Hallo werte W20xxA Besitzer und Interessierte!
Diesen Thread habe ich als Ersatz für den mittlerweile überfüllten
Thread
>Wittig(welec) Oszilloskop firmware problem<
eröffnet.
Für Hardwarethemen wird es einen eigenen Thread geben:
>Wittig(welec) DSO W20xxA Hardware>
Gruß Hayo
So hier noch eine kleine Wortliste damit der Thread auch von Google
gefunden wird:
DSO Oszilloskop oscilloscope WELEC WITTIG W2000 W2012A W2014A W2022A
W2024A
Gruß Hayo
Hallo Hayo,
nur um sicher zu gehen: Du benutzt den Bresenham nur im Notfall? Da
lohnt
meist eien Fallunterscheidung: horizontal, vertikal und diagonal direkt,
nur sonst Bresenham.
Gruß, Guido
Guido wrote:
> Hallo Hayo,>> nur um sicher zu gehen: Du benutzt den Bresenham nur im Notfall? Da> lohnt> meist eien Fallunterscheidung: horizontal, vertikal und diagonal direkt,> nur sonst Bresenham.>> Gruß, Guido
Hi Guido,
ja genauso hab ich es implementiert. Läuft ca. 10 mal schneller als die
alte Implementierung von WELEC. Zur Zeit teste ich noch ob auch alles
fehlerfrei gezeichnet wird, aber bislang sieht alles gut aus.
Gruß Hayo
Sorry wegen schlechtem deutsch, bin Spanier und beobachte Welec
Entwicklung.
Habe diesen LInk gefunden:
http://apps.sourceforge.net/phpbb/welecw2000a/view...
das ist gute Nachricht für alles Welec Oscilloscope Besitzer!
Hoffe mit euch auf gute Fortschritte bei Entwicklung-
Grusse
Broma
So hab mich nochmal aufgerafft und alles heute fertiggemacht. Die
Liesmich gibts jetzt auch in Englisch und der Updater ist auch mit
dabei. Wie immer die Liesmich beachten. Wesentliche Neuerung ist die
XY-Funktion.
Das File wird es auch auf Google Groups und SFN geben.
Viel Spaß
Hayo
Hallo Hayo,
hab deine neue FW bereits in mein Oszi geladen und schaue mir gerade die
XY-Funktion an.
Dazu hätt ich nun mal eine Frage, besteht die Möglichkeit in dieser
Einstellung die Lineare Interpolation zwischen den Messwerten
abzustellen und nur die reinen Messwerte darzustellen? Würde die Anzeige
schon deutlich verbessern.
Dann ist mir aufgefallen, dass ich immer einen einzelnen Messwerte habe,
der um die Nulllage herum liegt und das Bild verfälscht. Die ist so wie
es ausschaut auch gleich der allererste dargestellte Messpunkt.
Leider werden die Messdaten noch nicht korrekt wiedergegeben. Will
heißen: Ich würde erwarten, wenn ich an zwei Tastköpfen ein und dasselbe
Sinussignal anlege, dass die beiden Signale auf dem Display exakt
übereinander liegen. Das tun sie leider nicht, weswegen dann in der
x-y-Darstellung auch keine 45°-Schräge sondern eine Ellipse angezeigt
wird.
Liegt die Ursache hierfür im FPGA-Design oder in der FW?
Zur Mathe-Funktion:
Mir ist aufgefallen, dass bei den Einstellungen von Amplitude und Offset
nicht die LED am Verstell-Encoder leuchtet :)
Dann ist mir aufgefallen, dass unter den Setting von CH1*CH2 bei Scale
irgendwie Hieroglyphen im Scale-Button angezeigt werden.
Der Offset steht in allen Funktionen aus irgendeinem Grund nicht von
Haus aus auf 0V, das wäre sicherlich auch noch erstrebenswert.
Soweit an dieser Stelle die Kritik.
Ansonsten schon ein paar schöne Fortschritte in deiner FW.
Gruß, branadic
Hallo Hayo,
was mir gerade so beim Herumspielen mit deiner FW ins Auge gestochen
ist:
Für jeden Kanal gibt es ja den Kanalauswahlbutton, der Knopf mit der
Kanal-Zahl drauf.
Von dem Tek mit dem ich beinah täglich arbeite bin ich es gewohnt, wenn
ich diesen Kanalauswahlbutton drücke erscheint das Signal dieses Kanales
auf dem Display im Vordergrund, eine wie ich finde wirklich unglaublich
praktische Funktion.
Ist zum Beispiel wichtig, wenn ich mir ein moduliertes Signal anschauen
möchte und anschließend dessen passive Demodulation auf dem nächsten
Kanal. Aufgrund des zwangsläufigen Spannungsabfalls verschwindet das
demodulierte Signal nun hinter dem Signal des ersten Kanals bei gleichen
Scale-Einstellungen und gleichem Offset. Mit dem Kanalauswahlbutton hol
ich es mir einfach in den Vordergrund bzw. bestimme die Reihenfolge in
derer die einzelnen Kanäle angezeigt werden.
Ließe sich sowas in deiner FW integrieren?
Gruß, branadic
branadic wrote:
> Dazu hätt ich nun mal eine Frage, besteht die Möglichkeit in dieser> Einstellung die Lineare Interpolation zwischen den Messwerten> abzustellen und nur die reinen Messwerte darzustellen?
Hallo Branadic, danke für die prompte Reaktion. Bin leider erst heute
dazu gekommen mir das anzusehen. Wenn ich Dich richtig verstanden habe
meinst Du die Umschaltung zwischen Vektordarstellung und reine
Punktdarstellung? Die Umschaltung erfolgt wie beim normalen Zeitsignal
über das "Display" Menü mit der Taste Vectors.
> Dann ist mir aufgefallen, dass ich immer einen einzelnen Messwerte habe,> der um die Nulllage herum liegt und das Bild verfälscht. Die ist so wie> es ausschaut auch gleich der allererste dargestellte Messpunkt.
Das konnte ich leider bei mir nicht nachvollziehen. Mach doch mal ein
Bild, damit ich mir was darunter vorstellen kann.
> Leider werden die Messdaten noch nicht korrekt wiedergegeben. Will> heißen: Ich würde erwarten, wenn ich an zwei Tastköpfen ein und dasselbe> Sinussignal anlege, dass die beiden Signale auf dem Display exakt> übereinander liegen. Das tun sie leider nicht, weswegen dann in der> x-y-Darstellung auch keine 45°-Schräge sondern eine Ellipse angezeigt> wird.> Liegt die Ursache hierfür im FPGA-Design oder in der FW?
Kann es sein, dass Du nicht mit einem 50 Ohm abgeschlossenen Kabel
gemessen hast? Offenbar hast Du Dir da irgendwo eine Phasenverschiebung
eingefangen. Bei mir gibt es eine Diagonale (siehe Bild).
> zur Mathe-Funktion:> Mir ist aufgefallen, dass bei den Einstellungen von Amplitude und Offset> nicht die LED am Verstell-Encoder leuchtet :)
Ja, das ist mir auch schon aufgefallen, allerdings tritt das nicht immer
auf und war auch schon vorher so bei der originalen FW. Da ist wohl ein
Fehler in der Menüführung.
> Dann ist mir aufgefallen, dass unter den Setting von CH1*CH2 bei Scale> irgendwie Hieroglyphen im Scale-Button angezeigt werden.
Muß ich mal checken.
> Der Offset steht in allen Funktionen aus irgendeinem Grund nicht von> Haus aus auf 0V, das wäre sicherlich auch noch erstrebenswert.
Das liegt an den Konfigdaten die beim Start geladen werden (Bei Dir sind
noch die Konfigbereiche noch original). Das ist bei Welec die
Originaleinstellung. Bei mir ist das längst anders eingestellt. Ich hab
meine neuen Parameter noch nicht im Konfigbereich untergebracht, muß ich
demnächst mal machen.
> Soweit an dieser Stelle die Kritik.> Ansonsten schon ein paar schöne Fortschritte in deiner FW.
Danke und Gruß
Hayo
branadic wrote:
> Hallo Hayo,>> was mir gerade so beim Herumspielen mit deiner FW ins Auge gestochen> ist:>> Für jeden Kanal gibt es ja den Kanalauswahlbutton, der Knopf mit der> Kanal-Zahl drauf.> Von dem Tek mit dem ich beinah täglich arbeite bin ich es gewohnt, wenn> ich diesen Kanalauswahlbutton drücke erscheint das Signal dieses Kanales> auf dem Display im Vordergrund, eine wie ich finde wirklich unglaublich> praktische Funktion.> Ist zum Beispiel wichtig, wenn ich mir ein moduliertes Signal anschauen> möchte und anschließend dessen passive Demodulation auf dem nächsten> Kanal. Aufgrund des zwangsläufigen Spannungsabfalls verschwindet das> demodulierte Signal nun hinter dem Signal des ersten Kanals bei gleichen> Scale-Einstellungen und gleichem Offset. Mit dem Kanalauswahlbutton hol> ich es mir einfach in den Vordergrund bzw. bestimme die Reihenfolge in> derer die einzelnen Kanäle angezeigt werden.>> Ließe sich sowas in deiner FW integrieren?
Um sicher zu gehen dass ich Dich richtig verstanden habe (kenne diese
Funktion bislang nicht): Mit Vordergrund/Hintergrund meinst Du bei
Signalen die direkt übereinander liegen, welches beim Zeichnen "oben"
und welches "unten" liegt bzw. welches Signal von welchem verdeckt wird?
Falls ich das so richtig verstanden habe, -> ja das sollte sich umsetzen
lassen. Hört sich ganz nützlich an.
Gruß Hayo
Hallo Hayo,
jetz habe ich mich auch mal an deine Beta rangetraut. Folgendes ist mir
aufgefallen:
Das Signal wird nicht bis zum unteren Bildschirmrand gezeichnet. Schön
zu sehen an einem "übersteuerten" Sinus.
Die Quick-Measures funktionieren nicht richtig.
Wenn man die Eingangskopplung der Kanäle auf GND schaltet, kleben die
Nulllinien am oberen Bildschirmrand.
Die Multiplikation sieht komisch aus und scheint einen großen negativen
Offset zu haben. Man muss einen positiven Offset einstellen, um das
Signal überhaupt auf den Schirm zu kriegen.
Die Eingangskopplung stand natürlich auf AC.
Beim Versuch die Daten auf den PC zu übertragen, bleibt der
Fortschrittsbalken in der Welec Software am Ende stehen und es passiert
garnichts mehr.
Beim XY ist auch auf beiden Kanälen ein negativer Offset. Vieleicht der
selbe den branadic meint.
Das symmetrische Raster ist wunderschön ;-)
Mfg,
Kurt
Hallo Hayo,
das mit dem Umschalten der Vectordarstellung hatte ich irgendwie
verdrängt :)
Ich messe übrigens nicht mit 50-Ohm-Kabeln sondern mit den Tastköpfen.
Abgeschlossen ist das DDS-Board aber dennoch mit 50 Ohm.
Hab eine schöne Phasenverschiebung zwischen Kanal 1 und Kanal 2, obwohl
sie beide am gleichen Ausgang vom DDS-Board hängen. Ich seh da jetzt
ehrlich gesagt keinen Messfehler?
Daher nun auch das Bild. Zum Einen siehst du wie die beiden Signale
schön voneinander phasenverschoben liegen, zum Anderen gleich noch den
Ausreißer.
Auf dem Bild von Kurt kannst du übrigens die Hieroglyphe sehen, die
zieht sich dann (siehe mein Bild) in andere Menü's mit und wird nicht
überschrieben.
Ansonsten hast du mich genau richtig verstanden, was die Signalpriorität
auf dem Bildschirm angeht. Ich denke das ist eine nette Bereicherung auf
auf dem Welec.
Ist dein 4-Strahler heute eigentlich eingetroffen? Hin und wieder hab
ich die Vermutung, dass einige vermeintliche Fehler in deiner FW auf die
Tatsache zurückzuführen sind, dass ich hier noch den 2. FPGA drin habe.
Gruß, branadic
Kurt Bohnen wrote:
> Das Signal wird nicht bis zum unteren Bildschirmrand gezeichnet. Schön> zu sehen an einem "übersteuerten" Sinus.
Ja, Fehler ist bekannt -> hab ich in der readme beschrieben, nach der
Ursache suche ich noch, passiert irgendwo beim Zusammenmischen der
Grafiklayer.
> Die Quick-Measures funktionieren nicht richtig.
Hab ich befürchtet, da hier die Zerolinie völlig verschoben ist durch
meine Änderungen -> muß ich noch machen
> Wenn man die Eingangskopplung der Kanäle auf GND schaltet, kleben die> Nulllinien am oberen Bildschirmrand.
Oh, hatte ich ich noch garnicht bemerkt, ist das gleiche Problem wie bei
Quickmeasure, werd ich bis zur nächsten Beta beseitigen.
> Die Multiplikation sieht komisch aus und scheint einen großen negativen> Offset zu haben. Man muss einen positiven Offset einstellen, um das> Signal überhaupt auf den Schirm zu kriegen.
Hier wirkt sich die Multiplikation sehr stark auf kleinste Abweichungen
aus. Bei meinen bisherigen Testsignalen ist mir das nicht so extrem
aufgefallen. Hab mal Dein Testsignal nachgestellt und muß Dir recht
geben. Da muß ich mir nochmal was überlegen -> eine Idee hab ich schon.
> Beim Versuch die Daten auf den PC zu übertragen, bleibt der> Fortschrittsbalken in der Welec Software am Ende stehen und es passiert> garnichts mehr.
Die übertragung zum PC hab ich zur Zeit noch überhaupt nicht auf dem
Radar, da ich davon ausgegangen bin, dass Falk hier dran ist. Allerdings
hab ich da schon länger nichts mehr gehört. Muß ich aber erstmal hinten
an stellen, da mir die anderen Funktionen erstmal wichtiger sind.
Trotzdem Danke für den Hinweis.
> Beim XY ist auch auf beiden Kanälen ein negativer Offset. Vieleicht der> selbe den branadic meint.
Konnte ich leider nicht nachvollziehen. Wie man an meinem Testsignal
weiter oben sehen kann geht die Diagonale ziemlich genau durch den
Nullpunkt. Wie groß ist denn Dein Offset und wie hast Du gemessen?
> Das symmetrische Raster ist wunderschön ;-)
Höre ich gerne...
Gruß Hayo
branadic wrote:
> Ich messe übrigens nicht mit 50-Ohm-Kabeln sondern mit den Tastköpfen.> Abgeschlossen ist das DDS-Board aber dennoch mit 50 Ohm.
Ich vermute, dass die Tastköpfe die Phasenverschiebung verursachen.
> Daher nun auch das Bild. Zum Einen siehst du wie die beiden Signale> schön voneinander phasenverschoben liegen, zum Anderen gleich noch den> Ausreißer.
Schicke Liss-Figur, hab ich bei mir leider nicht hingekriegt, da ich
keine so schöne Phasenverschiebung produzieren konnte - muß ich mal mit
den Tastköpfen probieren.
> Auf dem Bild von Kurt kannst du übrigens die Hieroglyphe sehen, die> zieht sich dann (siehe mein Bild) in andere Menü's mit und wird nicht> überschrieben.
Ist keine Hieroglyphe, sondern ein kleines Bild. Dachte das wäre so
original. Keine Ahnung wo das herkommt, an der Stelle hab ich auch
nichts verändert. Scheint noch ne Macke aus der 1.2 FW zu sein.
>> Ansonsten hast du mich genau richtig verstanden, was die Signalpriorität> auf dem Bildschirm angeht. Ich denke das ist eine nette Bereicherung auf> auf dem Welec.
Kümmere ich mich drum
> Ist dein 4-Strahler heute eigentlich eingetroffen? Hin und wieder hab> ich die Vermutung, dass einige vermeintliche Fehler in deiner FW auf die> Tatsache zurückzuführen sind, dass ich hier noch den 2. FPGA drin habe.
Nein, Schande auch! Christian (hat im anderen Thread gepostet) hat seins
schon - ich nicht, hmmm...
-> morgen bestimmt.
Dann werd ich da mal ein paar Vergleiche anstellen.
Gruß Hayo
Das mit dem Offset in der XY Darstellung nehme ich zurück. Das lag nur
am falschen Nullabgleich der Kanäle.
Jedoch funktionieren die Cursor hier nicht richtig.
Und in der normalen Betriebsart stimmen die Anzeigen der Y-Cursor nicht
mit dem Raster überein.
So alle,
habe auch mal mit XY-Modus probiert. Bin ich eigentlich der Einzige, der
den mit einem SA o.ä. verwenden möchte? Lissajous ist ja ein schönes
Spielzeug aber dafür sind DSOs doch nicht wirklich gut geeignet.
@ Hayo: Die Darstellung im XY-Modus ist an der Mittelsenkrechten
gespiegelt (Fotos mach ich später noch). Welche Y-Signale stellst du
denn
dar, alle passen ja wohl nicht auf den Schirm. Ich vermute, dass da
ziemlich ausgefuchste Algorithmen nötig sind.
[Mecker:] Schönes Raster, aber mir fehlen echt die 2 Divisions in der
Horizontalen. [/Mecker:]
@ branadic: Hast du vllt. den 2. Kanaleingang auf AC stehen? Bei
niedrigen Frequenzen verursacht der Koppelkondensator so eine
Phasenverschiebung.
Gruß, Guido
Kurt Bohnen wrote:
> Das mit dem Offset in der XY Darstellung nehme ich zurück. Das lag nur> am falschen Nullabgleich der Kanäle.> Jedoch funktionieren die Cursor hier nicht richtig.>> Und in der normalen Betriebsart stimmen die Anzeigen der Y-Cursor nicht> mit dem Raster überein.
Cursor hab ich noch überhaupt nicht probiert, die müssen noch angepasst
werden. Hatte erstmal mit der XY-Funktion und der Optimierung der line()
Funktion alle hände voll zu tun. Wollte erstmal das Feedback zur reinen
XY-Funktion abwarten bevor ich weitermache.
Das Gleiche gilt für die Cursor in der normalen Betriebsart.
Das Dumme ist, dass ich hier Korrekturen an Coding durchführe für die
WELEC mehrere Jahre Entwicklungszeit hatte - dafür dass ich das nur
nebenbei mache bin ich also recht schnell finde ich.
Nichtsdestotrotz bin ich guter Dinge, in erster Linie versuche mal die
grundlegenden Funktionen benutzbar zu machen.
Gruß Hayo
Guido wrote:
> So alle,>> habe auch mal mit XY-Modus probiert. Bin ich eigentlich der Einzige, der> den mit einem SA o.ä. verwenden möchte?
Was ist SA?
> Lissajous ist ja ein schönes> Spielzeug aber dafür sind DSOs doch nicht wirklich gut geeignet.
Geht besser als mit meinem analogen 50MHz Oszi, das ist XY-Betrieb nur
bis 100KHz spezifiziert, danach ist die interne Phasenverschiebung zu
groß.
> @ Hayo: Die Darstellung im XY-Modus ist an der Mittelsenkrechten> gespiegelt (Fotos mach ich später noch). Welche Y-Signale stellst du> denn> dar, alle passen ja wohl nicht auf den Schirm. Ich vermute, dass da> ziemlich ausgefuchste Algorithmen nötig sind.
Wie meinst Du das mit den Y-Signalen?
> [Mecker:] Schönes Raster, aber mir fehlen echt die 2 Divisions in der> Horizontalen. [/Mecker:]
Welche Division möchtest Du denn noch haben? Habe zum Vergleich nur mein
analoges Oszi und da sieht es genauso aus. Ansonsten läßt sich das Grid
über Terminal auch in die alte gepunktete Darstellung umschalten ->
siehe readme
> @ branadic: Hast du vllt. den 2. Kanaleingang auf AC stehen? Bei> niedrigen Frequenzen verursacht der Koppelkondensator so eine> Phasenverschiebung.
Das stimmt, das könnte sein...
Gruß Hayo
@Guido
Ich habe mal die Sache mit dem spiegelverkehrten Signal um die vertikale
Achse geprüft -> Du hast Recht, es ist verkehrt rum.
Muß also noch korrigiert werden. Ist in Arbeit...
Gruß Hayo
Hallo Hayo,
hat etwas gedauert, aber ein Bild sagt mehr.....
Mit SA meine ich einen Spektrumanalyzer, hier mein Stolz, ein
TEK 1401A, bestimmt älter als die meisten Teilnehmer dieses
Forums.
Zum Vergleich links die Aufnahme am TDS210, viel besser geht es
mit einem analogen Oszi auch nicht. Die "Nachleuchtfunktion" ist
bei dieser langen Aufzeichnungsdauer sehr hilfreich, könnte aber
schwierig zu implementieren sein.
Für alle, die mit solchen Bildern nicht so firm sind: ganz links
der erste Peak ist die Nulllinie, die zur Einstellung des hor.
Offsets benutzt werden kann. Nach rechts geht es mit 50 MHZ/div
weiter. der nächste Peak ist das Nutzsignal bei 80 MHz. Dann
folgen die Oberwellen, wobei ein div einer Abschwächung um 20 dB
entspricht. Das ist meine eines Testsignal für das Welec, einstellbar
von 52 MHz bis 125 MHz, fast reiner Sinus.
Auf dem Welec ist das Bild seitenverkehrt, das Hayo ja schon im Griff.
Woher der "Rahmen" kommt ist mir unklar.
@ Hayo: Denke einfach an die FFT: 100 MHZ bzw. 200 MHz mit 8 div wird
ziemlich ungerade. Mir geht es mit 500 MHz genauso, deswegen wären
horizontal 10 div (wie bei jedem Oszi) besser, Symmetrie hin oder
her. Dass es dann mit den Spannungen ungerade wird ist kein Problem,
da sich dieses mit einem Spannungsteiler lösen lässt.
Die Y-Signale: bei der Speichertiefe des Gerätes kann ich mir nicht
vorstellen, dass du alle Werte zeichnest. Wie triffst du die Auswahl?
Lissajous: Die einzige mir bekannte Nutzung dieser liegt im Abgleich
von Oszillatoren. Mit einem DSO, das mir 1 bis 2 Bilder pro Sekunde
darstellt wird das aber sinnlos. Da kann man einfacher einen
Frequenzzähler einsetzen.
Was ich noch überhaupt nicht kapiere: kann das Gerät sich Einstellungen
merken? Kann ich mir eigentlich nicht vorstellen (im FPGA). Aber mir
kommt es bei der vertikalen Abschwächung so vor, die Offseteinstellung
ist aber immer nach dem Ausschalten weg.
Gruß, Guido
Hallo Guido,
so, jetzt lass mich bitte nicht unwissend sterben...
Wozu brauchst du den XY Betrieb? Zur Spektralanalyse? Hmmm also das
interessiert mich dann schon wie du das machst. Wenn ich das richtig
verstanden habe führt dein TEK diese SA durch und du missbrauchst das
Welec nur zur Anzeige des Ergebnisses- weil du dir davon eine bessere
Darstellung versprichst?
Mal sehen wozu die eingebaute FFT im Stande ist, wenn diese einmal in HW
implementiert ist... vielleicht verkaufst du dein TEK dann ja? Das TEK
hat aber bestimmt eine wesentl. höhere Grenzfrequenz?
Meine Hauptanwendungen des XY -Betrieb sind:
Bestimmen von Frequenzbeziehungen- vor allem geringste Phasenjitter
lassen sich so absolut präzise feststellen. Bei analogen Oszi's ist das
allerdings meist nur bis Frequenzen von ca. 1MHz möglich, da darüber
die geräteinternen Phasenjitter zu groß werden.
Aber die wichtigste Anwendung ist die Aufnahme von Kennlinienfelder.
Dioden, Transistoren u.v.m. lassen sich somit schnell und exakt in ihren
elektr. Kenngrössen miteinander vergleichen.... Der XY-Betrieb ist damit
weit mehr als nur eine Spielerei!
Gruß
brunowe
Hallo Hayo hallo Guido,
ich hatte beide Kanäle auf AC_Coupling. Witzigerweise habe ich diese
Phasenverschiebung auch bei DC-Coupling.
Wäre zu prüfen, ob das durch die Tastköpfe selbst kommt oder noch eine
andere Ursache hat.
Werd am Montag mal 50-Ohm-Kabel mitnehmen und den Versuch wiederholen.
Gruß, branadic
Guido wrote:
> Mit SA meine ich einen Spektrumanalyzer, hier mein Stolz, ein> TEK 1401A, bestimmt älter als die meisten Teilnehmer dieses> Forums.
-> Cool! Dann ist das Gerät also schon so um die 50 Jahre alt?
Wußte garnicht das es damals schon sowas gab ;-)
> Zum Vergleich links die Aufnahme am TDS210, viel besser geht es> mit einem analogen Oszi auch nicht. Die "Nachleuchtfunktion" ist> bei dieser langen Aufzeichnungsdauer sehr hilfreich, könnte aber> schwierig zu implementieren sein.
Sowas ähnliches wie die Nachleuchtfunktion gibt es am W20xx auch, nennt
sich "Persist" im Display-Menü.
> Auf dem Welec ist das Bild seitenverkehrt, das Hayo ja schon im Griff.
Jupp, ist schon erledigt.
> @ Hayo: Denke einfach an die FFT: 100 MHZ bzw. 200 MHz mit 8 div wird> ziemlich ungerade. Mir geht es mit 500 MHz genauso, deswegen wären> horizontal 10 div (wie bei jedem Oszi) besser, Symmetrie hin oder> her. Dass es dann mit den Spannungen ungerade wird ist kein Problem,> da sich dieses mit einem Spannungsteiler lösen lässt.
Nicht nötig, da ich gerade dabei bin eine Spectralanalyse (FFT) zu
implementieren die auch nicht schlechter sein wird als beim TEK.
Allerdings bin ich ebenso wie Bruno neugierig wie Du die Darstellung im
XY-Modus hingekriegt hast -> sieht irgendwie cool aus
> Die Y-Signale: bei der Speichertiefe des Gerätes kann ich mir nicht> vorstellen, dass du alle Werte zeichnest. Wie triffst du die Auswahl?
Korrekt, ich hatte die Auswahl zwischen wenigen Werten (schnell) und
vielen Werten (langsam). Da die reale Speichertiefe je nach Timebase
Zwischen 655 und 16K variiert, habe ich mich für die Darstellung der im
Zeitbereich angezeigten 600 Punkte entschieden. Dann weiß man, dass man
im XY-Betrieb genau das sieht was man vorher im Normalbetrieb
eingestellt hat.
> Lissajous: Die einzige mir bekannte Nutzung dieser liegt im Abgleich> von Oszillatoren. Mit einem DSO, das mir 1 bis 2 Bilder pro Sekunde> darstellt wird das aber sinnlos. Da kann man einfacher einen> Frequenzzähler einsetzen.
-> die Antwort hat Bruno schon gegeben...
> Was ich noch überhaupt nicht kapiere: kann das Gerät sich Einstellungen> merken? Kann ich mir eigentlich nicht vorstellen (im FPGA). Aber mir> kommt es bei der vertikalen Abschwächung so vor, die Offseteinstellung> ist aber immer nach dem Ausschalten weg.
-> definitiv ja! Bei bestimmten Eingaben (z.B. Verstellung der Timebase)
werden alle aktuellen Parameter ins Flash in den Konfigurationsbereich
geschrieben (kann man bei meiner FW sehen wenn ein Terminalprogramm
läuft). Allerdings muß ich zugeben, dass einige meiner neuen Parameter
noch nicht gesichert werden, ist aber auch schon in Arbeit.
Gruß Hayo
Eben habe ich mal diesen Phasenschieber zusammengelötet. Bei f0 macht er
-90°. Aber durch ändern der Eingangsfrequenz ändert sich auch die
Phasenverschiebung.
Hey, sehr schön, sowas hat mir als Bestätigung für die Funktion noch
gefehlt. Mußte mich immer mit einer Mischung aus Sinus (Funkt.
Generator) und Rechteck (Quarzoszillator) begnügen. Das entstehende
Signal ist aber für Testzwecke eigentlich zu kompliziert. Daher ist das
Bild sehr willkommen!
Gruß Hayo
Hallo alle,
>Meine Hauptanwendungen des XY -Betrieb sind:>Bestimmen von Frequenzbeziehungen- vor allem geringste Phasenjitter>lassen sich so absolut präzise feststellen. Bei analogen Oszi's ist das>allerdings meist nur bis Frequenzen von ca. 1MHz möglich, da darüber>die geräteinternen Phasenjitter zu groß werden.
Was aber am Analogteil liegt, der bei den Welecs sicher auch nicht
besser ist als bei einem analogen Oszi.
>Aber die wichtigste Anwendung ist die Aufnahme von Kennlinienfelder.>Dioden, Transistoren u.v.m. lassen sich somit schnell und exakt in ihren>elektr. Kenngrössen miteinander vergleichen.... Der XY-Betrieb ist damit>weit mehr als nur eine Spielerei!
So sehe ich das auch, ein Wobbler oder SA verwendet den XY-Modus exakt
genauso.
>Nicht nötig, da ich gerade dabei bin eine Spectralanalyse (FFT) zu>implementieren die auch nicht schlechter sein wird als beim TEK.
Vorsicht, da liegen Welten dazwischen. Die Grenzfrequenz des 1401A liegt
bei 500 MHz (sieht man ja auf dem Bild). Die Amplitudenauflösung bei
über
70 dB. da kann das Welec niemals mithalten. Die Empfindlichkeit geht
soweit, dass ein Meter Draht am Eingang reichen um die UKW-Sender
sichtbar zu machen.
>-> Cool! Dann ist das Gerät also schon so um die 50 Jahre alt?>Wußte garnicht das es damals schon sowas gab ;-)
Hallo hayo, dass das für dich nicht zutrifft habe ich mir schon gedacht.
Für mich übrigens auch nicht. Aber das Gerät ist rund 35 Jahre alt,
für die meisten Teilnehmer wird es also schon zutreffen.
>Allerdings bin ich ebenso wie Bruno neugierig wie Du die Darstellung im>XY-Modus hingekriegt hast -> sieht irgendwie cool aus
Aber bitte, das Bild habe ich nicht gemacht, nur aufgenommen. Das war
schon das Welec. das X-Signal ist einfach ein Sägezahn und in Y-Richtung
sind die Peaks vorhanden, die man ja beim TDS210 auch sieht.
Gruß, Guido
Ok, an die 500 MHz komme ich natürlich nicht heran, was ich aber meinte
war die Darstellung des Signals. Da werd ich mich mal ins Zeug legen,
dass das mal etwas geschmeidiger aussieht als ursprünglich bei den alten
Welecs. Bin da auch schon vorbelastet, da ich sowas mal als Diplomarbeit
gemacht habe.
-> Das mit dem Sägezahn werde ich auch mal ausprobieren, den Trick
kannte ich noch garnicht, man lernt nie aus...
Gruß und guats Nächtle wie der Schwabe sagen würde
Hayo
Ein Sägezahn als x-Signal- also eine gleichmäßig ansteigende Spannung.
Warum erinnert mich das nur so an das Zeitbasis- Signal? Das würde doch
bedeuten du kannst gleich den normalen Betriebsmodus wählen, wenn du
eine entsprechende Zeitbasis- Einstellung findest?
Hallo Bruno We,
das ist ja ein Messgerät. Mit mal so ungefähr die Zeitbasis halbwegs
brauchbar hinkriegen wird das nichts. Aber genau für solche Fälle ist
ja der XY-Modus vorgesehen. Das 1401A hat übrigens keine eigene
Anzeige, war also zum Gebrauch mit einem Oszilloskop vorgesehen.
Gruß, Guido
Hallo Guido,
siehst du...
>Das 1401A hat übrigens keine eigene>Anzeige, war also zum Gebrauch mit einem Oszilloskop vorgesehen...
das war die entscheidende Info- Das Tek stellt also auch direkt das
passende Sägezahnsignal zur Verfügung. Das selbe kannst du mit einer
variabel einstellbaren Zeitbasis, so wie es viele Oszi's besitzen, auch
erreichen.
(Ein Referenzsignal vorausgesetzt)
Aber mit der Info:
1) Das Tek hat keine eigene Anzeige und
2.) Es stellt dafür ein Sägezahnsignal für die xy Ablenkung zu
Verfügung,
hätten wir uns die letzten 10 Posts sparen können.
Gruß
Hallo,
ich hab am Wochenende mal die neue Firmware von Hayo getestet und noch
ein paar Probleme entdeckt, die bei mir und einem Freund (wir haben
beide das W2024) auftraten.
Anbei sind ein paar Bilder, die das Problem beschreiben. Es sieht für
mich so aus, als wenn eine falsche Speicherposition ausgelesen und
dargestellt würde (letztes Bild). Bei Timebase-Einstellungen von größer
2ms bekomme stellt das Oszi nur noch eine Linie dar (kein Rauschen).
Dies beginnt mit nur einem Kanal und setzt sich bei größerer Timebase
fort. Ab 50ms und größer ist das Signal eingefrohren.
Das andere Problem ist die Kalibrierung bei Kanal 3 und 4. Wenn ich
genau die Stufen treffe (im Bild 5V und 500mV) dann ist sie gut. Stelle
ich aber 2V ein, so habe ich einen großen Offset.
nur so am Rande - bei den ersten 3 Bildern ist das Gehäuse so ocker -
hast du das umgespritzt oder rauchst du 3 Schachteln am Tag vor dem Teil
;-)) ??
gut's Nächtle
egberto
Hallo,
nö, vor dem XY-Modus kapituliere ich. Auch wenn ich die Vektoren
ausschalte bekomme ich nur ca. 1 Bild/s. Was macht das Ding in der
Zwischenzeit? Auch mit konstanten Signalen am Eingang springt die
Anzeige hin und her. Habe mal Lissajous bei 512 kHz probiert, sieht
aus wie Aliasing-Probleme, aber die zeitl. Abhängigkeit müsste doch
im XY-Betrieb weg sein.
Michaels Problem kann ich bestätigen, bei langsamer als 10 ms/div
friert bei mir der Bildschirm ein.
@ Bruno: das Welec hat keine variable Zeitbasis und Synchronität ist
mit sowas nicht zu schaffen.
Gruß, Guido
Hallo Michael,
danke für die Hinweise, leider hab ich meinen Vierkanaler immer noch
nicht... grummel, Welec läßt sich verdammt viel Zeit, vielleich heute.
Daher bin ich auf den Kanälen 3 + 4 "blind" und kann da momentan nichts
dran machen. An einem neuen Nullabgleich bin ich aber ohnehin dran, da
ich auch noch nicht zufrieden war.
@Guido
Ich habe die XY-Funktion noch mal komplett überarbeitet und erweitert.
Du hast recht, in der 0.48 dreht das Ding noch ein paar Ehrenrunden,
deswegen sieht das auch etwas zugemüllt aus. Die neue Version ist
schneller, hat einen komplett von der Zeitdarstellung getrennten Offset
und - kleines Schmankerl für alle 4-Kanaler - eine zusätzliche
XY-Darstellung für Kanal 3 + 4 die auch gleichzeitig mit Kanal 1 + 2
dargestellt werden kann.
Nebenbei hab ich etliche Fehler beseitigt. Die neue Version gibt es
heute oder morgen.
Gruß Hayo
Hallo Hayo,
freut mich zu hören, dann warte ich mal ab. Zum Zeitbasisproblem:
10 ms/div geht, 20 ms/div Bildschirm eingefroren, langsamer dito.
Aktivierter Mathemodus (z.B. 2-1): 20 ms/div geht noch, ab
50 ms/div eingefroren.
Kannst du das Abspeichern der Einstellungen noch mal anschauen?
Ich muss nach jedem Einschalten ein Autozero durchführen, weil er
mindestens einen Kanal wieder verstellt hat.
Gruß, Guido
Hallo Hayo,
mir ist aufgefallen das in deiner FW- genauso wie im Original, im
"Vector off- Mode" nicht nur die Messwerte dargestellt werden. Falls ich
mich nicht verzählt habe werden in 10ns/Div 40Px gezeichnet, obwohl ja
nur Jede Nanosekunde ein Messwert vorliegt. D.h. es wird schon irgendwie
interpoliert...
Ich fände es, speziell für die Entwicklungsphase, weitaus besser wenn
wirklich nur die reinen Messwerte dargestellt werden. Man könnte so
wesentl. leichter etwaige ADC Nichtlinearitäten zuordnen (und
beseitigen).
Slog hat das in seinem FPGA Design wunderschön vorgemacht, indem jeder
ADC seine eigene Zeichenfarbe erhalten hat. Ich möchte jetzt keine
Grundsatzdiskussion über Sinn und Unsinn des Vector -off Mode
lostreten... dennoch würde dieses Feature gerade auch bei der Lösung der
HW Probleme imens helfen.
Gruß Brunowe
@Guido
Ja das mit dem eingefrorenen Signal konnte ich auch nachvollziehen, war
mir nur nie aufgefallen da ich in diesen Zeitbereichen nicht so häufig
teste. Meine Vermutung ist, dass es mit dem Trigger zusammenhängt, denn
die Zeichenroutine wird durchlaufen, es kommt nur kein neues Signal. Ich
hatte aber für das übernächste Betarelease ohnehin vor größere
Änderungen durchzuführen, unter anderem wollte ich den Zeroshift wieder
einbauen und dann einen neuen Zero-Offsetabgleich programmieren.
Vermutlich erledigt sich das Problem dann gleich mit.
@Bruno
Ja natürlich hast Du recht, denn die Signalgewinnung und
Signalverarbeitung sind komplett getrennt von der Zeichroutine. D.h.
wenn umgeschaltet wird zwischen Vector und Nonvector dann betrifft das
nur die Zeichenroutine. Die bekommt aber nur einen Wertebuffer übergeben
der die zu zeichnenden Werte enthält - in den Bereichen > 50ns sind das
halt die interpolierten Signalwerte. Die Interpolation findet also nicht
in der Zeichenroutine statt sondern vorher, daher wäre es etwas
schwierig die interpolierten Werte hinterher wieder auszublenden.
Weglassen kann man sie aber auch nicht, da sonst die Zeitachse nicht
mehr korrekt wäre(wäre sonst wie 50 ns).
Die Features der experimentellen FPGA-Version von Slog lassen sich hier
nur schwer einbauen (der derzeitige Stand ist dafür schon zu komplex),
auch wenn ich Dir recht geben muß, dass es für einige Tests ganz
hilfreich wäre.
Gruß Hayo
p.s. die neue FW kommt doch erst morgen, mein Oszi hoffentlich auch...
Hayo W. wrote:
> der die zu zeichnenden Werte enthält - in den Bereichen > 50ns sind das
sollte natürlich heißen < 50 ns - interpoliert werden 20ns und 10 ns
(und in Kürze auch die neue Zeitbasis 5ns)
Hayo
Hallo Hayo,
ja das habe ich mir schon fast gedacht :-( Wäre zu schön gewesen!
Dann muss ich mich wohl bei meiner "Messerei" anders behelfen...
Eine 5ns Zeitbasis ist ein guter Einfall, setzt aber eine gute
Interpolation (sinx/x) voraus.
Gruß
brunowe
Ob die Interpolation gut genug ist kannst Du Dir ja mal ansehen, es gibt
den 5ns Bereich nämlich schon - nur noch nicht im Main-Mode. Wenn Du bei
10ns in den Delayed-Mode schaltest hast Du Ihn!
Gruß Hayo
So hier wie angekündigt die aktuelle beta version 0.50 - es sind einige
Änderungen erfolgt insbesondere im XY-Betrieb.
Wundert Euch nicht beim Neustart, wenn es erstmal komisch aussieht. Da
ich die Ablage der Parameter im Config-Bereich geändert habe werden
erstmal unpassende Parameterwerte gezogen. Durch Betätigung des
Defaultsetups ist das dann aber erledigt. Bei der nächsten Verstellung
der Timebase werden dann aktuelle Werte weggeschrieben. Einen Flashdump
habt Ihr ja vorsichtshalber gemacht oder?
In der Defaultzeichenroutine werkelt jetzt die neue beschleunigte line()
Funktion, da diese das Signal an den Spitzen feiner auflöst als die alte
Zeichenroutine. Kann man gut sehen wenn man via Terminalprogramm mit den
Tasten shift + s die Darstellung umschaltet. Die Geschwindigkeit ist so
ziemlich gleich.
Die XY-Funktion hat jetzt eine eigene Zeroverstellung, deren Werte auch
getrennt im Configbereich abgelegt werden, so daß nach dem
Wiedereinschalten des Gerätes das Sinal noch an der gleichen Stelle ist
wie vorher.
Die Leute mit einem Vierkanalgerät könnten ja mal die XY-Funktion für
die Kanäle 3 + 4 testen die ich zwar implementiert habe, aber selber
noch nicht zu Gesicht bekommen habe (schneuz).
Die nächste Version wird wohl etwas dauern, da erstmal Ostern anliegt
und ich dann größere Umbaumaßnahmen vor habe, mit denen dann hoffentlich
auch etliche aktuelle Bugs verschwinden.
Also laßt mal hören was Ihr dazu meint.
So zum Schluß muß ich nochmal meinen Frust loswerden....mein Oszi ist
immer noch nicht da, obwohl WELEC das für den 4. April als spätesten
Termin angekündigt hatte. Die Gutschreibung des Betrages war sogar schon
am 27.3. . Da bin ich doch schon etwas geknickt muß ich sagen.
So langsam könnte das mal an Land kommen oder?
Gruß Hayo
Hallo Hayo,
das schalten der Kanäle auf GND funktioniert wieder. Allerdings behällt
Kanal 2 einen winzigen positiven Offset.
Ein verstellen der Volt/Div Knöpfe sorgt dafür dass sich der
entsprechende Kanal leicht verschiebt. Jedoch Komplett: Nullmarkierung,
Nulline, Triggermarkierung.
Noch schlimmer ist es bei Kanal 1: Wenn ich den Volt/Div Knopf beliebig
weit nach rechts drehe, also in Bereiche von 5mV,2mV,1mV... (wenn es die
geben würde) verschiebt sich der Kanal immer weiter nach oben.
Mfg,
Kurt
PS: Hoffentlich verzögert Welec den Versand nicht absichtlich. In den
Bewertungen heißt es immer "schnelle Lieferung".
Kurt Bohnen wrote:
> Hallo Hayo,> das schalten der Kanäle auf GND funktioniert wieder. Allerdings behällt> Kanal 2 einen winzigen positiven Offset.>> Ein verstellen der Volt/Div Knöpfe sorgt dafür dass sich der> entsprechende Kanal leicht verschiebt. Jedoch Komplett: Nullmarkierung,> Nulline, Triggermarkierung.>> Noch schlimmer ist es bei Kanal 1: Wenn ich den Volt/Div Knopf beliebig> weit nach rechts drehe, also in Bereiche von 5mV,2mV,1mV... (wenn es die> geben würde) verschiebt sich der Kanal immer weiter nach oben.
Hmm, muß ich mir mal angucken, ich hab die Nullinie jetzt geändert, in
der originalen FW wird einfach stumpf eine Linie beim Zerolevel
gezeichnet, während ich das jetzt so geändert habe, dass in der
Ausleseroutine des ADC statt der ADC-Werte Null (bzw. 127) in den
Speicher geschrieben wird. Ansonsten würde nämlich auch das Math-Signal
falsch berechnet werden, da ja im Hintergrund immer noch das
ursprüngliche Signal ausgelesen und berechnet würde.
> PS: Hoffentlich verzögert Welec den Versand nicht absichtlich. In den> Bewertungen heißt es immer "schnelle Lieferung".
Da wären sie ja schön blöd, denn breiter als hier könnten sie es wohl
kaum irgendwo trampeln! Wenn man bei Google die entsprechenden Begriffe
eingibt landet man zwangsläüfig in diesem Forum - Allerdings
interessanterweise nicht in diesem Thread sondern im Alten. Anscheinend
ist der Suchcache noch nicht aktualisiert worden.
Gruß Hayo
Warum sollten die denn den Versand verzögern?
Viele Grüße,
egberto
PS: Habe heute auch so ein 4 Kanal Teil (200 MHz) geschossen - Nach
Ostern (wenn nichts dazwischen kommt) bin ich dann (erst mal als Tester)
hier dabei!
Hallo Hayo,
das sieht wieder mal richtig gut aus. Der XY-Modus ist wirklich
deutlich schneller und einen Lissajous habe ich jetzt auch
hinbekommen.
Kurts Meldung kann ich bestätigen, ist bei mir in beiden Kanälen.
Sieht aus, als ob der Drehgeber für die Aschwächung/Verstärkung die
vert. Pos. verschiebt.
Mir scheint, dass in den langsamen Bereichen eine für die Grafik
zuständige Variable überläuft. Schalte ich auf 20 ms/div, friert
der Bildschirm ein. Zurück auf 10 ms/div gibt es einen Bruch in der
Darstellung bei der 3. div (Verschiebung im Signal). Weiter runter
auf 5 ms/div, der Bruch verschiebt sich in die Mitte des Schirms.
Jetzt stehen die Signale bei mir wie eine Eins auf dem Schirm, kein
Rumspringen mehr und dementsprechend auch kein hektischer Druck auf
Run/Stopp. Liegt das an der neuen Firmware, oder hatte ich vorher
was anderes verbockt?
Gruß, Guido
Prima,
unsere kleine Gemeinde wächst von Woche zu Woche. Da macht das
weiterentwickeln so richtig Spass...
Ich denke übrigens nicht, dass da Absicht hintersteckt. Allerdings hab
ich heute mal eine Anfrage abgeschickt aber noch keine Antwort gekriegt.
Gruß Hayo
Oh, das sollte eigentlich eine Antwort an Egberto sein, aber ich sehe
gerade dass da schon wieder zwei Beiträge dazwischen stehen :-)
Danke übrigens wieder für die schnellen ersten Reaktionen. Heute hab ich
allerdings keine Lust mehr die Kiste anzuschmeißen. Werd mir das mal
später ansehen
@ Guido
Hast Du mal den XY-Modus auf Kanal 3 + 4 gecheckt? Würd mich mal
interessieren, ich kann das ja (noch) nicht sehen...
Gruß Hayo
Sorry Hayo,
ich hab ja auch nur ein zweikanaliges Gerät. Aber ich drück
die Daumen, dass dein 4-Kanaler morgen ankommt. Bei mir hatte
Herr Wittig gut eine Woche gebraucht.
Gruß, Guido
So, jetzt hab ich mich hier auch mal angemeldet ;-)
Der X-Y-Modus funktioniert auch auf 3+4. Jedoch kann man nicht in den
X-Y-Modus, wenn Kanal 1 und/oder 2 deaktiviert ist. Auch funktioniert
hier der Offset noch nicht. Man muss beide Kanäle auf die Mitte regeln,
bevor man in den X-Y-Modus geht. Das klappt automatisch nur bei 1+2.
Fotos mach ich evtl. nachher noch und stelle sie rein.
MfG, Michael
@Michael
Danke für die Hinweise.
>wenn man im x-y-Modus zwischen Vektor- und Punkt-Anzeige umschaltet,>dann wird das Signal an der y-Achse gespiegelt!
Da hab ich doch tatsächlich nur den Vektorbetrieb korrigiert und den
Punktbetrieb vergessen -> wird gemacht.
Gruß Hayo
@Hayo
ich habe mir erlaubt die FW1.2.BF.0.50_beta.zip in die Google Groups zu
stellen, hier im Mikrocontroller Forum findet die keiner aus dem
internationalen Umfeld :-)
-lässt sich irgendwie ein ADC Abgleich durch den User verwirklichen?
Praktisch wäre sowas natürlich via Menü und Encoder... aber wohl zu
komplex und eher wieder was fürs VHDL Projekt?
Bei meinen Messungen (die schon schwer im Gange sind) ist mir
aufgefallen das wohl viele Probleme (z.B. das Rauschen) durch den
schlechten ADC Abgleich zumindest begünstigt werden.
Gruß
brunowe
P.S.: Anbei noch ein kleines "Stimmungsbild"
Hi Community,
hab die FW mal angetestet, die bisher beschriebenen Phänomene konnte ich
z.T. auch schon beobachten, aber was mir arg zusetzt ist der Trigger. Da
dies die erste FW ist, die ich installiere, weiß ich nicht obs an der FW
oder an der Hardware liegt.
Ich hab jetzt keine Ahnung ob der durch die FPGA- oder die
Softcore-Firmware beeinflusst wird, jedenfalls konnte ich auf eine
sporadisch auftretende Flanke (ein Taster, der an der Mittelabzapfung
eines Spannungsteilers einen Spannungssprung erzeugt) beim besten Willen
nicht triggern, während es bei periodischen Signalen problemlos klappt.
Ansonsten, danke für die FW :-)
Das mit dem Trigger ist mir auch schon aufgefallen. Jedoch meine ich das
es nur bei CH1 extrem war und die anderen funktionierten. Werde das aber
heute Abend nochmal ausprobieren.
Bei mir klappt das angegebene Experiment auf keinem der Kanäle. Auch
nicht mit Puls-Trigger, welcher ja eigentlich noch besser geeignet wäre
für so was. Und auch bei keiner Timebase-Einstellung.
Okay, ich habe dem Projekt bereits meine Hilfe angekündigt, da weiß ich
ja jetzt wo was zu tun ist :-)
Hi,
bin aus dem Osterurlaub zurück und - Überaschung - das W2014 ist da.
Also, alles wird gut. Übrigens steht auch nur W2014 (ohne A) auf dem
Gehäuse, ich vermute mal das da alte Restbestände an Gehäusen oder
Labels verwendet werden. Die Hardware scheint aber aktuell zu sein.
Hab erstmal das komplette Flash gesichert, wer also seins zerschossen
hat kann gerne anfragen.
@Andreas
Mach mal erstmal noch nichts wegen des Triggers. Wie ich schon im readme
beschrieben habe hängt das unter Umständen mit der Deaktivierung des
Zeroshifts zusammen, den ich wegen des Nullabgleichs vorgenommen hatte.
Zur nächsten Beta werde ich das wieder aktivieren, ab da wird es dann
wirklich interessant wegen Nullabgleich, Trigger und Cursor. Der
derzeitige Stand ist nur ein Zwischenstand. In der nächsten Version
werde ich ebenfalls mal die Funktionen von Kanal 3 + 4 prüfen und
überarbeiten.
Gruß Hayo
@Hayo,
nochmal zum Trigger: wenn ich den Trigger auf AC stelle, klappts.
Seltsam, da ich überzeugt bin, dass der Trigger auch bei DC-Coupling
auslösen müsste, wenn ich den Triggerpegel zwischen H- und L-Level des
Signals lege.
Och egberto...
wie oft hatten wir das denn schon?
Lese doch einfach mal die alten Posts.
Tipp: Welec Updater... (wenn du "nur" mit Hayo's FW spielen willst...)
Ok, ich war zu faul.....wollte aber auch auf Nummer sicher gehen - ob
ich dann auch alle Parameter etc. mitnehme.
Ich werd dann wohl mal lesen (müssen)
Schönes WE,
egberto
Bruno We wrote:
> wie oft hatten wir das denn schon?> Lese doch einfach mal die alten Posts.
Macht doch mal einen Artikel draus. Schliesslich breiten sich die Geräte
hier ja nun doch etwas aus, und jedem neuen Nutzer nahezulegen, 100e
Posts in mehreren Threads zu lesen... hust ;)
/Hannes
Liest eigentlich keiner das readme das ich dem FW-Update beigelegt habe?
Da steht doch alles drin und der Updater ist doch auch schon dabei.
Also hier noch mal zum Mitschreiben im Detail.
Backup erstellen:
- DSO und PC mit dem seriellen Kabel verbinden - beide anschalten!
- den Welecupdater starten, in der Parameterauswal (Pfeiltaste neben dem
grünen IC-Symbol) den Adressbereich einstellen.
- Komplettdump 00040000 bis 007FFFFF davor steht nichts drin und danach
fängt das RAM an.
- FW-Dump 00040000 bis 000DFFFF
- Config, protected Config und Signalspeicher 000E0000 bis 007FFFFF
- Am DSO die linken beiden Funktionstasten unter dem Bildschirm drücken,
es wird erst weiß dann schwarz - der Germs-Monitor ist aktiv
- Beim Welec-Updater den Download starten
- Nach dem Download mit dem Speichernbutton (Diskettensymbol) den Dump
in eine Datei speichern
Dump wieder zurückspielen:
- Am DSO die linken beiden Funktionstasten unter dem Bildschirm drücken,
es wird erst weiß dann schwarz - der Germs-Monitor ist aktiv.
- Beim Welec-Updater den Upload starten, die Flashdumpdatei auswählen
und den Upload bestätigen.
- wenn der Upload fertig ist kommt entweder eine Timeoutmeldung
(Übertragungsfehler) oder die Meldung "Fertig". Beides ist gut.
- danach DSO auschalten und dann wieder einschalten - das war es
Gruß Hayo
Danke!
Deine Beta wollte ich ja sonst erst auspacken, wenn ich das Backup
habe.....
Mal sehen, ob ich heute noch dazu komme (ich muß mir ja auch die
originale Firmware erst mal etwas anschauen!).
Viele Grüße,
egberto
@Hayo,
der WelecUpdater hat bei mir erst funktioniert nachdem ich den Pfad auf
die .flash-Datei in der .ini-Datei angepasst hatte, erst dann wurde der
Download-Button grün (war davor disabled). Hat mich ne ganze weile
gekostet das herauszufinden, da der Pfad absolutcodiert auf das
Verzeichnis C:\Temp zeigt. Evtl. sollte in einem Future-Release ein
relativer Pfad (z.B. ".\tomcat.flash") angegeben werden.
Hi,
der Welecupdater ist von Markus geschrieben worden, daher
Änderungsvorschläge direkt an Ihn richten. Ansonsten kann ich aber in
zukünftigen Betareleases auf diese Eigenheiten hinweisen.
Ach ja, eine Frage - ich habe gerade eine Zwischenversiomn fertig, bei
der ich die XY-Funktion bzw. die Menüsteuerung angepasst habe und auch
sonst noch einige Kleinigkeiten in Bezug auf die Vierkanalfunktion
geändert habe. Soll ich die hier einstellen, oder lieber bis zum
nächsten größeren Release warten?
Gruß Hayo
Hi @Hayo,
also angesichts der Tatsache dass jede FW, insbesondere die originale,
mit einigen Bugs behaftet ist, nehme ich jedes Release gerne an, solange
es keine anderen Funktionen außer Kraft setzt. Außerdem ist das W2024A
mein einziges Oszi, über jede Verbesserung an meinem
oszillographierenden Messknecht bin ich froh :-) Gerade die
Menügeschichten klingen nützlich.
Ich denke auch, so lange nicht neue Baustellen aufgerissen werden
sondern Dinge korrigiert - nur raus damit.
Nebenfrage: Ich habe das Teil ja erst seit Freitag (bin also noch in der
"Gewöhnungsphase), gibt es eine Möglichkeit die Samplerate runter zu
setzen (zwecks Vergleich mit meinem OWON)? Dann müsste sich doch auch
das (sichtbare) Rauschen verringern?
Viele Grüße,
egberto
So, hier wie angekündigt die vorgezogene beta 0.54.
Highlights sind:
- neue Timebase 5ns -> Trigger stimmt hier noch nicht
- manuelle Abgleichfunktionen für DAC und ADC
- neu implementierter Zeroshift
- diverse Bugs die Ihr mir gemeldet habt sind behoben
(Invers-Bug, Triggeroffset etc.)
einige Sachen sind leider noch offen, da ich wegen der etwas
überhasteten Veröffentlichung keine Zeit mehr zum Testen und korrigieren
hatte.
Dem Paket habe ich auch eine aktualisierte Anleitung für das Erstellen
eines Backups und die Handhabung des Updaters beigefügt.
Die Kurzanleitung für den manuellen Abgleich findet Ihr am Ende des
Readme. Für diese Funktionen braucht Ihr auf jeden Fall ein
Terminalprogramm. Wenn es dazu noch Fragen gibt immer raus damit.
Gruß Hayo
So, hab die FW grade mal draufgeflasht (ist ja in Verbindung mit dem
Backup ein abendfüllendes Programm :D) und werd dann mal bissi
rumspielen.
Was mir grade wieder auffällt: wäre es nicht sinnvoll, wenn durch Wählen
des aktiven Kanals auch gleich diese Triggerlevelmarke mit zum aktiven
Channel wechseln würde? Wenn ich Kanal 2 auswähle und dann am
Triggerlevel rumdrehe, ändert sich nach wie vor der Triggerlevel von
Kanal 1. Find ich irgendwie umständlich.
/Hannes
Gerade habe ich die neue Firmware geflasht - gibt's eigentlich keine
Möglichkeit, das über USB zu erledigen? Junge, Junge...
Die Kallibrierung:
beim vierten Kanal ist das Rauschen sehr gering gewesen, nach oben
hin(3,2,1) immer stärker...
Ich muss mich erstmal intensiver mit dem Teil beschäftigen (Spruts USB
PIC Brenner z.B. der hat bei mir eine zu hohe Brennspannung...). Die
Anzeige scheint mir aber immer noch sehr langsam. Slog soll ja bis zu
70(!) Frames/s mit dem neuen FPGA-Design hinbekommen...
Heute (gestern) hatte ich auf der Hannovermesse ein LeCroy in Action
gesehen - huuuh, ganz andere Liga, 15k€...
Michel
Hey,
@Slackman: warum das über USB nicht geht, frag ich mich auch jedes
mal...
Hat schon einmal jemand versucht, die neue FW einfach in die Original
Flash reinzukopieren (nach den Bootlader) und dann via original
W2000-update hoch zu laden? Ja ich weiß- original sind S2 Code- Zeilen
mit anderem Adress- Aufbau... war ja nur so ein Gedanke.
Wüsstest du das Lecroy derzeit eine Oszi- Abwrackprämie anbietet (ich
glaub 3000€- für Oszis ab 12k€) da kannst du dir jetzt direkt ein
Schnäppchen holen.
Gruß, brunowe
Johannes Studt wrote:
> Was mir grade wieder auffällt: wäre es nicht sinnvoll, wenn durch Wählen> des aktiven Kanals auch gleich diese Triggerlevelmarke mit zum aktiven> Channel wechseln würde? Wenn ich Kanal 2 auswähle und dann am> Triggerlevel rumdrehe, ändert sich nach wie vor der Triggerlevel von> Kanal 1. Find ich irgendwie umständlich.
Der aktive Kanal muß aber nicht unbedingt der Triggereingang sein! Daher
wäre es ja nicht sinnvoll die Triggersource einfach zu wechseln. Es
kommt ja auch vor, dass auf dem einen Signal getriggert und das andere
begutachtet wird.
Was man natürlich machen könnte, wäre beim Abschalten eines Kanals
gegebenenfalls die Triggersource automatisch auf den nächsten aktiven
Eingang zu legen.
Michael Werner wrote:
> Gerade habe ich die neue Firmware geflasht - gibt's eigentlich keine> Möglichkeit, das über USB zu erledigen? Junge, Junge...
Klar ginge das. War auch schon mal angedacht. Falk und Markus hatten
sich hierzu schon Gedanken gemacht. Da scheint aber noch nichts passiert
zu sein. Ich selbst bin mit USB nicht so gut vertraut und habe mich
daher erstmal auf die Firmware konzentriert.
> Die Kallibrierung:> beim vierten Kanal ist das Rauschen sehr gering gewesen, nach oben> hin(3,2,1) immer stärker...
Ja das sieht bei mir auch so aus. Das fällt einem bei der originalen FW
nur nicht so auf.
> Die Anzeige scheint mir aber immer noch sehr langsam. Slog soll ja bis zu> 70(!) Frames/s mit dem neuen FPGA-Design hinbekommen...
Stimmt, das liegt daran, dass im WELEC (Referenz) NIOS-Design keine
extra Multiplikationseinheit vorgesehen ist (es gibt auch ein Design mit
extra Multiplikator). Nun muß ich aber um die Anzeige genau zu machen
pro Meßwert eine Floating Point Multiplikation durchführen - das kostet
Zeit.
Die original WELEC-Firmware erkauft sich die Geschwindigkeit mit hoher
Messungenauigkeit! Meßt mal die genauen Pegel mit einem geeichten
Multimeter nach, dann wißt Ihr was ich meine. Besonders hoch sind die
Abweichungen in den 2er und 1er Bereichen.
Hier bin ich aber trotzdem dabei noch weiter zu optimieren.
Bruno We wrote:
> Hat schon einmal jemand versucht, die neue FW einfach in die Original> Flash reinzukopieren (nach den Bootlader) und dann via original> W2000-update hoch zu laden? Ja ich weiß- original sind S2 Code- Zeilen> mit anderem Adress- Aufbau... war ja nur so ein Gedanke.
Klar hab ich da schon rumexperimentiert. Leider erwies sich die
WELEC-Software als ziemlich zäh und widerborstig. Alle Möglichkeiten
habe ich hier sicher noch nicht ausgelotet - es besteht also noch
Experimentierpotential. Wenn jemand das hinkriegt, liefere ich die
Flashs auch gerne im WELEC-kompatiblen Format. An den Adressen liegt es
aber glaube ich nicht. Die kann man beim Updater von Markus vor dem
Download in der INI-Datei einstellen und damit eine entsprechende
Testdatei erzeugen.
Falls es nur daran liegen sollte, ist es wohl kein Problem einen
entsprechenden Kommandozeilenkonverter schnell zusammenzuklöppeln.
Gruß Hayo
Hayo W. wrote:
> Der aktive Kanal muß aber nicht unbedingt der Triggereingang sein! Daher> wäre es ja nicht sinnvoll die Triggersource einfach zu wechseln. Es> kommt ja auch vor, dass auf dem einen Signal getriggert und das andere> begutachtet wird.
Hm, da hatte ich einen Denkfehler drin. Ich war irgendwie der Meinung,
dass jeder Kanal unabhängig voneinander getriggert wird, aber das ist ja
Unfug.
> Was man natürlich machen könnte, wäre beim Abschalten eines Kanals> gegebenenfalls die Triggersource automatisch auf den nächsten aktiven> Eingang zu legen.
Das passiert immerhin zwischen Kanal 1 und 2 schon jetzt.
/Hannes
Hi,
erstmal danke für die neue FW - funktioniert soweit gut, vor allem das
mit der Nulllinie freut mich.
Aber eine kleine Frage zum Updater: ist es normal, dass der Flashvorgang
mit Schreibfehlern endet? Das war jetzt mein 2. Updatevorgang, und am
Schluss gabs jedes mal Fehler und Retries. Das Oszi tut allerdings
trotzdem.
Wenn das nur bei mir auftritt werd ich mir die genaue Meldung beim
nächsten mal aufschreiben.
Hallo Hayo,
so, hab mich etwas mit der ADC Kalibrierung gespielt.
Interessant was zu erreichen wäre wenn...
Aber so ganz perfekt ist das Ganze nicht- entweder ist Ch1 ODER Ch2 gut
kalibriert!
Bruno We wrote:
> Hallo Hayo,>> so, hab mich etwas mit der ADC Kalibrierung gespielt.> Interessant was zu erreichen wäre wenn...> Aber so ganz perfekt ist das Ganze nicht- entweder ist Ch1 ODER Ch2 gut> kalibriert!
Ja die Kalibrierung bringt nicht immer die gleichen Ergebnisse. Nach
drei Durchläufen ist sie aber meistens konstant. Die automatische
ADC-Kalibrierung wird übrigens für alle Kanäle durchlaufen wenn die
"Search Zeros" Funktion benutzt wird (und zwar direkt vorher).
Bei der manuellen Kalibrierung läßt sich das für jeden Kanal einzeln
einstellen. In den ersten 15 Schritten (jedes Mal beim Drücken von
shift + Q wird ein Schritt weitergeschaltet) werden verschiedene
Kombinationen durchlaufen - dann kommt als letzter Schritt ein
automatischer Abgleich für den Kanal. Mit shift + Z kann man zum
nächsten Kanal schalten und das Spiel neu beginnen. Wenn man alles durch
hat, kann man das Ergebnis mit shift + O in den protected Bereich
schreiben - dann wird es beim nächsten Start wieder geladen.
Gruß Hayo
..und so lange verwendet wird, bis durch ein Aufruf der "Calibrate Zero
lines" alles wieder überschrieben wird?! ÄCHZ
Mit den möglichen 15 Kombinationen des manuellen Abgleich bekomme ich
den Abgleich des Kanal 1 übrigens nicht so gut hin, wie mit der autom.
Kalibrierung. Es scheint mir als ob die Anpassung mindestens eines ADC
nicht mit den 15 Kombinationen abgedeckt wird- d.h. der max Bereich der
Anpassung reicht für diesen ADC nicht aus.
Schade das die autom. Kalibrierung (auch bei mehrmaligen Versuchen)
nicht für beide Kanäle gleichzeitig zufriedenstellend arbeitet!
Aber die Darstellungen auf meinen obigen Fotos finde ich schon ok...
Wenn jetzt das Optimum des Ch1 mit dem Optimum des Ch2 kombiniert
wäre...
Auf jeden Fall kann ich jetzt gut weitermachen, danke!
Gruß, brunowe
Bruno We wrote:
> ..und so lange verwendet wird, bis durch ein Aufruf der "Calibrate Zero> lines" alles wieder überschrieben wird?! ÄCHZ
Nein, der protected Bereich wird definitiv nur mit shift + O
überschrieben. Dieser Bereich ist eigentlich nur für Factory Settings
vorgesehen - hier steht unter anderem auch die Seriennummer. Wenn ein
Zero-Abgleich durchgeführt wird, dann ist das nur temporär. Beim
nächsten Start werden wieder die Werte aus dem protected Bereich
geladen.
> Mit den möglichen 15 Kombinationen des manuellen Abgleich bekomme ich> den Abgleich des Kanal 1 übrigens nicht so gut hin, wie mit der autom.> Kalibrierung. Es scheint mir als ob die Anpassung mindestens eines ADC> nicht mit den 15 Kombinationen abgedeckt wird- d.h. der max Bereich der> Anpassung reicht für diesen ADC nicht aus.
Sorry, mir waren das einfach zu viele Kombinationen, da hab ich dann die
genommen, die bei meinen beiden Oszis am besten funktioniert haben.
Bei den Einserkombinationen hab ich noch alle sinnvollen genommen, bei
den 2ern hab ich dann nur eine Auswahl verwendet. 3er hab ich garnicht
berücksichtigt, obwohl diese natürlich auch nicht ausgeschlossen sind -
bei mir allerdings nicht auftreten (Bei mir 2110 und 1001).
Nenne mir doch mal die Werte die die automatische Kalibrierung ergibt,
dann kann ich die Kombination mit einbauen.
> Schade das die autom. Kalibrierung (auch bei mehrmaligen Versuchen)> nicht für beide Kanäle gleichzeitig zufriedenstellend arbeitet!
Da ich diese in den Standardablauf mit eingebaut habe sind meine
Möglichkeiten hier erstmal beschränkt - alles Weitere ist in Arbeit...
> Aber die Darstellungen auf meinen obigen Fotos finde ich schon ok...> Wenn jetzt das Optimum des Ch1 mit dem Optimum des Ch2 kombiniert> wäre...> Auf jeden Fall kann ich jetzt gut weitermachen, danke!
Es zeigt auf jeden Fall, dass man hier noch Einiges herausholen kann.
Gruß Hayo
Hallo Hayo,
nur zur akt. Diskussion: gib bitte noch mal einen Suchbegriff an, mit
dem diese Kalibrierung in hardware_t.cpp gefunden werden kann. Ich
hatte das schon mal angesehen, jetzt finde ich es nicht mehr.
Wenn Bruno eine Toolchain hat, kann er das leicht selbst probieren
(schien mir unproblematisch).
Ich danke mal für die neue Version und werde nächste Woche testen.
Gruß, Guido
Hallo,
ok, der protected Bereich wird mit "Zero Calibration Line" nicht
überschrieben- ist mir gestern nur so vorgekommen.
Meine optimale Kalibrierung für Ch1 ist 2340 (bzw. 3450 sieht auch recht
gut aus), für Ch2 0112. Ich hab die Einstellung für beide Kanäle jetzt
recht gut hinbekommen. Als nächstes will ich mal checken ob mein Kanal 2
auch auf ein Rauschen von ±1Digit zu bekommen ist. Das ist, glaub ich,
ein durchaus akzeptabler Wert.
Mein Kanal 1 sieht jetzt echt gut aus... nur schade das da noch keine
Analog-Stufen dranhängen!!!
Gruß, brunowe
@Guido
In hardware_t.cpp Zeile 3258 - das ist der Buttonhandler
(Suchbegriff Test Funktion 0 Q)
@Bruno
2340 ist aber echt heftig! Da kann ich mir gut vorstellen wie das Signal
unkalibriert aussieht...
Wenn Du in das oben genannte Coding gehst, kannst Du Dir eigene
Kombinationen dazubasteln. Ansonsten werde ich Deine mal mit aufnehmen
für die nächste Version.
Ich habe übrigens gerade festgestellt, dass es nicht 15 Kombinationen
sind, sondern 26 (ich war noch in Gedanken auf dem alten Stand) - die
27igste ist dann Autokalibrierung.
Gruß Hayo
Hallo,
es ist (zum Glück) nicht notwendig das ich im Code herum operiere. Ich
habe via auto calibration den optimalen Abgleich für Ch1 erstellt, dann
manuell den Abgleich für Ch2 durchgeführt und das Ganze mit Shift O
abgespeichert- scheint zu funktionieren. Eine sehr gute Basis fürs
weitere Vorgehen!
Gruß brunowe
Anmerkung:
bei 10mV Eingangsempfindlichkeit (wie bei Bruno We) sieht es bei mir
nicht so gut aus - am Besten klappt es anscheinend bei 50 mV (bei 100 mV
ist es schon wieder schlechter).
Viele Grüße,
egberto
Genau, am besten ist es immer in den "5er" Messbereichen, also 5V,
500mV, 50mV, am schlechtesten sieht es in den "1er" Messbereichen aus.
Ich bekomme es auch manuell nicht so hin wie Bruno.
Wie ist da eigtl die Vorgehensweise? Aus den Zeilen, die da im Terminal
erscheinen, einen Mittelwert je DAC bilden und dann den Ausgleich
errechnen? Ich hab jetzt nur der Reihe nach alle Kombinationenn
durchgedrückt und geschaut, wo es am hübschesten aussieht.
Irgendwie kommt es mir so vor, als wenn ich da irgendwas noch nicht
begriffen habe. :D
/Hannes
hallo bastelfreunde
zu aller erst mal ein großes HUT AB und DANKESCHÖN an hayo, bruno und
die anderen entwickler die so viel arbeit und zeit in dieses projekt
investieren.
seit vorige woche bin ich auch besitzer eines w2024. die entwicklungen
hier im forum verfolge ich nun schon seit ein paar tagen. mich erstaunt
wieviel potential wittig bei dem gerät verschenkt hat. wenn es also was
zu testen gibt stehe ich gern zur verfügung. ich schrecke auch vor
hardwarebastellein am gerät nicht zurück. als vergleichsgerät steht ein
lecroy 9400 zur verfügung. ein paar kenntnisse in C sind auch vorhanden.
grüße sunny
Hallo sunny,
na dann erstmal herzlich willkommen. Vielleicht hast du ja Lust etwas
mit an der HW rumzubasteln? Momentan bin ich anscheinend der Einzigste,
dessen Oszi schon seit Tagen auseinandergebaut am Arbeitsplatz liegt und
für Messungen an Herz und Leber herhalten muss?! Für Unterstützung und
evtl. für Vergleichsmessungen wäre ich durchaus dankbar!
Evtl. meldest dich ja mal via Skype bei mir? Skype- Name: brunowe1
Hallo Bruno We,
auch wenn wir (die primär nicht an der Hardware arbeitenden) dich nicht
direkt vorwärts bringen können- könntest du so etwas wie eine kurze
Abgleichanleitung mit etwas Hintergrund (warum z.B. entsteht durch
schlechten Nullinienabgleich eine Schwingung mit 250 Mhz?) hier rein
stellen?
Neben Johannes und mir gibt es bestimmt noch mehr Einsteiger in die
Thematik.
Viele Grüße,
egberto
Hallo egberto,
mir ist leider nicht ganz klar was du mit Abgleichanleitung meinst.
Wie ich meine ADC abgeglichen habe? Eigentlich ist das da nicht viel
dabei...
Ist doch alles in der Liesmich von Hayo's FW, (evtl. in meinen
Messprotokollen- wg. 250MHz Schwingung) und in diversen anderen,
öffentl. verfügbaren Dokumentationen nachzulesen.
Ich denk mir, wer sich ernsthaft mit der Materie auseinandersetzen will,
sollte sich vlt. erstmal die HW Beschreibung auf SF ansehen.
http://apps.sourceforge.net/trac/welecw2000a/
Wir haben uns viel Arbeit gemacht alle Info's über die W2000 Oszis in
unserem SF-Wiki abzulegen- nutzt sie.
Ich bin überzeugt, das dir dann sofort klar wird wie es zu den 250MHz
kommt.
Nur so nebenbei... auch mit der Niederschrift meiner Messergebnisse hab
ich versucht etwas Klarheit in die Funktion des Oszi's zu bringen.
Noch ne Anmerkung: der etwas kompliziertere Weg des ADC- Abgleich wie
ich ihn oben durchgeführt habe, ist eh nur notwendig wenn mind. ein ADC
soweit aus dem Bereich raus ist, das er mittels Hayo's manuellen
Abgleich nicht korrigiert werden kann.
Gruß brunowe
Hallo Bruno We,
vielen Dank für die Antwort.
Es ist halt das alte Problem, man muss erst viele Dinge lesen (und
ellenlange Threads abarbeiten) um eine Antwort auf eine sich stellende
Frage zu erhalten.
Mir ist klar, das der Grat zwischen nerven der (kundigen)
Forumsteilnehmer und Aufgabe wegen zu hohem Einarbeitungsaufwand schmal
ist.
Darum die Bitte, auch mal eine doofe Frage wohlwollend zu beantworten -
das macht den Einstieg wesentlich leichter.
Viele Grüße,
egberto
Bruno We wrote:
> Ist doch alles in der Liesmich von Hayo's FW, (evtl. in meinen> Messprotokollen- wg. 250MHz Schwingung) und in diversen anderen,> öffentl. verfügbaren Dokumentationen nachzulesen.
Hm, ich hab zu diesem Punkt nix gefunden. Liegt vllt auch daran, dass
ich nicht ein Werkzeug entwickeln, sondern nur Verbesserungen, welche
andere daran vornehmen, verwenden möchte (s.u.) und dementsprechend nur
das Liesmich gelesen und nicht irgendwo im Netz in vielen Dokumenten
dazu nachgeforscht habe.
> Wir haben uns viel Arbeit gemacht alle Info's über die W2000 Oszis in> unserem SF-Wiki abzulegen- nutzt sie.
Versteh mich bitte nicht falsch: ich finde das absolut bemerkenswert,
was ihr hier macht, aber für mich ist das Gerät nicht Selbstzweck,
sondern Werkzeug. Ich helfe gern im Rahmen meiner beschränkten
Möglichkeiten, indem ich zum Beispiel nach einer vorgegebenen
Verfahrensanleitung eine OS-Firmware flashe, ein Paar Testpunkte
abarbeite und dann ein Ergebnis poste, aber mitentwickeln oder auch
nur mich in die Funktionsweise hineindenken möchte ich eigtl nicht.
Darum kann ich die Nachfrage von egberto uneingeschränkt nachvollziehen.
> Noch ne Anmerkung: der etwas kompliziertere Weg des ADC- Abgleich wie> ich ihn oben durchgeführt habe, ist eh nur notwendig wenn mind. ein ADC> soweit aus dem Bereich raus ist, das er mittels Hayo's manuellen> Abgleich nicht korrigiert werden kann.
Ich hab gerade ein paar Fotos gemacht vom Zustand nach dem Einschalten
und vom Zustand nach dem mehrfachen Ausführen von "Calibrate Zero
Lines". Ich finde, das bringt nicht nur nix, sondern verschlechtert
das Rauschen (von den unverändert abweichenden Zerolines mal ganz
abgesehen). Also mache ich entweder etwas grundlegend verkehrt, oder
dort ist ein Wurm drin.
/Hannes
P.S: Fotos poste ich gleich, muss sie nur noch zusammenfügen.
So,
jeweils ein Bild vom Zustand direkt nach dem Einschalten (erstes und
drittes Bild) und vom Zustand nach dreimaligem "Calibrate Zero Lines"
(zweites und viertes Bild) bei unterschiedlicher zeitlicher Auflösung.
/Hannes
Hallo,
mal eine Schnellanleitung für den ADC-Abgleich: Ihr müsst ein
Terminalprogramm über die ser. Schnittstelle mit 115,3 kBaud/8N1
anschließen. Oszi lange warmlaufen lassen (1 h oder so).
Einstellung für alle Kanäle: 5 V/div, 50 ns/div.
Unter Utilities-> Auto-Calibrate mehrmals durchführen.
Falls die Linien für die Kanäle unterschiedlich dick sind (sieht
aus wie Rauschen) im Terminalprogramm mit Shift+Z den gestörten
Kanal wählen. Dann immer wieder Shift+Q drücken und die Anzeige
beobachten. Mit jedem Tastendruck wird eine von 22 Kombinationen
eingestellt und ihr könnt euch für die optimale Entscheiden. Die
letzte Kombination ist wieder ein Auto-Zero, jetzt aber spez. für
den eingestellten Kanal. Habt ihr die optimale Kombination für
alle Kanäle eingestellt, könnt ihr diese mit Shift+O dauerhaft
speichern.
@ Bruno We: Ich verstehe überhaupt nicht, warum diese Kalibrierung
für die Kanäle unterschiedlich ist. Es sind doch dieselben Wandler?
@ Hayo: Sollen wir mal eine Sammlung an Kalibrierwerten anlegen?
In den den 1er-Bereichen habe ich jetzt einen bleibenden Offset,
2er- und 5er-Bereiche stimmen optimal überein. Kann (muss) man das
auch individuell kalibrieren.
@ all: Viele Spaß beim Experimentieren,
Gruß, Guido
Hallo
@Guido, ja es sind die selben Wandler. So wie ich das momentan sehe,
werden die ADC nicht extern mit einer Referenzspg. versorgt, sondern
nehmen als Referenz einfach die Hälfte der angebotenen Versorgungsspg.
Wahrsch. kommt diese Abweichung dann einfach durch Bauteilunterschiede
zustande.
@Johannes: Inwieweit die "Calibrate Zero Lines" für die 4 Kanäler gut
arbeitet kann ich nicht beurteilen. Das muss Hayo beantworten. Wenn du
dein erstes Foto mit meinem Foto von oben vergleichst, dann liegt beim
Einschalten dein Rauschniveau in etwa so wie bei mir auf Ch2. Mein Ch1
ist das Optimum (vom analogen Standpunkt aus betrachtet- ohne
nachträgliche digitale Bearbeitung)- da will ich meinen Ch2 in etwa
hinbekommen. Noch mal für alle (die die obigen Post's nicht gelesen
haben) bei meinem Ch1 wurde die Verbindung zum analog- Part der
Schaltung abgelötet- das ±1 Digit an Fehler wird also vom ADC bzw. von
der anschl. digitalen Verarbeitung erzeugt (eher unwahrscheinlich).
Man muss auch nochmal erwähnen das Hayo's aktuelle FW etwas überstürzt
heraus gegeben wurde, um genau diesen Punkt des ADC- Abgleich wenigstens
schon einmal experimentell durchführen zu können. D.h.man muss halt noch
ggf. gewisse Einschränkungen in der Bedienung hinnehmen. Irgendwann wird
dieser manuelle Abgleich der einzelnen ADC bestimmt nicht mehr notwendig
sein- weil ich überzeugt bin Hayo bekommt den autom. Calibrate Zero Line
gut hin!
Gruß, brunowe
Ja, dass du den analogen Teil der Eingangsschaltung abgetrennt hast,
hatte ich zwar gelesen, aber gleich wieder "verdrängt". Sorry. ;-)
Wie kann man sich erklären, dass Nulllage und auch Rauschen in den 5er
und 2er Messbereichen jeweils deutlich besser sind als in den 1er
Messbereichen? Im 1V/div-Bereich habe ich auf Channel 4 aller paar
Sekunden Rauschen im Bereich einer Div-Teilung, m.a.W. 1Vpp, und wenn
ich auf 500mV runterschalte, wird es verglichen damit recht glatt (genau
wie in der anderen Richtung, also bei 2V/div und 5V/div).
Die Nulllage ist bei 5er und 2er MB fast korrekt, bei 1er MB dagegen
ziemlich daneben, und ich kann sie auch mit ShiftW/E nicht verschieben.
/Hannes
Hallo Bruno,
wie hast du eigentlich Slog's Design ins Oszi gekriegt?
Habe ich das so richtig Verstanden?
USB Blaster installieren
Quartus Programmer installieren
Hello_W2000_v0_1_4.sof ins Oszi Programmieren
Jetzt sieht es so aus wie
http://www.mikrocontroller.net/attachment/49782/Ch1_ohne_R31uR32-Slog_V1_3_.jpg
Nach Neustart des Gerätes ist der Zauber wieder vorbei
USB Blaster deinstallieren, damit sich das Oszi wieder als HID meldet
Backup des 24C64 ist nicht nötig
Mfg,
Kurt
Hallo Hannes,
wie ich sehe hast du dich noch nicht wirklich mit der Materie und auch
noch nicht mit deinem Gerät beschäftigt.
Dir wäre dann nämlich aufgefallen, dass das Gerät nur über drei
Messbereiche verfügt. Man hört wie beim Umstellen des Messbereiches ein
Relais schaltet.
Dir hätte auch auffallen können, dass Wittig/Welec die optimale
Darstellung der Signale in ihrer Produktbeschreibung bei 5V/500mV/50mV
angibt.
Die Summe der so gesammelten Informationen führt dann zu der
unglaublichen Erkenntnis, dass die 2V/1V Darstellung nur eine
Vergrößerung der 5V-Messung sind, 200mV/100mV der 500mV-Messung und wer
hätte das gedacht, die 20mV/10mV die der 50mV-Messung. ;)
Gruß, branadic
branadic wrote:
> wie ich sehe hast du dich noch nicht wirklich mit der Materie und auch> noch nicht mit deinem Gerät beschäftigt.
Du wirst lachen, nein. Ich mach das hier nur nebenher mit, während ich
ein Layout zu Papier bringe. :)
> Dir wäre dann nämlich aufgefallen, dass das Gerät nur über drei> Messbereiche verfügt. Man hört wie beim Umstellen des Messbereiches ein> Relais schaltet.
Doch, das ist mir aufgefallen. Ich hab nur nicht tiefschürfend darüber
nachgedacht, an welcher Stelle da etwas umschaltet.
> Dir hätte auch auffallen können, dass Wittig/Welec die optimale> Darstellung der Signale in ihrer Produktbeschreibung bei 5V/500mV/50mV> angibt.
Ist wirklich an mir vorbeigegangen, stimmt.
> Die Summe der so gesammelten Informationen führt dann zu der> unglaublichen Erkenntnis, dass die 2V/1V Darstellung nur eine> Vergrößerung der 5V-Messung sind
Das dachte ich mir schon, aber 1V/div sieht eben nicht aus wie eine
Vergrößerung der 2V/div-Darstellung, weil sich auch die Nullage gewaltig
verschiebt und das Rauschen nicht nur doppelt so groß, sondern
unverhältnismässig größer wird. Daher frug ich. :)
> 200mV/100mV der 500mV-Messung und wer hätte das gedacht, die 20mV/10mV> die der 50mV-Messung. ;)
Das wiederum wird dann selbst mir klar.
Bin zwar kein Elektroniker, aber auch kein Depp. :D
/Hannes
Sehr interessant - das mit dem abgetrennten Kanal hatte ich auch
verdrängt; über die 1V/2V/5V Thematik hatte ich noch nicht nachgedacht,
allerdings wäre ich nie auf den Gedanken eines "Softwaretricks"
gekommen.
Wieder eine Anfängerfrage: Was genau verbessert SLOGs FPGA Design? (ist
wohl noch sehr beta, sonst hätten es ja alle fest installiert..) (bitte
sagt jetzt nicht, ich soll das russische Forum durcharbeiten ;-)!)
Vielen Dank für die Infos....
egberto
Danke branadic!
Slog's Design verbessert wohl hauptsächlich die Geschwindigkeit weil es
Hardwaremultiplikationen ermöglicht und auch die Abfrage der
Bedienelemente in Harware realisiert. Dadurch wird die CPU stark
entlastet.
http://www.kurts-werkstatt.de/wittig/slog.avi (3,21MB)
Das Video ist in Echtzeit! Man beachte die flüssige Verstellung von
Zeitbasis, Vertikalauflösung und Signallage. Viel mehr kann man
allerdings noch nicht machen, da sich Slog auf das FPGA Design
konzentriert und die Software entsprechend mager ausgerüstet ist
(Messungen sind nicht möglich).
Hier noch ein Foto.
Wieso habe ich nicht die bunten Sample Punkte der ADCs?
Probiert hatte ich
Slog_Project_with_Nios_v0.1.3.zip und
Hello_W2000_v0_1_4.zip
Hallo,
oje, ich weiß gar nicht wo ich mit den Richtigstellungen und Erklärungen
anfangen soll...
Vielleicht vorab noch ein Hinweis: Leute die sich nicht in die
Funktionsweise des Oszi's hineindenken wollen- s.h. Zitat weiter oben-
sollten am besten nicht weiterlesen! ;-)
Also erstmal, nehmt euch doch mal meinen Schaltplan des Oszi's zur Hand:
http://welecw2000a.sourceforge.net/docs/schematics/Analog-Input-Part_assignment.pdf
Das Umschalten zwischen den Bereichen 5V-2V-1V etc. ist kein SW Trick.
Links oben im Schaltplan seht ihr die beiden Relais die dieses
Umschalten erledigen- das Klack ist ja auch deutlich zu hören. Je
nachdem in welchem Messbereich ihr euch befindet wird das Eingangssignal
unterschiedl. stark gedämpft. Wenn ihr euch in 5V; 2V; oder auch 1V
befindet wird das Eingangssignal durch das Widerstandsnetzwerk von
Relais 1 bedämpft(geteilt) und zusätzlich durch das Netzwerk unter
Relais 2.
Befindet ihr euch in einem der Messbereiche 500mV, 200mV, 100mV, so ist
nur das Relais 2 in off- Position und teilt das verkleinert das
Eingangssignal ca. um den Faktor 10 (genaueres dazu steht recht
ausführlich in meinem Messprotokoll Nr.1)
Das bedeutet also, das jegliche folgende Signalverarbeitung auf die 3
Fälle 10mV, 20mV und 50mV Messbereich zurückzuführen ist. Die Teilung am
Anfang ist relativ problemlos und muss nicht weiter beachtet werden.
So, wie geschieht nun die Umschaltung zwischen 50mV, 20mV und 10mV? Auch
das ist kein SW- sondern ein Schaltungstrick. Ihr habt den Schaltplan
noch zur Hand? Unten in der Mitte befinden sich 3 Op's (AD8131) und
zwischen dem 1ten und 2ten, bzw. dem 2ten und 3ten unterhalb jeweils
elektronische Schalter (U7AD) (deshalb kein Klack!). Nur wenn der
Schalter geschlossen ist wird der nachfolgende AD mit einem
differentiellen Eingangssignal
versorgt und das Signal um den Faktor 2 verstärkt, ist der Schalter
offen liegt nur am positiven Input des AD das Eingangssignal an- seine
Verstärkung beträgt in diesem Fall 1.
Soweit findet in diesem Bereich also (abhängig vom Messbereich) ein 1:1;
1:2 oder 1:4 Verstärkung statt- ob jetzt durch einen weiteren Kniff das
wieder zu 1:2:5 hingebügelt wird wollte ich noch prüfen, glaub es aber
eigentl. nicht.
Zur Vollansteuerung der ADC ist an beiden (diff) Eingängen ein Signal
von ±0,3125V nötig- d.h. das Signal am positiven Ausgang des letzten AD
kann/ soll sich um ±0,3125V um den Mittelwert von +1,4V ändern, am
negativen Ausgang des AD ebenso, nur eben um π Phasenverschoben. Auch da
wollte ich nochmal checken inwieweit das passt.
Zu Slog's VHDL Design:
Prinzipiell muss man sagen das es mehrere funktionierende VHDL Designs
gibt, nicht nur die von dir oben erwähnten. Die VHDL Arbeit basiert
allerdings immer auf der großartigen Vorarbeit von Slog- er hat sich nun
mal als erstes mit Oszi intensiv auseinandergesetzt und es als VHDL-
Entwicklungsboard missbraucht.
D.h. den einzelnen VHDL Designs liegen ganz unterschiedl. Zielsetzungen
zu Grunde. Während der Eine über spezielle Aspekte der internen
Datenverarbeitung seine Masterarbeit schreibt- will der Andere "nur"
sein VHDL verbessern... aber das Gute daran ist, das man all diese
Arbeiten durchaus zusammenführen kann.
Alle VHDL Designs sind bislang nur temporär ausgelegt , d.h. nach dem
Ausschalten des Oszi's ist alles wieder weg (nicht weiter tragisch, das
aufspielen dauert ca. 10s!)- es werden keine Daten intern überschrieben
und man kann nichts kaputt machen. Das liegt einfach daran weil derzeit
von jedem Design nur spezielle Aspekte getestet/ entwickelt werden.
Und ja- man kann mit Slog die einzelnen ADC Werte farbig darstellen
lassen, so wie in meinem Foto im Messprotokoll 2. spiele dich einfach
mal mit den Tasten- wie gesagt du kannst dabei nichts kaputt machen-
maximal haben sie keine Auswirkung da sie halt via VHDL-Code nicht
verarbeitet werden. Das aktuelle Slog Design hat übrigens genau die ADC
Kalibrierung und vor allem das Timing der einzelnen ADC zum Thema-
deshalb diese schöne farbige Darstellmöglichkeit. Die Zeitbasis lässt
sich nicht verändern, ist glaub ich fix auf 50ns/Div eingestellt. (damit
müsste jeder gemessene ADC-Wert einem Pixel auf der zeitl. Achse des
Displays entsprechen.
so, jetzt ist aber erstmal genug-
Gruß, brunowe
Bruno We wrote:
> Vielleicht vorab noch ein Hinweis: Leute die sich nicht in die> Funktionsweise des Oszi's hineindenken wollen- s.h. Zitat weiter oben-> sollten am besten nicht weiterlesen! ;-)
Ich les trotzdem weiter. Nicht hauen bitte. :D
> Das Umschalten zwischen den Bereichen 5V-2V-1V etc. ist kein SW Trick.> [...]> Anfang ist relativ problemlos und muss nicht weiter beachtet werden.
Klar.
> So, wie geschieht nun die Umschaltung zwischen 50mV, 20mV und 10mV? Auch> [...]> Soweit findet in diesem Bereich also (abhängig vom Messbereich) ein 1:1;> 1:2 oder 1:4 Verstärkung statt-
Also wird das Rauschen hauptsächlich von diesen OPV und vllt noch den
elektronischen Schaltern bestimmt?
> ob jetzt durch einen weiteren Kniff das wieder zu 1:2:5 hingebügelt wird> wollte ich noch prüfen, glaub es aber eigentl. nicht.
D.h. dort wird dann das 1:4-Rauschen in Software auf 1:5 erhöht,
deswegen sieht das auch unverhältnismässig größer aus als bei 1:2?
Es ist übrigens schön, wenn einem das mal ein Berufener so erklärt, dann
versteht man auch gleich was (oder man beginnt wenigstens damit). In die
Schaltung allein habe ich geguckt wie die sprichwörtliche Sau ins
Uhrwerk.
Jetzt muss ich nur noch irgendwie die Trennlinie bzw. das Zusammenspiel
von dem, was Hayo macht mit dem, was Slog da bearbeitet, begreifen.
/Hannes
Hallo Buno We,
zur Spannungsverstärkung noch folgendes: Der OPA656 ist in der
Verstärkung zwischen 1 und 1,25 umschaltbar. So entstehen die
Gesamtverstärkungen von 1, 2.5 und 5. Das ist auch nicht ganz
uninteressant, da bei 1,25-facher Verstärkung eine Frequenzkompensation
für den OPA zugeschaltet wird, die die hochfrequenten Störungen etwas
reduziert.
@ Kurt: Danke für das Video, wirklich beeindruckend.
Gruß, Guido
Hallo Guido,
das mit dem Verstärkung des OPA656 war mir noch nicht ganz klar- (das
mit der Frequenzgangkompensation schon). Wie kommst du auf 1:1,25?
Klär uns doch mal über die Fkt. des OPA656 auf...
Alter Schwede hier ist ja was los...
Ich dachte ich hätte in diversen älteren Beiträgen schon mal auf den
Grund des unterschiedlichen Rauschens hingewiesen. Allerdings gebe ich
zu, dass es auch etwas nervig ist alle alten Beiträge durchzuforsten.
Daher möchte ich hier ergänzend zu Brunos Ausführungen mit wenigen
Worten die Problematik erklären:
- die einzelnen Stufen haben durchaus jede Ihre eigene
Spannungsvorteilung (wie Bruno ja auch schon anmerkte - kein Fake also)
- die Übersetzung ist jedoch so (unglücklich) gewählt, dass in den
unterschiedlichen Stufen bei der Grafikausgabe unterschiedliche
Skalierungsfaktoren nötig sind.
- bei den 5er Bereichen ist der Skalierungsfaktor ca. 2, bei den 2er und
1er Bereichen ist er ca. 3,3
D.h. wenn die Offsetabweichung eines ADC 3 ist (z.B. 3012 oder 0321),
dann stellt sich das in den 5er Bereichen mit eine Peak von 6 Pixeln
dar, wärend sich das in den anderen Bereichen mit einem Peak von 10
Pixeln darstellt.
Das ist schon ein deutlicher Unterschied.
Gruß Hayo
Hallo Bruno We,
wir sollten uns in den Hardware-Thread verziehen. :-))
Ist U3 am OPA656 geöffnet, bilden R21 und R14 seine Gegnkopplung.
Rechnerische Spannungsverstärkung 1,244, wird in der Praxis wohl
1,25 sein. Schließt U3, ist der OPA ein Impedanzwandler, in beiden
Fällen wirkt R14 auch als Mindestlast.
Durch ide Wirkung der Kompensation bin ich auf die Idee gekommen
mit Kondensatoren zu experimentieren. Leider halt ohne großen
Erfolg.
Gruß, Guido
Hallo Hayo,
wo findet denn die Skalierung der ADC-Werte statt? Ich finde es
nicht. Heute abend möchte ich mal mit den Verstärkungen spielen,
da müsste ich die Skalierung für die 1er und 2er Bereiche
ändern.
Danke, Guido
Guido wrote:
> Hallo Hayo,>> wo findet denn die Skalierung der ADC-Werte statt? Ich finde es> nicht. Heute abend möchte ich mal mit den Verstärkungen spielen,> da müsste ich die Skalierung für die 1er und 2er Bereiche> ändern.>> Danke, Guido
In der Datei tc_vars.cpp Zeile 1437 (float scale_factor[16])
Gruß Hayo
Hallo Hayo,
ich habe mal die Testfunktionen 1 und 2 so erweitert, dass sie
für den gewählten Test_Channel wirken. Die Einstellungen werden
im Protected_Flash angehängt.
Schau dir das bitte mal durch und pflege es ggf. in deine Quellen
ein. Bei meinem W2012A scheint es für beide Kanäle zu funktionieren,
ich habe 4 Kanäle vorgesehen, kann die aber nicht kontrollieren.
Über die Verstärkungseinstellungen berichte ich morgen, heute schaffe
ich wohl nicht mehr viele Tests.
Gruß, Guido
@Guido
ja das hatte ich ohnehin vor, aber da Bruno gerne schnell testen wollte
hab ich die Version etwas unfertig rausgehauen...
Wie ich sehe hast Du auch schon schön nach einzelnen Spannungsstufen
getrennt, kann ich dann ja so 1:1 übernehmen - spart Zeit ;-)
Danke und Gruß Hayo
Hallo,
habe mal eine Frage zur PC Software. Wie kann ich die gespeicherten
Messwerte bzw. Kurven mit der PC Software übertragen. Ich kann nur die
aktuelle Kurve in den PC laden.
Werde dann auch mal die FW1.2.BF.0.50 nach Flashsicherung aufspielen.
Aber das kann ja bekanntlich dauern...
Gruß
Ronny
Die Version FW1.2.BF.0.50 läuft auf meinem W2024A sehr gut. Habe dann
mal die FW1.2.BF.0.54 aufgespielt und das Nullinien-Rauschen war nach
einem "Calibrate Zero Lines" erheblich stärker auf Kanal 1-3, Kanal 4
war besser. Werde jetzt erstmal die vorige Version aufspielen und das
nochmal versuchen. Mauellen Abgleich der ADCs habe ich nicht
vorgenommen.
Gruß
Ronny
Nach Aufspielen der FW1.2.BF.0.50 und "calibrate zero line" ist das
Nullinien-Rauschen bedeutend geringer als mit FW1.2.BF.0.54, Kanal 3 ist
am Besten.
Hallo alle,
ich habe mir mal Gedanken zum Userinterface gemacht. Wenn jemand
Lust zum Testen hat ist eine Rückmeldung erwünscht. Ich habe nach
ca. 30 Flashvorgängen kein Gefühl mehr dafür wie es vorher war.
Zufrieden bin ich eigentlich nur mit der Triggerposition, die
läuft in ihrem begrenzten Laufstall imho sehr schön.
@ Hayo: Was ich geändert habe steht im zip unter anders2.txt. Das
ist sicher nur ein Proof of Concept und lässt sich mit Sicherheit
noch verbessern. Bei meinem momentanen Codeverständnis kriege ich
es aber nicht besser hin. :-(
Gruß, Guido
Guido schrieb:
> Lust zum Testen hat ist eine Rückmeldung erwünscht. Ich habe nach> ca. 30 Flashvorgängen kein Gefühl mehr dafür wie es vorher war.
30? Dauert das nur bei mir so lange, oder hast du jetzt echt ca. 40
Stunden dem Flashen zugeschaut?
/Hannes
Hallo Ronny Schmiedel,
was nutzt die USB-Übertragung, wenn das Gerät sonst nur sehr
eingeschränkt nutzbar ist? Ich habe mir das Welec eigentlich
auch deswegen gekauft, hilft aber nicht weiter. Also geh zum
Regal, nimm den K&R und lege los. :-)
@ Johannes: Nö, ne knappe halbe Stunde brauche ich noch zum
Flashen, habe als Linuxer aber extra (naja, nicht ganz ernst
nehmen) ein Laptop mit XP gekauft. Da macht man sich aber
natürlich Gedanken: das USB-Interface würde um keinen Deut
weiterhelfen, auch über RS232 kann es höchstens 2 Minuten
dauern die Daten zu Übertragen. Teste mal!
Gruß, Guido
Guido schrieb:
> @ Johannes: Nö, ne knappe halbe Stunde brauche ich noch zum> Flashen, habe als Linuxer aber extra (naja, nicht ganz ernst> nehmen) ein Laptop mit XP gekauft.
Hm, ich hab bisher mit dem fwupload.pl rumprobiert (bekomme ich nicht
ans Rennen) und dann in einer Virtualbox mit USB->RS232-Adapter. Das
funktioniert, dauert aber ca. 1,5h.
Auch auf die Gefahr hin, dass ich wieder darauf hingewiesen werde, dass
das alles schon mal schön übersichtlich irgendwo beschrieben steht: wie
muss das Oszilloskop auf das Schreiben der Zeilen der Firmwaredatei
antworten? Bei mir sagt das irgendwie keinen Mucks, deswegen bleibt
offenbar auch das fwupload.pl stehen und wartet bis zum
St.-Nimmerleins-Tag.
/Hannes
Johannes Studt schrieb:
> muss das Oszilloskop auf das Schreiben der Zeilen der Firmwaredatei> antworten? Bei mir sagt das irgendwie keinen Mucks, deswegen bleibt> offenbar auch das fwupload.pl stehen und wartet bis zum> St.-Nimmerleins-Tag.
Kaum sucht man nochmal, findet man plötzlich was: ein + sollte da
auftauchen, das ist wohl der Prompt des GERMS-Monitors. Eben schreibe
ich deine Flash-Datei mit Minicom ins Oszi, mal sehen, wie lange das
dauert.
/Hannes
Na juchhu aber auch. Eben hab ich bemerkt, dass der Welec-Updater von
Markus ja auch für Linux verfügbar ist. Nachdem ich jetzt bissi mit
Lazarus und Freepascal rumgezappelt habe, läuft das Ding hier
einwandfrei.
Das Leben ist schön. :D
/Hannes
P.S: ich liebe Monologe.
Johannes Studt schrieb:
> Guido schrieb:>> Lust zum Testen hat ist eine Rückmeldung erwünscht. Ich habe nach>> ca. 30 Flashvorgängen kein Gefühl mehr dafür wie es vorher war.>> 30? Dauert das nur bei mir so lange, oder hast du jetzt echt ca. 40> Stunden dem Flashen zugeschaut?
Hab jetzt über 100 Flashvorgänge hinter mir. Dauert ca. 21 Minuten pro
Durchlauf - allerdings mit echtem RS232 (auch an langsamen Rechnern).
Ich hatte unter Linux einen Kommandozeilenuploader entwickelt, der hat
es in 2 bis 3 Minuten geschafft, allerdings nicht zuverlässig genug. Da
hab ich dann irgendwann aufgehört und den WELEC-Updater genutzt, der ist
wenigstens zuverlässig.
Gruß Hayo
Johannes Studt schrieb:
> Na juchhu aber auch. Eben hab ich bemerkt, dass der Welec-Updater von> Markus ja auch für Linux verfügbar ist. Nachdem ich jetzt bissi mit> Lazarus und Freepascal rumgezappelt habe, läuft das Ding hier> einwandfrei.>> Das Leben ist schön. :D>> /Hannes>> P.S: ich liebe Monologe.
Ich mach das jetzt mal zum Dialog:
Die Linux-Version läuft bei mir mindestens zehnmal länger als die
Windowsversion. Wie ist das bei Dir?
Gruß Hayo
Da hab ich keinen echten Vergleich, weil ich die Windowsversion
ebenfalls unter Linux in einer XP-VM (und das zu allem Überfluss auch
noch mit dem USB->RS232-Adapter) laufen hatte. In dieser Konstellation
haben sie beide ca. gleich lange gebraucht.
Ich hatte bisher angenommen, dass das DSO der Part ist, der bremst, weil
ja der Welecuploader nix anderes macht, als auf das '+' zu warten und
dann sofort die nexte Zeile abzuwerfen.
Jetzt werd ich mal das Notebook meiner Frau zünden und mit der dort noch
anwesenden echten RS232-Schnittstelle Vergleiche anstellen.
/Hannes
Ja, das kannste vergessen. Am Notebook meiner Frau benimmt sich das DSO
bockig. Nach ca. 15% bricht die Datenübertragung ab und der Welecupdater
wartet, bis die Elbe austrocknet. Bis kurz vor den Hänger meint er, er
würde ca. 52 Minuten brauchen wollen (Windowsversion).
Ich werd's jetzt nochmal mit einer Linux-LiveCd versuchen.
Ja, ich habe ähnliche Erfahrungen gemacht. Ich habe unter Windows keinen
kompletten Download zustande gebracht(auf zwei verschiedenen Laptops
getestet). Unter Linux hat es dann geklappt, wenn auch etwas langsamer.
Der Upload klappte problemlos auch unter Windows.
Uwe
@Guido
Ich bin gerade dabei die Erkenntnisse der letzten Tage in die aktuelle
Version einfließen zu lassen. Deine Erweiterung der Testfunktion 1 + 2
hab ich unverändert übernommen. Die Änderung der Flashroutine hab ich
nicht übernommen, da die Zero-offsetwerte schon im normalen
Configbereich des Flash gespeichert werden. Eine weitere Speicherung im
Protected-Bereich ist also nicht nötig.
Insbesondere implementiere ich gerade die neue Integerscalierung - der
Upload läuft noch - ich bin gespannt was rauskommt.
Ansonsten beisse ich mir zur Zeit die Zähne daran aus diesen blöden
Freeze-Fehler zu finden der das Signal bei Zeitbasen größer 5ms
einfrieren läßt. Immerhin hab ich das Problem schon soweit eingekreist,
dass ich weiß, das ich mir den Bug zwischen version 0.32 und 0.33
eingebaut habe. Es kommt einfach vom ADC kein Data-Available-Signal mehr
an. Die berühmte Nadel im Heuhaufen...
Ich halte Euch über die Fortschritte auf dem Laufenden.
Gruß Hayo
Upload ist fertig,
erstes Ergebnis: Super! Genauigkeit ist genau wie bei der Floating-Point
Skalierung, aber die Geschwindigkeit ist im Einkanalbetrieb so schnell,
dass ich die Anzahl der Bildwiederholungen nicht mitzählen kann für
einen Vergleich.
Gefühlt würde ich sagen 2 - 3 Mal schneller.
Gruß Hayo
Hallo Hayo,
das hört sich ja gut an. Wegen dem Flash-Eingriff: Da habe ich
schlicht nicht kapiert was gespeichert wird und wollte sicher
gehen.
Mit dem Freeze: ich habe den Eindruck, dass eine Variable überläuft.
Wenn man ein paar mal rauf- und runterschaltet, werden immerhin
noch Teile des Bildschirms aktualisiert (in manchen Zeitbereichen).
Ich hänge noch mal die Erläuterung zu den Drehgebern an, ist zwar
suboptimal aber damit bekomme ich die Pfeile synchron zur
Drehung auf dem LCD aktualisiert. Ev. wäre das ja noch was für
die nächste Version.
Guido schrieb:
> Mit dem Freeze: ich habe den Eindruck, dass eine Variable überläuft.> Wenn man ein paar mal rauf- und runterschaltet, werden immerhin> noch Teile des Bildschirms aktualisiert (in manchen Zeitbereichen).
Das liegt daran, das bei Änderung der Zeitbasis der ADC-Durchlauf neu
gestartet wird, dadurch wird dann zumindist ein Signaldurchlauf gelesen
- das wars dann aber auch.
> Ich hänge noch mal die Erläuterung zu den Drehgebern an, ist zwar> suboptimal aber damit bekomme ich die Pfeile synchron zur> Drehung auf dem LCD aktualisiert. Ev. wäre das ja noch was für> die nächste Version.
Hast Du gesehen, dass ich einen ähnlichen etwas einfacheren Ansatz auch
schon implementiert habe? Bei irgendeiner User-Interface-Eingabe werden
alle weiteren Berechnungen und Ausgaben abgebrochen und erstmal der
Drehgeber ausgewertet. Dann erst wird weiter auf dem Schirm ausgegeben.
Das hab ich einfach mit einem Flag realisiert (UI_request), das in den
entsprechenden Interrupt-Serviceroutinen gesetzt und am Ende des
Hauptschleifendurchlaufs wieder gelöscht wird.
Gruß hayo
Hallo Hayo,
ja, das UI_request habe ich schon gesehen, aber es wirkt nicht
richtig. Deshalb meine Idee die Änderung in Tomcat anzusetzen.
Das wirkt dann auch und benötigt nur sehr wenige Änderungen.
Mit dem freeze: ich habe nicht den Eindruck, dass es voll
hängt (kann mich aber auch täuschen). Mir kommt es eher vor,
als ob die Grafikaufbereitung außerhalb des sichtbaren
Bereiches erfolgt (erst verschwindet 1/3 des Schirms, bei
größerer Zeitbasis dan 2/3 anschließend passiert garnichts
mehr).
Gruß, Guido
Nach meinen Vorankündigungen hier die aktuelle Beta. Neu ist die rein
integerbasierte Grafik, die entsprechend schnell geworden ist. Angepasst
ist die normale Siganlausgabe, der delayed Modus und die XY-Darstellung.
Die erweiterte Testfunktion 1 + 2 für den manuellen Nullabgleich von
Guido ist auch schon drin (ungetestet).
Morgen (bzw. heute) werde ich mich mal weiter dran machen und den blöden
Freeze-Bug suchen, damit ich mal endlich dazu komme die FFT weiter zu
machen.
guats Nächtle
Hayo
Hallo Hayo,
die Geschwindigkeit ist schonmal super. Vor allem im XY-Modus!
Wenn ich da jedoch die Vektordarstellung abschalte, verschwindet der
Nullpunkt.
Kurt Bohnen schrieb:
> Wenn ich da jedoch die Vektordarstellung abschalte, verschwindet der> Nullpunkt.
Danke für die schnelle Rückmeldung. Fehler ist schon lokalisiert, da ist
mir doch wieder so ein typischer copy and paste Fehler durchgegangen.
Ist in der nächsten Version beseitigt.
Gruß Hayo
Hallo,
ich bin seit einiger Zeit Besitzer eines W2014a und verfolge die
Entwicklung hier aufmerksam.
Ich habe gerade die Beta V0.55 ausprobiert. Der Unterschied in der
Darstellungsgeschwindigkeit ist echt beeindruckend.
Bezüglich des Flashens will ich mal meine Erfahrungen darstellen. Das
Flashen dauert bei mir ca. 15-20 min auf einem System mit Win XP und
einem USB-RS232-Adapter der Firma systec-electronic. Mit der "normalen"
RS232-Schnittstelle habe ich keine Verbindung mit dem Oszi bekommen.
Viele Grüße
Kristian
Hallo,
Kristian da kannst du dich glücklich schätzen- ich bin froh wenn ich's
so in 4-5 Std. hin bekomme- ist jedes mal ne Nacht füllende Aktion.
(Mit Delock Adapter USB to seriell)
Noch ein paar Fragen an die Programm-Kundigen:
Ich spiel mich gerade mit dem DAC Abgleich.
1.) Was bedeuten den die Zeilen:
CH1 Zero Sign Offs 1 = 2<\n>
CH1 Zero Sign Offs 2 = 0<\n>
CH1 Zero Sign Offs 3 = -1<\n>
(sind das die abgelegten DAC Werte für die Messbereiche 1:2:5 ?)
Irgendwie kann ich bei Shift +W bzw. auch bei Shift +E keine Änderung am
Welec Display erkennen (wohl aber an der Terminal Ausgabe)- schade- ich
hab da einen echt groben Offset.
Schön wäre es, die "Zero Level Werte" direkt eingeben zu können - für
jeden der Messbereiche 1:2:5er extra.
Sobald ich Cal. Zero lines durchführe, ist der offset zwar korrigiert,
aber leider auch meine Optimierung der ADC's futsch.
2.) Was hat den der Enable Debug mode für einen praktischen Nutzen?
3.)Was bedeuten den die Zeilen beim Start des Oszi, die auf dem
seriellen Terminal ausgegeben werden, speziell folgende:
...
Volt_Correct_float = 1.625<\n>
Scale Factor = 3.250<\n>
CH1_DAC_Offset = 8194<\n>
multi_active = 1<\n>
Auf dem Hardware Sektor gibts auch Neuigkeiten- werde ich später im HW
Thread posten.
Gruß, brunowe
Hall0 Bruno We,
zu 1): Die Zeilen geben die Zahlenwerte für die Offsets der
einzelnen ADC an, sollten also dieselben sein wie die, die
beim Shift+W drücken in einer Zeile angezeigt werden. Die
Änderung auf dem Bildschirm macht sich erst bemerkbar, wenn
du den Eingangswahlschalter hin- und wieder zurückdrehst.
Ich gehe so vor: Cal. Zero-Lines, Offset stimmt für einen
Bereich (norm. nehme ich einen 5er Bereich). Umschalten in
nächsten Bereich (2er) und mit Shift W optimieren. Als letztes
noch den 1er Bereich und dann speichern.
Gruß, Guido
He Folks,
erst mal abwarten. Ich hab mich in den letzten Tagen ordentlich
reingekniet um die Jungs an der Hardwarefront zu supporten. Nachdem ich
den ADC-Abgleich etwas nachlässig implementiert hatte, hab ich jetzt
Nägel mit Köpfen gemacht und einen Abgleich gemacht der für alle vier
Kanäle zuverlässig arbeitet. Weiterhin bin ich noch am DAC-Abgleich
zugange. Die Graphikausgabe hab ich nochmal optimiert, so dass die
Skalierung jetzt ganz ohne Multiplikation auskommt (merkt man im delayed
Modus).
Als Schmankerl hab ich die bisherigen Testschalter ins Utility-Menü
gelegt, so dass man sie bequem betätigen kann auch ohne Terminal
(ADC-Abgleich, DAC-Abgleich, Gridumschaltung, Graphikmodusumschaltung).
Die neue Version gibt heute Abend - mal sehen wie weit ich noch komme.
Gruß Hayo
@Hayo- das hört sich ja Spitze an!
@Guido: ich glaube du verwechselst da ADC Abgleich mit dem DAC Offset-
Abgleich!
Wie gesagt, den ADC Abgleich der einzelnen ADC pro Kanal hab ich jetzt
soweit im Griff, nur der generelle Offset stimmt eben nicht.
CH1 Zero Sign Offs 1 = 2<\n>
CH1 Zero Sign Offs 2 = 0<\n>
CH1 Zero Sign Offs 3 = -1<\n>
Diese 3 Werte können nicht die ADC Kalibrierungswerte der 4! ADC 's
sein, schon eher die DAC Offset Werte wie ichs vermute.
Gruß, brunowe
Bruno We schrieb:
> Wie gesagt, den ADC Abgleich der einzelnen ADC pro Kanal hab ich jetzt> soweit im Griff, nur der generelle Offset stimmt eben nicht.> CH1 Zero Sign Offs 1 = 2<\n>> CH1 Zero Sign Offs 2 = 0<\n>> CH1 Zero Sign Offs 3 = -1<\n>> Diese 3 Werte können nicht die ADC Kalibrierungswerte der 4! ADC 's> sein, schon eher die DAC Offset Werte wie ichs vermute.
Diese Werte sind die Offsetkorrekturwerte für die DACs, die den
Nullpunkt der Eingangs-OPVs steuern. Pro Kanal gibt es drei Werte, und
zwar immer für alle 5er Bereiche (Nr. 3) für aller 2er (Nr 2) und die
1er (Nr. 1).
Der DAC wird von 0 bis 16384 ausgesteuert, die Mitte des Grids liegt bei
8192 (idealerweise). Der Offset korrigiert mit einem entsprechenden
Faktor diese Nulllage.
Bin mit dem DAC-Abgleich schon recht weit, teste nur noch kleinere
Änderungen.
Die 0.56 gibts dann nachher...
Gruß Hayo
So hier ist sie, bin mit dem DAC-Abgleich nicht ganz fertiggeworden.
Aber seht selbst - geht nach dem flashen einfach mal ins Utility Menü
und probiert es aus. Wenn Ihr die ADC-Werte sehen wollt die der
Abgleichermittelt, dann müßt Ihr ein Terminalprogramm laufen lassen, da
werden dann die ermittelten Werte ausgegeben.
Ansonsten wie gesagt habe ich die Grafikroutine nochmal beschleunigt -
sieht man im Normalbetrieb nicht so deutlich, aber im Delayed-Mode wo ja
doppelt so viele Signale geschrieben werden merkt man es schon.
Viel Spaß
Hayo
Bin immer noch am DAC-Abgleich. Leider ist das ziemlich Zeitaufwändig,
da man nach jeder Kleinigkeit die man testweise ändert warten muß bis
die Firmware wieder geladen ist bevor man weitermachen kann. Bin aber
schon recht weit.
Übrigens geht der DAC-Abgleich schon so ein bißchen wenn man vorher die
Nulllage des entsprechenden Kanals auf die Mitte des Grids stellt.
Hat es schon jemand ausprobiert?
Gruß Hayo
Hallo Hayo,
ich habe letzte Nacht noch schnell probiert, aber ohne Erfolg.
Ich hatte übersehen, dass die Linien in Schirmmitte sein
müssen und so hat jeder Tastendruck den Offset um 1 div nach
unten verschoben. Geht das momentan nur für Kanal 1 oder wie
kann man umschalten? Aufgefallen ist mit, dass dieser Abgleich
jetzt eh nur noch für die 1er Bereiche nötig sind die 2er
stimmen nach AutoZero im 5er Bereich auch. Zufall?
Gruß, Guido
Guido schrieb:
> Hallo Hayo,>> ich habe letzte Nacht noch schnell probiert, aber ohne Erfolg.> Ich hatte übersehen, dass die Linien in Schirmmitte sein> müssen und so hat jeder Tastendruck den Offset um 1 div nach> unten verschoben. Geht das momentan nur für Kanal 1 oder wie> kann man umschalten?
Nein, geht für alle Kanäle gleichzeitig.
> Aufgefallen ist mit, dass dieser Abgleich> jetzt eh nur noch für die 1er Bereiche nötig sind die 2er> stimmen nach AutoZero im 5er Bereich auch. Zufall?
Nein, hab an der ursprünglichen Zero-Routine auch ein paar Kleinigkeiten
geändert.
Die Search Zero und die Calibrate DAC Funktion haben zwar das gleiche
Ziel, arbeiten aber völlig unterschiedlich. Ich bin mir noch nicht ganz
sicher, ob Calibrate DAC die alte Funktion komplett ersetzen wird oder
nur für's Feintuning als Zusatzfunktion bleibt. Mal sehen.
Gruß Hayo
Hallo Hayo,
hast du von der Software aus zugriff auf den Programm-Speicher? Evtl.
würde sich ein zweiter Bootloader rentieren, der den Speicher schneller
vollbringt. Ich stelle mir das Entwickeln bei den Upload-Zeiten ziemlich
langweilig vor ;-)
Wirklich ein super Projekt.
Gruß,
Stefan
Hallo Hayo,
Neue FW- Spitzenarbeit!!!
Super, mit dem erweiterten Menü- so stell ich mir das vor!
Jetzt noch den DAC Offset hinbügeln und dann "Beta" aus der Bezeichnung
streichen.
Also auch mein Rauschen ist, bedingt durch den tollen ADC- Abgleich,
wesentl. besser. (Seltsamerweise Kanal 1 jetzt viel besser als Ch2-
liegt auch tw. an meiner kleinen HW Modifizierung- lass mich bitte in
dem Glauben!)
Soweit ich's bisher testen konnte, echt erstklassige Arbeit von dir!
Gruß, brunowe
Hm,
bei mir wird das Rauschen immer nur schlimmer. Sobald ich die "Search
Zero Lines"-Funktion verwende, bekomme ich Rauschen im Bereich von einem
halben bis zu einem ganzen Div, je nach Messbereich und
Erwärmungszustand. Schlimm sind v.a. die Kanäle 3 und 4.
"Calibrate ADC" verändert an der Intensität des Rauschens im Grunde nix,
es verändert nur ein wenig die Form.
"Calibrate DAC" lässt die Nulllage je nach Messbereich mit jedem
Tastendruck um bis zu ein Div nach unten wandern, auch wenn ich vorher
die Nulllage aller Kanäle auf die Mitte drehe. "Search Zero Lines" fängt
das wieder ein, allerdings habe ich trotzdem auf den Kanälen 3 und 4
immer ein negatives Offset.
Mit dem Offset könnt ich leben, aber das Rauschen macht das Gerät in
meinen Augen ziemlich unbenutzbar.
Hallo,
frei nach dem Motto: "ein Bild sagt mehr als tausend Worte"
Meine aktuellen Rauschpegel mit der neuen FW nach ADC Calibration.
Probe- Klemme auf Gnd.
Hallo,
vielen Dank für die neue Firmware.
Bei meinem 2014A liegen die Kanäle 3 und 4 auch immer im negativen
Bereich (Kanal 3 ca. 500mV, Kanal 4 ca. 1V).
"Calibrate DAC" führt bei mir auch zu einer Verschiebung der Signale in
den negativen Bereich. Dies scheint aber stark vom jeweilig
eingestellten Spannungsbereich abzuhängen.
Das Rauschen erscheint bei mir (zumindest für Kanal 1 und 2) deutlich
verringert.
Bei mir fehlt die blau 3 neben der Anzeige der V/Div für Kanal 3. Die
Beschriftungen der anderen Kanäle sind vorhanden.
Gruß
Kristian
Ich krieg hier noch die Krise...
Muß erstmal etwas Frust ablassen, Hrmpf. Da tut die positive Rückmeldung
von Euch ganz gut. Bin immer noch an dem besch... DAC-Abgleich. Um die
Situatuion kurz zu schildern:
Vor dem Abgleich wird per Coding alles auf die Nulllinie (Gridmitte)
gefahren, dann der Abgleich durchgeführt. Trotzdem bleibt ein
Restoffset. Wenn ich die Nulllinien manuell auf die Gridmitte einstelle
klappt alles ordentlich. Ich hab alles dazwischen gecheckt und auch
schon eine Verzögerung eingebaut weil ich mir dachte dass die DACs
eventuell nicht schnell genug regeln - hilft nix.
Morgen hab ich leider nicht viel Zeit dafür, daher hier erstmal die
inoffizielle beta 0.57 nur als Flash zum ausprobieren.
Wie gesagt, wenn die Nulllinien auf Gridmitte sind reichen 2 - 3mal
Drücken und die die Lage stimmt. Bitte zu beachten:
- es wird zur Zeit nur der aktuell eingestellte Bereich
(1er, 2er oder 5er) calibriert.
- das Ergebnis wird zur Zeit noch nicht ins Flash geschrieben.
Gruß Hayo
Kristian Trenkel schrieb:
> Bei mir fehlt die blau 3 neben der Anzeige der V/Div für Kanal 3. Die> Beschriftungen der anderen Kanäle sind vorhanden.
Ja das passiert bei mir aber auch mit der aktuellen 1.4 FW von Welec. Da
das allerdings erstmal von der Prio her weit hinten rangiert werde ich
das noch nicht in Angriff nehmen (es sei denn ich stolpere zufällig
darüber.
Zur Zeit gibt es folgende Prio:
1. DAC-Abgleich
2. Den Freeze-Bug finden den ich mir in Version 0.33 eingebaut habe
(Signal friert ein bei Zeitbasen > 5ms)
3. FFT einbauen -> damit hat eigentlich vor einem halben Jahr alles
angefangen, aber bei all den Ungereimtheiten bin ich immer noch nicht
dazu gekommen...
Gruß Hayo
Johannes Studt schrieb:
> So denn, das ist Kanal 4.
Tja, da muß ich leider sagen, es ist nicht der ADC-Abgleich der hier
nicht hinhaut sondern hier dürften Störungen oder Eigenresonanzen
verantwortlich sein. Mein Kanal 4 sieht zeitweise noch viel schlimmer
aus. Die Bilder kennt Ihr ja schon. Da hilftnatürlich auch kein
ADC-Abgleich. Hinzu kommt, dass der ADC-Abgleich natürlich auch dadurch
gestört wird. Wie sieht denn Dein Kanal 3 aus? Der ist bei mir nämlich
glatt wie ein Babypopo.
Gruß Hayo
Darum habe ich auch jetzt meinen W2024 innerhalb des 14Tage
Rückgaberecht wieder zurückgeschickt. Bei mir war das Gleiche, das
Rauschen nahm nur zu. Hoffe für Euch, das Ihr das in den Griff bekommt.
Ich bin raus...
Ronny Schmiedel schrieb:
> Darum habe ich auch jetzt meinen W2024 innerhalb des 14Tage> Rückgaberecht wieder zurückgeschickt. Bei mir war das Gleiche, das> Rauschen nahm nur zu. Hoffe für Euch, das Ihr das in den Griff bekommt.> Ich bin raus...
Na sowas, das muß man sportlich sehen. Da ist halt recht viel
Optimierungspotential ;-)
Gebe allerdings zu, dass für professionelle oder semiprofessionelle
Anwendungen die WELECs nicht die erste Wahl wären. Aber für Hobbybastler
und Optimierer super bei dem Preis. Wenn ich jetzt auch noch Geld dafür
kriegte müßte ich mich nicht mehr "nebenbei" für SAP krumm machen.
@Hannes
warum macht Ihr eigentlich immer Bilder vom 10ns Bereich? Da muß man in
Gedanken immer die interpolierten Werte rausrechnen um sich ein Bild des
Werteverlaufs zu machen. Der 50ns Bereich ist da ideal, weil er die
Werte 1:1 wiedergibt bei voller Samplerate.
Gruß Hayo
Weil Bruno das so macht und ich keinen Plan habe, was für wen warum auch
immer am besten ist.
Sprich: hier einfach der Vergleichbarkeit der Bilder wegen.
Normalerweise[TM] mache ich auch andere Bilder.
Hallo,
@ Hayo, mach mal Pause, dann fällt es einem oft wie Schuppen aus den
Haaren. Den Ansatzpunkt (manuell versus auto) hast du ja schon.
Wegen dem Freeze suche ich auch noch mal, das ist aber wohl was
fieses kleines.
@ Johannes: Kanal 4 sieht wirklich schlimm aus. Eigentlich ist der
doch am weitesten von Netzteil entfernt, das Rauschen muss also
woanders her kommen. Kanal 3 kannst du besser einstellen. Da sieht
man noch die Abweichungen zwischen den ADCs (periodisch). Probier
mal mit einem Terminalprogramm (sofern nicht schon getestet).
@ Bruno We: jo, so etwa bekomme ich den Abgleich auch hin. Für
mich verfestigt sich der Eindruck, dass da ein Schwingen im
Eingangskreis stattfindet. Das ist kein Rauschen der Bauteile,
dafür ist es um Größenordnungen zu stark. Normalerweise würde
ich zu Ferritperlen raten, aber das geht in dem SMD-Layout wohl
nicht?
Gruß, Guido
Guido schrieb:
> woanders her kommen. Kanal 3 kannst du besser einstellen. Da sieht> man noch die Abweichungen zwischen den ADCs (periodisch). Probier> mal mit einem Terminalprogramm (sofern nicht schon getestet).
Ändert nix, damit habe ich schon rumgespielt. ;)
/Hannes
@ Guido,
wie wäre es statt Ferritperlen mit Ferrit Beads? Die gibt es für die
unterschiedlichsten Frequenzbereiche und in unterschiedlichen Packages.
Schau mal bei RS nach, da solltest du schnell fündig werden.
Gruß, branadic
Hallo,
der Grund warum ich Fotos im 10ns Bereich mache ist eigentl. ganz
simpel: ich hatte lange Zeit (und habe tw. immer noch) massive Probleme
mit HF Schwingungen, eben auch mit dem ADC Abgleich und mit einer NF
Überlagerung bei offenen Eingängen. Bei 50ns ist es sehr schwer eine
eine HF Frequenz auszuzählen und eine Regelmäßigkeit zu erkennen. Das
mit den interpolierten Werten stellt kein Problem bei 10ns dar, erstmal
geht es ja um die Minimas und Maximas der Anzeige- und die sind auf
keinen Fall interpoliert. Darüber hinaus fällt es bei 10 ns leichter die
Anzahl der wirklichen Sprünge abzuschätzen, also um wieviele Bit des ADC
die Anzeige des Display sich wirklich ändert. Als letztes möchte ich
auch das Verstärkerrauschen mit untersuchen, das ist nach bisherigen
Erkenntnissen in den 1er Messbereichen am grössten.
@Guido:
Ich antworte dir im HW Thread.
Gruß, brunowe
Ich bin echt beeindruckt!
Es ist schon genial, was hier die Entwickler und Tester auf die Beine
stellen. Mich juckt es ja so sehr, ebenfalls einen Welec zu ersteigern.
Aber ich habe für mein Hobby bereits einen Agilent 54622D und ich
vermisse bei dem Welec einfach die 16 digitalen Kanäle, ohne die ich
nicht leben könnte :)
Trotzdem mal ein paar Ideen für die ganze Offset/Zeroing Problematik,
gerade weil ich diesen Abgleich vom Agilent her ein wenig kenne.
Allerdings habe ich für dieses Gerät, trotz Vorzugspreis und so weiter,
einen aus Hobby-Sicht stolzen Preis bezahlt und es daher noch nicht
geöffnet.
Der Agilent fährt bei einer User-Calibration ein recht aufwändiges
Muster an Kurven durch, dem man auch zuschauen kann. Wenn Euch das
hilft, versuche ich mal davon ein Video zu machen. Es sind wohl einige
unter Euch, die aus den dargestellten Mustern rückschließen können, was
da eingemessen wird.
Was ich bei dem Welec bislang vermisse, ist ein Referenz-DAC, der zur
Kalibration aller anderen verwendet werden kann. Ist der noch irgendwo
verborgen, oder wurde der tatsächlich eingespart? Oder gibt es bei den
verschiedenen Multiplexern eventuell eine Stellung in der sie auf 0 und
eine, in der sie auf eine Vref geschaltet werden können? Dann kann man
eventuell den Gain-DAC dazu verwenden, die OVs auszumessen.
Es wundert mich doch sehr, dass es notwendig ist, die Strahlen auf Mitte
zu bringen, bevor man eine ZeroCal durchführen kann.
Eine softwaretechnische Frage wäre dann noch, ob der Welec seine
Software aus dem FLASH laufen lässt, oder ins RAM bootet und dort dann
arbeitet. Für die Entwickler wäre die Idee, einen weiteren Bootloader zu
schreiben sicherlich sehr hilfreich, der originiale scheint, ehrlich
gesagt, Murks zu sein. Das Flashen von 8MB dürfte nicht länger als max.
4min dauern.
Sollte sich jemand daran wagen, dann wäre es wohl sinnvoll, den
Bootloader ins RAM zu kopieren, große Blöcke ins RAM zu laden und von
dort aus zu flashen. Bitte beachtet dabei, dass die Toggle-Bits einiger
AMD/Spansion und Kompatibler erst nach ein paar ms gültig sind. Ist eine
Falle, die das Flashen enorm verlangsamen kann, wenn man diese zu früh
abfragt und dann in eine Fehlerbehandlung rennt, die nicht nötig ist.
Ich meine MX gehört zu den Spansion kompatiblen. Wenn das ganze ins RAM
kopiert wird, dann sollte der Bootloader das auch unterstützen, damit
man eine Software auch ohne Flashen mal schnell ausprobieren kann.
Hat jemand eine Info, in wie weit diese Scopes noch nachgefertigt
werden? Wenn Welec/Wittig nur noch Restbestände abverkaufen, und alles
deutet darauf hin, dass nur noch die Retouren aufgearbeitet und
abverkauft werden, was dann? Die Arbeit ist auf keinen Fall vergebens,
aber es wäre sicherlich besser, wenn man länger was davon hätte, auch
wenn ich nicht weiß, ob sich ein OpenSource Oscar auf dem Markt
durchsetzt.
Allerdings wäre das doch sicherlich ein interessantes Geschäftsmodell
für Wittig um seinen Laden zu retten. Ich hatte eigentlich gehofft, dass
er sich mehr für das Projekt einsetzen würde. Nun, auf der Sourceforge
Seite angekündigte Bereitstellung von Mustern an die Maßgeblichen
Entwickler ist ein Schritt in die richtige Richtung.
Ich verfolge das auf jeden Fall mal weiter, vielleicht kann ich mein
Hobby-Budget mal wieder aufstocken :)
Gruß, Ulrich
@Guido
wg. des Freeze-Problems bräuchtest Du die Sourcen der 0.32 und 0.33, da
läßt sich das am einfachsten herausfinden da ein direkter
Sourcenvergleich möglich ist. Guckst Du im Anhang...
Der Fehler ist mit Sicherheit in der Hardwareroutine zu finden, denn die
Grafikausgabe wird, wie ich schon rausgefunden habe, korrekt durchlaufen
- die Drehgeberroutinen übrigens auch. Der Grund warum keine neuen Daten
gelesen werden ist sekundär, dass das ADC_Data_Available Flag nicht
gesetzt wird und dann auch der ADC nicht ausgelesen wird (Handle_ADC()
Zeile 19418). Warum es aber nicht mehr gesetzt wird, das versuche ich
rauszukriegen. Müßte eigentlich eine Änderung sein die ich mit BF
gekennzeichnet habe.
@Bruno
ok, das kann ich einsehen. Für meine Zwecke benutze ich meistens die
50ns Einstellung da ich hier immer alle realen Punkte ohne Zommfaktor
zur Verfügung habe (deswegen hab ich auch das Freeze-Problem nicht
bemerkt).
@Ulrich
Mußte Deinen Beitrag noch ein zweites Mal lesen, da er so lang war, dass
ich am Ende nicht mehr wußte was am Anfang stand (Altersbedingt).
Also zum Bootloader: Das Programm läuft natürlich im RAM. Beim
Anschalten des DSO wird ein kleines Bootloaderprogramm aus dem Flash
geladen (steht an Adresse 0x00040000) dieses kopiert dann den Rest der
Firmware ins RAM (Adresse 0x00800000), von wo es dann gestartet wird.
Zur Flashgeschwindigkeit: Klar, ich hab es mit einem selbstgeschriebenen
Linux-Kommandozeilenprogramm in 3 Minuten geschafft. Leider war mir das
Programm nicht zuverlässig genug, da hab ich dann lieber das von Markus
genommen. Anscheinend ist es nicht so einfach ein RS232
Übertragungsprogramm zu schreiben, das auf allen Rechnern gleich gut
funktioniert (liegt wohl auch am Hardware Abstraction Layer). Bin aber
ganz froh, dass es überhaupt so gut funktioniert.
Zudem hatte ich anfangs auch nicht vermutet dass es sooo viel zu tun
gibt und ich innerhalb kürzester Zeit auf weit über 100 Uploads komme.
Zu den Abgleichkurven: Ja, immer her damit. Ich laß mich gerne von
Profilösungen inspirieren.
Gruß Hayo
@Ulrich
Ach ja, eins hatte ich noch vergessen, der Trend geht zum Zweitwelec ;-)
Da kann man schön vergleichen und kann auch mal eins zerlegen.
Gruß Hayo
Ok, kürzer :)
Hoffe ich kann das Video mit meiner kleinen WebCam ordentlich hin
bekommen und irgendwo hin uploaden.
Ich denke, dass es nötig ist, den Bootloader so zu erweitern, dass man
auch direkt ins RAM schreiben kann, falls das nicht ohnehin schon
unterstützt wird, damit man eine neue Software direkt testen kann (
Flashloader überspringen). Wegen der fehlenden FlashErase und
Schreibzyklen sollte das weit unkritischer sein und damit auch
unkritischer für die serielle Kommunikation. Wurde auf Seite des Wittig
eventuell das RTS/CTS Handling übersehen, oder hat der diese Leitungen
nicht angeschlossen?
Gruß, Ulrich
Ulrich P. schrieb:
> Es wundert mich doch sehr, dass es notwendig ist, die Strahlen auf Mitte> zu bringen, bevor man eine ZeroCal durchführen kann.
Das liegt daran, das ich einen anderen Ansatz verfolge als die Routine
von WELEC. Ist eigentlich ganz simpel. Ich prüfe einfach bei offenen
Eingängen die ADC-Werte. Diese müssen bei GND 127 betragen (oder 128 je
nachdem wo man die Nullinie hinlegt). Ich ermittle also nur die
Differenz zu den 127 und korrigiere dann den DAC-Wert um die Differenz
und einen Faktor. Da aber nur bei DAC-Nulllage auch 127 rauskommt, muß
ich vorher die DACs in die Nulllage fahren. Übrigens wird kein absoluter
Korrekturwert ermittelt, sondern der von der Search Zero Routine
ermittelte Wert wird nach oben oder unten korrigiert - ein Feintuning
sozusagen.
Gruß Hayo
egberto schrieb:
> Anfängerfrage (nicht hauen!) - womit commpiliert ihr das eigentlich?>> Was muß ich mir dafür installieren?
Du brauchst ein Linux-System dafür. Kann man ganz easy zusätzlich zum
Windows installieren. Bei mir hat es mit Open SUSE prima hingehauen (War
auch Linux-Anfänger). Ich hatte auch schon mal ein how to geschrieben,
ich hänge das hier nochmal an.
Viel Erfolg
Hayo
Ok, ich hatte jetzt noch nicht die Zeit die Datenblätter der DACs und
ADCs durch zu arbeiten. Aber normalerweise ist doch ein signed bei
0..127 positiv und bei 128..255 negativ, wobei 128 der -1 entspricht.
Allerdings nur, wenn man die Wandler ensprechend einstellt. Ich habe die
ganzen Threads innerhalb eines Tages durchgelesen, und meine mich
erinnern zu können, dass die Eingangsstufen die Messpannung auf
Wandlermitte anheben, also wird nur positiv gemessen.
Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da
die OVs der Eingangsstufe dann frei laufen. Gibt es keine Option, die
Stufe auf GND zu schalten? Das wäre schon mal ein Anfang. Optimaler wäre
es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten
zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs
kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige
brauchbare Referenz aller Kanäle gemeinsam?
Nochwas zum HP. Er führt die User-Calibration offenbar unter
Berücksichtigung der eigenen Temperatur durch, diese vermerkt er
jedenfalls in den Logdaten zur Cal. Viel mir nur gerade ein, weil einige
ja darüber klagten, dass der Welec nur bei bestimmten Temperaturen
sauber funktioniert. Vermutlich fehlt der Sensor im Welec-Design, oder
er wurde noch nicht gefunden. Andernfalls müsste man für eine schnelle
Aufbereitung der Daten für jeden Wandler eine Korrekturtabelle von 256
Werten anlegen. Diese wird beim HP vermutlich durch die User-Calib
extrapolieert.
Wo kann ich denn das Video ggf. ablegen. Die User-Calib dauert ein paar
Minuten... Werde ich dann heute Abend aufnehmen.
Gruß, Ulrich
Was mich extrem wundert, sind die Ähnlichkeiten zwischen Welec und
Agilent Geräten.
Z.B. sind die Bedienelemente 100% identisch. Abgesehen von zwei
fehlenden Tasten beim Welec und anderen Softkeys.
Auch das Bildschirmdesign ist zu 99% identisch. Auch die 4 SubDiv/Div in
Y-Richtung.
Siehe Bedienungsanleitung:
http://cp.literature.agilent.com/litweb/pdf/54622-97036.pdf
Verwendet Welec wirklich leicht abgeänderte Orginaldesigns von Agilent?
Aber warum sind dann Hard-und Software so buggy?
Kurt Bohnen schrieb:
> Was mich extrem wundert, sind die Ähnlichkeiten zwischen Welec und> Agilent Geräten.
Das wundert mich nicht. Wenn ich ein neues Gerät auf den Markt bringen
wollte, würde ich mich auch an Bewährtem orientieren
> Z.B. sind die Bedienelemente 100% identisch. Abgesehen von zwei> fehlenden Tasten beim Welec und anderen Softkeys.> Auch das Bildschirmdesign ist zu 99% identisch. Auch die 4 SubDiv/Div in> Y-Richtung.
Das hätten sie allerdings nicht abkupfern müssen. Da halte ich es eher
wie die Japaner: Gut abkupfern und dann verbessern!
> Siehe Bedienungsanleitung:> http://cp.literature.agilent.com/litweb/pdf/54622-97036.pdf
Die hätte WELEC man auch abkupfern sollen, denn die taugt wenigstens
was. Die werd ich mal als Anhaltspunkt für weitere Entwicklungen nehmen
und evtl. auf dieser Basis mal eine richtige Anleitung für das WELEC
stricken.
> Verwendet Welec wirklich leicht abgeänderte Orginaldesigns von Agilent?
Wohl nur das Äußere würde ich sagen. Genaueres kann uns da nur ein
Agilent-Besitzer sagen.
> Aber warum sind dann Hard-und Software so buggy?
Weil sie halt nicht von Agilent sind (schade)
Gruß Hayo
p.s. vielleicht kann man ja eine Platine von Agilent kriegen und ins
WELEC einbauen ;-)
Ulrich P. schrieb:
> Aber normalerweise ist doch ein signed bei> 0..127 positiv und bei 128..255 negativ, wobei 128 der -1 entspricht.
Und 127 die Null. Soweit korrekt.
> Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da> die OVs der Eingangsstufe dann frei laufen.
Da gebe ich Dir recht.
> Gibt es keine Option, die> Stufe auf GND zu schalten? Das wäre schon mal ein Anfang.
Mir ist keine bekannt, aber wenn es da andere Erkenntnisse gibt macht
mich schlau. Ich wollte mich erstmal an vorhandener Hardware
orientieren, damit alle was davon haben.
> Optimaler wäre> es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten> zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs> kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige> brauchbare Referenz aller Kanäle gemeinsam?
Nicht das ich wüßte. Allerdings hab ich die Hardwareseite noch nicht so
intensiv unter die Lupe genommen. Tja da war ich wohl vor 15 Jahren
schon weiter als ich für die Diplomarbeit mein externes Oszi für den
Parallelport konstruiert habe. Da gab es nämlich Abgleichreferenzen und
auch eine schicke Spektralanalyse auf dem PC. Da lief aber die komplette
Software auf dem PC und man mußte nicht so mit Resourcen geizen wie
hier.
Unter anderem gab es auch eine Korrektur der ADC-Kennlinie, die hatte
ich beim WELEC auch schon probeweise eingebaut (Y = beta*X + alpha) aber
wegen der massiven Performanceeinbrüche bei der Graphikausgabe wieder
ausgebaut.
> Nochwas zum HP. Er führt die User-Calibration offenbar unter> Berücksichtigung der eigenen Temperatur durch, diese vermerkt er> jedenfalls in den Logdaten
...
> Vermutlich fehlt der Sensor im Welec-Design, oder> er wurde noch nicht gefunden.>
Temperatursensor? Was ist das möchte man fragen. Sowas gibt es hier
nicht. Da hilft nur nachkalibrieren, und damit das gut klappt legen wir
uns hier ja ins Zeug.
Gruß Hayo
Hallo Hayo,
wenn das Freeze-Problem wirklich zwischen 0.32 und 0.33 eingetreten
ist (h.h. in der 0.32 war es noch nicht), liegt es sicher nicht an
hardware. Da wurde fast nichtsgeändert, wie ein diff zeigt.
Es muss von display kommen, die meisten Änderungen betreffen wohl
den Delayed-Mode. Es kann eineWeile dauern, das durchzuschauen
aber das werden wir schon finden. 8-)
Gruß, Guido
Hayo W. schrieb:
>> Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da>> die OVs der Eingangsstufe dann frei laufen.>> Da gebe ich Dir recht.>>> Gibt es keine Option, die>> Stufe auf GND zu schalten? Das wäre schon mal ein Anfang.>> Mir ist keine bekannt, aber wenn es da andere Erkenntnisse gibt macht> mich schlau. Ich wollte mich erstmal an vorhandener Hardware> orientieren, damit alle was davon haben.
Wenn ich mir den Schaltplan unter
http://welecw2000a.sourceforge.net/docs/pcb/Analog_+Inputs_updated2.png
ansehe, dan gibt es dort wohl mehrere Möglichkeiten. Leider sind in der
letzten Version die IC-Nummern raus gefallen.
Der MAX4704 kann das Signal aus der Vorstufe über NO2 auf GND schalten.
Damit wäre die mittlere Stufe in die Kalibration einbezogen.
Er kann mit NO1 auch gegen einen Pin D8 vom FPGA geschaltet werden, was
das für einen Sinn hat weiß ich nicht, aber wenn der Pin ein Ausgang
ist, kann man damit zumindest einen Bezug zu Digital-Masse und Digital
Vcc herstellen. Allerdings scheint da 0V anzuliegen...
Die Vorstufe rund um die OPAs müsste über K1 und K2 ebenfalls zu
beruhigen sein, hier liegt leider ein 110K Widerstand im Weg zur Masse.
Immer noch besser, als zu floaten.
>>> Optimaler wäre>> es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten>> zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs>> kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige>> brauchbare Referenz aller Kanäle gemeinsam?>> Nicht das ich wüßte. Allerdings hab ich die Hardwareseite noch nicht so> intensiv unter die Lupe genommen.
Ich auch gerade erst, aber weil ich halt nur mal so mitspiele, habe ich
auch keine Hektik :) Muss ja keinen Code ändern, weil hunderte Leute
nach jeder kleinen Verbesserung lechzen :)
> Unter anderem gab es auch eine Korrektur der ADC-Kennlinie, die hatte> ich beim WELEC auch schon probeweise eingebaut (Y = beta*X + alpha) aber> wegen der massiven Performanceeinbrüche bei der Graphikausgabe wieder> ausgebaut.>
Ich kenne die Software, wie gesagt, nicht. Ich spiele daher also nur mal
mit Gedanken. Wenn man die Werte als Byte einliest, aber in einem Word
oder Longint speichert und das gleich als 2. oder drittes Byte.
Dann baut man sich eine Kalibriertabelle, ebenfalls mit korrekt
verschobenen Faktoren und multipliziert dann nur ein einziges Mal und
das als int und nicht float. Klar, die Tabelle müsste dann natürlich für
die geraden und ungeraden Faktoren abgelegt werden, also mind. 2mal. Am
besten sogar für jeden Messbereich und jeden Kanal. Das braucht etwas
Platz, spart aber Zeit.
Gruß, Ulrich
@Guido
Ich bin mir relativ sicher, dass die 0.32 noch anständig läuft. Hier
sicherheitshalber die Flashdatei wenn Du das probieren möchtest.
@Ulrich
> weil ich halt nur mal so mitspiele, habe ich> auch keine Hektik :) Muss ja keinen Code ändern, weil hunderte Leute> nach jeder kleinen Verbesserung lechzen :)
Ich bin zum Glück seelisch stabil ;-) - sonst wär ich auch als
EDV-Fachmann völlig im verkehrten Beruf - Kunden können echt grausam
sein...
> Dann baut man sich eine Kalibriertabelle, ebenfalls mit korrekt> verschobenen Faktoren und multipliziert dann nur ein einziges Mal und> das als int und nicht float. Klar, die Tabelle müsste dann natürlich für> die geraden und ungeraden Faktoren abgelegt werden, also mind. 2mal. Am> besten sogar für jeden Messbereich und jeden Kanal. Das braucht etwas> Platz, spart aber Zeit.
1. Platz ist rar. Brauche schon eine Menge für die trigonometrischen
Tabellen die ich bei der FFT einsetze.
2. Bei 8 Bit ist der Benefit des Abgleichs kombiniert mit der
Ablesegenauigkeit nicht so berauschend. Den Fehler kann man also wohl
verschmerzen.
3. Diese Tabellen müßten ja für jedes Gerät separat ermittelt und
gespeichert werden - was für ein Aufwand an Abgleichroutinen.
Ich denke die Anderen werden mir Recht geben dass es momentan andere
Baustellen gibt die mehr an nutzbarem Erfolg bringen wenn wir sie in den
Griff kriegen.
Nichts desto trotz immer her mit konstruktiven Vorschlägen, dann kann
man Für und Wider hier ausdiskutieren bevor ich (oder andere Berufene)
da was einbauen.
Gruß Hayo
Hallo,
@Ulrich- mit dem Problem des "Eingangstest" (Power on self Test) hab ich
mich auch schon beschäftigt... der FPGA1 PIN D8 scheint allerdings als
Input geschalten zu sein...(Wir- im VHDL Projekt- hatten schon mal
angedacht einen definierten Spannungsverlauf über diesen Pin auszugeben
und das Ergebnis an den ADC's mit dem abgespeicherten Sollzustand zu
vergleichen)
Über die jetzige Fkt. der dortigen Beschaltung gibt's meines Wissens
noch keine tieferen Erkenntnisse.
Evtl. könnte man auch über den DAC eine definierten Spannungsverlauf
ausgeben- da müsste man einmal sehen wie schnell der ist...
Also ich verbinde meinen BNC- Eingang für die Kalibrierung immer mit
GND- speziell da mein OPA gern schwingt.
Nehm doch bitte den Schaltplan in der Google Groups, der ist immer auf
dem neusten Stand (und wesentl. ausführlicher). Derzeit in Version 1.32
http://groups.google.com/group/welec-dso
Gruß, brunowe
Hi Bruno,
Ok, dann beziehe ich mich auf diesen Schaltplan, für den aber vorerst
das gleiche gilt. Mir ist die Funktion aller OVs darin noch nicht ganz
klar, aber das wird schon. In der Diskussion dieser drei Threads war die
Rede davon, dass der ADC Single-Ended angesprochen wird. Die Schaltung
ist aber eher differential ausgelegt. Aber ich bin halt nicht der
analoge Crack, bei mir fängt die Signalaufbereitung normalerweise auch
erst im DAC/ADC an.
Daher spinn ich jetzt mal was herum. Wenn der DAC eingesetzt wird, um
den negativen Bereich in den Positiven zu verschieben, dann ist keine
saubere 0-Linien Berechnung zu machen, weil die Verzerrungen und die
Offsetfehler der OVs hoch skaliert werden. Nutzt man den ADC als
Differential und den DAC nur zum Offsetabgleich und Gain, dann würde man
doch viel genauere Messwerte gerade bei kleinen Signalen erhalten?
Beschimpft mich nicht, erklärt es mir, ich lern gerne noch was dazu.
Gruß, Ulrich
@ Ulrich: Der ADC wird differentiell angesteuert. Der DAC verschiebt
direkt den Offset des OPA-Eingangsverstärkers. Er könnte damit direkt
für Testsignale verwendet werden. Aber alles zu seiner Zeit. Solange
die Offseteinstellung noch hakt macht es wenig Sinn daran rumzuspielen.
@ Hayo. Jo, die 0.32 läuft noch. Ich gehe mal das diff durch.
Gruß, Guido
@Guido
ja da bin ich auch gerade dabei. Ich muß Dir Recht geben, die
Hardwareroutinen geben keinen Hinweis. Ich hab danach mal die
Displayroutinen gescannt, aber auch nichts direktes gefunden außer einem
Verdächtigen in der DrawSignals(), den ich jetzt mal per
Terminaldebugging etwas unter die Lupe nehme - Upload läuft noch...
Hayo
@ Hayo: mit dem diff bin ich durch, da ist mir nichts
gravierendes aufgefallen. Ich bin schon am überlegen,
ob es nicht eine Race-Condition ist, aber das sieht
eigentlich auch sauber aus. Ich hab mal "Signal_Loaded"
rausgeworfen, wird eh nicht benutzt aber wohl auch keine
Besserung bringen.
Gruß, Guido
Tja bei mir sieht es ähnlich aus. Der Diff-Vergleich bringt nur
unspektakuläres. Hab jetzt mal ein paar Debuggingausgaben eingebaut.
Folgende Details:
Timebase < 18 und >28 - ADC wird gestartet, ADC meldet per ISR Data
available, Daten werden vom ADC abgeholt, Zeichenroutine gibt Signal
aus, ADC wird gestartet....usw.
Timebase >= 18 und <= 28 - ADC wird gestartet, keine Rückmeldung vom
ADC, es werden keine Daten abgeholt (wegen der fehlenden Rückmeldung),
Zeichenroutine gibt das alte Signal aus das immer noch im Buffer steht,
ADC wird gestartet... usw.
Also ich kann mir da im Moment keinen Reim drauf machen. Werd mal als
nächstes die PIO-Register checken. Schaff ich aber heute und morgen
nicht.
Gruß Hayo
Hallo Hayo,
heute blicke ich auch nicht mehr viel. Aber suche doch mal
in hardware nach "Start_Record", das wird selbst im
Timerinterrupt aufgerufen. Es macht mich halt misstrauisch,
dass der Fehler vom Timing abhängt.
Gruß, Guido
Guido schrieb:
> Es macht mich halt misstrauisch,> dass der Fehler vom Timing abhängt.
Ich habe da einen weiteren Verdächtigen ausgemacht. Vielleicht schaffe
ich es nach der Arbeit noch schnell eine neue Testversion upzuloaden
bevor ich wieder los muß.
Gruß Hayo
Ich habe die 0.56er Sourcen jetzt compiliert bekommen, meine
TomCat.flash ist allerdings 1307517 Byte groß, die von Hayo 1307650
Byte.
Habe ich was falsch gemacht (die in der Anleitung beschriebenen
"offical" Sourcen hatten kein Makefile, ich habe die "improved" genommen
und dort das src Verzeichnis durch das von Hayo ersetzt)???
Viele Grüße,
egberto
Ich habe bei mir das loader file etwas geändert, das wird dann mit dem
Flashfile zusammengemerged. Hier noch mal alle wichtigen Ordner ohne den
src Ordner.
Das sollte es sein. Wenn nach dem Upload alles im Oszi läuft wie es soll
kann es nicht so verkehrt sein.
Gruß Hayo
Noch eine Frage: hattest Du überhaupt das Loader-File? Wenn nicht
funktioniert es nicht, da ist der Bootloader drin, der das Programm
nachher in den RAM-Speicher lädt. Deshalb muß das Loader-File mit dem
Tomcat.Flash kombiniert werden. Sieht man auch wenn man mit dem
Texteditor ins Flashfile geht. Das ist im Makefile schon alles
eingebaut.
Gruß Hayo
Hallo Hayo,
loader ist dabei gewesen(801 Bytes).
Mit deinen Build-Dateien bekomme nach "make clean all" nun auch deine
Dateigröße.
Viele Grüße,
egberto
@egberto
prima, dann kannst Du ja auch gleich mit einsteigen...
@Guido
Der nächste Verdächtige scheidet auch aus. Hab mal alle UI_requests
rausgenommen, geht aber trotzdem nicht - die Suche geht weiter. Hab
schon die nächste Idee, komme aber erst morgen oder übermorgen dazu.
Gruß Hayo
Hallo Hayo,
es ist mir gelungen den Fehler einzugrenzen und einen
Workaround zu implementieren. Der wird uns hoffentlich
helfen den Fehler zu finden. Näheres findest du im zip
als freeze.txt.
@ all: Im zip ist auch ein Tomcat.flash, das außer dem
Workaround Hayos letzter Beta entspricht. Vielleicht hat
jemand Lust zum Testen.
Gruß, Guido
@Guido
das Löschen der availability Abfrage bringt uns aber nicht näher an den
Fehler. Das Problem ist ja, dass der ADC gestartet wir, aber aus
irgendeinem Grund keinen Ready-Interupt mehr auslöst. Da muß ich wohl
die Register prüfen, allerdings hatte ich da eigentlich nichts geändert.
Zur Eingrenzung werde ich auch noch mal versuchen die 0.32er
Display-Routine mit der 0.33er Hardware-Rotine zu kombinieren und
umgekehrt. Dadurch läßt sich vielleicht der Fehler weiter eingrenzen.
Gruß Hayo
Hallo Hayo,
die Availability-Prüfung habe ich längst wieder drin. Du musst
da keine weiteren Tests machen. Das Problem ist einfach, dass
der ADC in der Grafik gestoppt wird, so dass sein Interrupt
nicht ausgelöst wird. Ich vermute, dass das in Copy-Planes
erfolgt. Das können wir noch weiter untersuchen, im Moment
arbeitet das Welec mit dem Workaround aber wie gewünscht.
Gruß, Guido
Oh, sorry - da fehlte wohl ein Zeilenumbruch in Deiner Datei. Ich hab
nur den ersten Teil gelesen. Hab eben nochmal die Zeilen umgebrochen und
den Rest gelesen. Ok, das ist schon mal ein Hinweis dem man nachgehen
kann. Die Copy und Transfer Planes Routinen sind leider spärlich
kommentiert, so dass die Suche etwas schwierig ist. Evtl. könnte man
nach StopRecord() suchen, denn damit kann man den ADC-Lauf abbrechen.
Gruß Hayo
Hallo Hayo,
ich werde später erst mal versuchen den Workaround auf die
schuldige Funktion zu begrenzen (im Moment sind es ja noch
3). Wenn da irgendwo in dem Assemblerteil ein Bit getoggled
wird, könnte die Suche lang werden. :-(
Es könnte aber auch Absicht dahinterstecken, weil sonst ein
Konflikt beim Zugriff aufs RAM entsteht.
Wir werden es rausfinden, Guido
Ok,
ich glaube ich hab es. Durch Deinen Workaround bin ich da auf einen
Gedanken gekommen. Es gab in der 032 eine Variable - DrawSignals_Needed
- die hab ich in der 033 rausgenommen (zumindest in der Graphikroutine)
weil mir die Funktion redundant erschien.
Wenn ich jetzt so darüber nachdenke sollte diese Variable wohl
verhindern, dass die Gaphikroutine zu früh aufgerufen wird und damit
natürlich auch das nächste Start_Record(). Denn in Start_Record() wird
erstmal der alte Aufruf gestoppt und dann wieder ein Neuer gestartet.
Das erklärt narürlich, warum dann bei langen Wandlerlaufzeiten keine
neuen Daten mehr gelesen werden. Ich werde das mal morgen reparieren und
schicke dann die nächste Beta raus. Da sieht man wieder, zu zweit sieht
man einfach mehr als ein Einzelner.
Gruß Hayo
Ich hab auch schon einen viel eleganteren Lösungsansatz.
In der Routine Start_Record() braucht man nämlich nur das Flag -
adc_started - abzufragen und bei gesetztem Flag die Routine zu verlassen
und schon sollte die Welt wieder in Ordnung sein und da die
Graphikroutine trotzdem noch durchlaufen wird, reagiert sie auch auf
User-Eingaben.
Das halte ich auch für nachlässig programmiert (von WELEC), denn es
macht ja keinen Sinn den ADC aufzurufen wenn er noch läuft.
Gruß Hayo
Hallo Hayo,
das haben die sicher so gemacht, damit bei Änderung der
Einstellungen nur Start_Record aufgerufen wird. Sonst muss
man einen Messzyklus abwarten, bis die Signalanzeige
aktualisiert wird (das ist mir eh noch ein Dorn im Auge, jedes
andere Oszi kann das besser), oder erst Stop_Record und dann
noch Start_Record aufrufen.
So, TransferPlanes (allein) ist unschuldig. Werde gleich noch
mal flashen.
Gruß, Guido
Bin gerade zuhause angekommen, schnell mal Linux gestartet und die
Änderungen programmiert und den Updater angeworfen - Upload läuft. Bin
gespannt was rauskommt.
Gruß Hayo
> Bin gespannt was rauskommt.
Wird schon klappen, ist sehr beruhigend, dass es nur das
Start_Record ist. Braucht man nicht im Assemblercode zu
wühlen.
Gruß, Guido
ich hab mal eine frage an die firmware coder. ich spiele gerade etwas
mit dem schaltverhalten des switch U3 und den softwareskalierungen rum.
wenn ich die ändere passt der offsetmarker nicht mehr zur nulllinie.
gibt es für die markerposition auch korrekturfaktoren?
gruß sunny
Hallo sunny,
das klingt ziemlich unsinnig. Die Nulllinie sollte ja da sein,
wo man sie mittels Marker hinsetzt. Die Kalibrierung des Offsets
stimmt aber nur für die in der Firmware vorgesehenen
Einstellungen der Verstärkung.
Gruß, Guido
der sinn, das schaltverhalten des U3 zu ändern (zu invertieren), besteht
darin die auflösung in den 1er und 2er messbereichen zu verbessern.
im original verstärkt der opa656 im 5er bereich mit 1,25 und in den 1er
und 2er bereichen mit 1. das hat zur folge, dass in den 1er und 2er
bereichen die aussteuerung des adc recht gering ist und eine
softwareskalierung >3 notwendig ist, um den screen zu füllen. betreibt
man den opa 656 jedoch genau umgekehrt, so dass er im 5er bereich mit 1
und in den 1er und 2er bereichen mit 1,25 verstärkt, reduziert sich die
nötige softwareskalierung auf einen faktor von etwa 2. das vermindert
das sichtbare rauschen und verbessert die darstellungsqualität.
problem ist dass die ausgangsspannungen des offset dac nicht mehr zu den
verstärkungen des opa656 passen. der offsetmarker erreicht das obere
ende des screens ca 1,5div vor der nullinie.
die werte in dem float Volt_Correct_float array in der tc_vars.cpp
müssten doch das sein was ich suche. richtig?
Hallo sunny,
das hängt jetzt davon ab, welche Firmware du benutzt. In der neuesten
Beta hat Hayo die Umrechnung auf Int umgewandelt, so dass die
Tabelle obsolet ist.
Eigentlich sollte U3 immer geöffnet sein (meine Meinung). In den
5er Bereichen bringt das eine bessere Auflösung (Umrechnungsfaktor
auf die Grafik dann 2), in den 1er und 2er Bereichen ist die 1,25
fache Verstärkung sowieso nötig. Da müssen wir mal einheitlich
was festlegen. Dazu sind dann 3 Offsetwerte nötig, was bisher
schon vorgesehen ist.
Gruß, Guido
ich nutz die .56
in der funktion ON_Zero_Channel_x wird das array noch genutzt. ich weiß
nicht wann hayo das geändert hat.
ich hab den u3 im 5er bereich schlißen lassen, weil dann die
softskalierung in allen 3 bereichen gleich ist. du hast allerdings
recht. es macht eigendlich keinen sinn ihn im 5er bereich zu schließen.
damit verschenkt man nur aussteuerbarkeit. man könnte wirklich mal
versuchen ihn ständig ausgeschaltet zu lassen.
Tja sunny,
da gibt es schon noch Unstimmigkeiten. Dein Hinweis ist
da schon hilfreich, damit das nach und nach geändert
werden kann.
Mal was anderes: Du hast ja rausgefunden wie U21 und U23
angesteuert werden (hab ich auch schon ;-)). Findest du
ev. wie und wo U24 angesteuert wird? Das wäre für den
Offsetabgleich super, dann könnte man mit dem MAX4704
hierfür die Eingänge auf GND legen.
Gruß, Guido
Dafür, U3 rauszuschmeißen spricht auch die Simulation von Bruno im
Hardwarethread -> man würde gleich 2 Fliegen mit einer Klappe
erschlagen.
Mal sehen, was bei Brunos Lötaktion so raus kommt.
Viele Grüße,
egberto
@sunny
Die Marker repräsentieren nur die Nulllinie (Grid-Zerolevel), diese wird
nur als direkter gridproportionaler Integerwert im Zerolevel geführt.
Die FW unterscheidet den Grid-Zerolevel (0 - 400) und den virtuellen
Zerolevel (-8192 bis +8192) der den Aussteuerbereich des DAC
repräsentiert. Man kann den Zerolevel also bis in den Virtuellen Bereich
verstellen, nur das der Grid-Zerolevel dann auf 0 oder 400 stehen
bleibt.
Die Werte im float Volt_Correct_float array sind für die Skalierung des
DAC-Offsets (Zerolevels) verantwortlich, für die Signalskalierung haben
sie keine Auswirkungen. Die Mitte (Gridmitte) des DAC-Offsets liegt bei
8192. Hinzuaddiert wird der virtuelle Zerolevel skaliert durch diesen
Faktor und korrigiert durch die DAC-Korrektur, die ja bei SearchZero()
ermittelt wird.
Gruß Hayo
Ok hier nun einige Details.
Nachdem ich gestern mit Guidos Hilfe auf den (eigentlich sekundären)
Fehler gestoßen bin, hab ich erstmal einiges Ausprobiert und analysiert.
Ausglöst wurde der Fehler durch eine Variable die ich gelöscht hatte,
die aber eigentlich von hinten durch die Brust ins Auge die
Start/Stop-Logik steuern sollte (in der Graphikroutine!).
Ich hatte ja gestern die Idee in der Start_Record() den erneuten Aufruf
zu unterbinden. Vom Gedanken her auch korrekt, aber es läuft nicht, da
die Start/Stop-Logik des ADC so krude implementiert ist, dass es immer
wieder zu Hängern kommt. Also gleich wieder Nägel mit Köpfen gemacht und
die Logik vernünftig implementiert. Die Startsequenz hab ich also aus
der Graphikroutine rausgenommen - wo sie auch wirklich nichts zu suchen
hat - und in den ADC-Handler verfrachtet - wo sie auch hingehört.
Zusätzlich hab ich noch eine Start/Stop-Sequenz in den
TimebaseWheel-handler eingebaut. Auf die komische Steuervariable die ich
ja ohnehin schon an diversen Stellen gelöscht hatte, kann man jetzt ganz
verzichten. Außerdem wird jetzt die Graphikroutine unabhängig vom
Abtastprozess des ADC durchlaufen was eine bessere Reaktion auf
Usereingaben bewirkt.
Zusätzlich bin ich bei der Gelegenheit auf eine weitere Baustelle
gestoßen, die auch die aktuelle FW 1.4 betrifft.
Und zwar laufen Zeitbasen > 20S im 50ns Modus, man kann also mit der
Zeitbasis 200s ein Signal mit einer Frequenz von z.B. 5 MHz sauber
darstellen.
Wie das mit dem Timebaseregister zusammenhängt kann man in der
aktualisierten Fassung meiner Programming Maps sehen die in der
Timebasetabelle die aktuellen Einstellungen zeigt (siehe Anhang).
Ursprünglich war wohl für Zeitbasen im Sekundenbereich der sogenannte
Rollmode vorgesehen, der nicht eine Zeitlinie nach der anderen
darstellt, sondern mit einem Zeitfenster durch die Zeitlinie fährt. Man
kann sich das so vorstellen wie die Anzeige auf einem Herzschlagmonitor.
Der Programmierer hat jedoch alle Stellen zum Rollmode in der FW
auskommentiert. War wohl noch unausgegoren. Ich werde das auch nicht
wieder aktivieren sondern lieber gleich richtig machen. Dauert aber
natürlich etwas.
Die aktuelle FW ohne Freeze-Bug gibt es heute abend.
Gruß Hayo
Hallo Hayo,
da bin ich aber mal gespannt. Ich hatte mir auch Gedanken gemacht
und war zu dem Ergebnis gekommen, dass Start_ADC in Display_Signals
schon seinen Grund hat. Wenn der ADC schon wieder sampled, während
die Daten verarbeitet werden, gibt es keinen zusammenhängenden
Kurvenzug mehr. Auch bei der Triggerung könnte das zu Problemen
führen. Soweit ich das bisher verstehe, haben wir ja keine echte
Hardware-Triggerung, es wird nur das aktuelle Sample entsprechend
durchsucht.
Die Zeitbasisprobleme kann man wohl nur in der Firmware erkennen,
wer kommt schon auf die Idee über eine Stunde zu warten, bis das
Sampling abgeschlossen ist.
Rollmode, das ist der Begriff, der mir gestern gefehlt hat. Den
müssen wir noch implementieren (hab schon eine Idee) sonst sind
die langsamen Bereiche next to useless.
Gruß, Guido
Guido schrieb:
> Die Zeitbasisprobleme kann man wohl nur in der Firmware erkennen,> wer kommt schon auf die Idee über eine Stunde zu warten, bis das> Sampling abgeschlossen ist.
Nein, schließ mal ein 5MHz Signal an und gehe auf 100s oder 200s, das
sieht genauso aus wie im 50ns Bereich. Bin drauf gekommen weil mich die
hohe Wiederholrate stutzig gemacht hat. Bei 10s und 20s geht es noch
(hab ich einfach ausgesessen).
> Rollmode, das ist der Begriff, der mir gestern gefehlt hat. Den> müssen wir noch implementieren (hab schon eine Idee) sonst sind> die langsamen Bereiche next to useless.
So ist es. Der rein physikalisch Vorgang ist eigentlich ganz einfach.
Man sampled immer nur ein kurzes Stück und scheibt es auf der einen
Seite in den Signalbuffer rein. Hinten läßt man das alte einfach
"rausfallen". Dann gibt man das Siganl aus. Dann Sampled man erneut und
schiebt dann wieder nach. Das sieht dann so aus, als würde das Signal
(ein Impuls z.B.) von links nach rechts über den Bildschirm wandern.
Dadurch hat man dann bei Sampleraten um 1Sa/s auch keine ewigen
Wartezeiten bevor man was sieht.
Ideen hab ich auch schon, aber ich muß mal meine Prioritätenliste
sortieren und sehen was mir wichtig erscheint.
Gruß Hayo
Guido schrieb:
> Ich hatte mir auch Gedanken gemacht> und war zu dem Ergebnis gekommen, dass Start_ADC in Display_Signals> schon seinen Grund hat. Wenn der ADC schon wieder sampled, während> die Daten verarbeitet werden, gibt es keinen zusammenhängenden> Kurvenzug mehr.
Nein, kein Problem, der ADC-Handler wartet ja mit dem Auslesen des
nächsten Samples bis die Graphikroutine fertig ist - es sei denn es
kommt ein UI-Interrupt.
> Auch bei der Triggerung könnte das zu Problemen> führen. Soweit ich das bisher verstehe, haben wir ja keine echte> Hardware-Triggerung, es wird nur das aktuelle Sample entsprechend> durchsucht.
Der Trigger verschiebt im Prinzip nur den angezeigten Ausschnitt aus dem
Signalbuffer. Ich habe die Variable die den Startpunkt des Fensters
markiert irgendwann mal umbenannt in MemWinStart falls Du mal im Coding
suchen willst.
Gruß Hayo
hi
@guido
>Findest du ev. wie und wo U24 angesteuert wird?
ja, ich denke schon.
der U24 hängt hardwaremäßig hinter dem U22 welcher für die ansteuerung
des CH2 zuständig ist. du machst also
SwitchesCH2 &=0x00FF;
SwitchesCH2 |= 0x**00; // ** sind die daten die an U24 erscheinen sollen
SetSwitches(2, -1);
ich denke so müsste das gehen.
@hayo
die signalskalierung hatte ich schon gefunden. mir ging es hier um die
skalierung der dac ausgangsspannung in bezug auf die markerposition. ich
hatte das etwas blöd beschrieben. auf jeden fall danke für die
erklärung. ich werd mein glück noch mal versuchen.
gruß sunny
Ok hier wie angekündigt die neue 0.59 beta.
Hab noch schnell einige Sachen geprüft, aber soweit scheint alles stabil
zu laufen (außer den bekannten Bugs). Wer mitgelesen hat der weiß schon,
dass der Freeze-Bug endlich gefunden und beseitigt ist. Der DAC-Abgleich
ist noch in Arbeit und funktioniert nur wenn man die Zerolevel vorher
auf Gridmitte gestellt hat.
Der neu gefundene Fehler in der Zeitbasis, der auch in der originalen FW
steckt kann nur durch die Implementierung des Rollmode beseitigt werden
- Fertigstellungstermin noch unklar.
Wie immer alles andere in der readme. Ich hab auch noch die How To für
die Linux und CDK Installation mit reingepackt.
Gruß Hayo
Hallo Hayo,
ich hab die neue FW mal aufgespielt und auch den ADC-Abgleich
durchgeführt, soweit so gut.
Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch
nicht richtig funktioniert? Kanal 1 und 2 werden ziemlich gut auf Null
gebracht, bei Kanal 3 und 4 liegen die Signale unterhalb der Nulllinie.
Oder hängt das noch mit dem DAC-Abgelich zusammen?
Ansonsten sieht die FW bei mir momentan stabil aus, werd mal noch ein
wenig herumprobieren.
Gruß, branadic (W2014A)
Hallo Hayo,
ich hatte das ja bei meinen Compilierversuchen schon angedeutet - die in
deiner Anleitung angegebenen Sourcen stehen da nicht mehr, und die als
"improved" zu findenden haben einen anderen loader als du.
Könntest du nicht diese build.zip in jede weitere Beta einschließen?
Dann hat man ein Makefile und auch deinen loader. So könnte sich eine
breitere "Masse" damit auseinandersetzen.
Leider geht z.Z. mein Hausumbau vor, aber deine "Programming_Maps"
empfinde ich als sehr hilfreich zum Verständnis - bitte mehr in dieser
Art bzw. umfangreiche Kommentare in den Sources.
Viele Grüße,
egberto
branadic schrieb:
> Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch> nicht richtig funktioniert? Kanal 1 und 2 werden ziemlich gut auf Null> gebracht, bei Kanal 3 und 4 liegen die Signale unterhalb der Nulllinie.
Bei mir ganz genauso.
/Hannes
Hallo Hayo,
ich weiß nicht inwiefern dir das jetzt noch hilft, aber bei mir spuckt
der automatische ADC-Abgleich folgende Werte aus:
CH1 ADC1 Voltage offset = 3
CH1 ADC2 Voltage offset = 0
CH1 ADC3 Voltage offset = 1
CH1 ADC4 Voltage offset = 0
CH2 ADC1 Voltage offset = 0
CH2 ADC2 Voltage offset = 0
CH2 ADC3 Voltage offset = 0
CH2 ADC4 Voltage offset = 0
CH1 Zero Sign Offs 1 = 113
CH1 Zero Sign Offs 2 = 134
CH1 Zero Sign Offs 3 = 91
CH2 Zero Sign Offs 1 = 115
CH2 Zero Sign Offs 2 = 140
CH2 Zero Sign Offs 3 = 104
Man merkt auch den Geschwindigkeitszuwachs durch deine Aufräumarbeiten
:)
Wirklich schon schön anzuschauen.
Gruß, branadic
Hallo Hayo,
habe mich mal durch das Assembler-Listing durchgelesen, das du im
anderen Thread veröffentlich hast. Ich antworte einfach mal hier, weil
es ja zur Software gehört. Ich hoffe, dass stört keinen.
Alles habe ich noch nicht 100% verstanden, aber den Größtenteil. Es
langt auf alle Fälle um zu erkennen, warum das Averaging so ganz komisch
funktioniert. Der Durchschnitt wird nicht mit den benachtbarten
Messwerten gebildet, sondern mit den Messwerten die noch im Speicher vom
letzten Aufruf stehen. Wenn der Trigger etwas ungenau funktioniert,
werden dadurch verschiedenste Werte gemittelt.
Mehr dazu dann Morgen, wenn ich es ganz verstanden habe.
Gruß,Stefan
Stefan schrieb:
> habe mich mal durch das Assembler-Listing durchgelesen, das du im> anderen Thread veröffentlich hast. Ich antworte einfach mal hier, weil> es ja zur Software gehört. Ich hoffe, dass stört keinen.
Das ist hier schon ganz richtig, hatte nur das Thema von Bruno im
Hardwarethread aufgegriffen, von daher überschneiden sich auch einige
Themen in den Threads was ja nicht schlimm ist.
> Alles habe ich noch nicht 100% verstanden, aber den Größtenteil. Es> langt auf alle Fälle um zu erkennen, warum das Averaging so ganz komisch> funktioniert. Der Durchschnitt wird nicht mit den benachtbarten> Messwerten gebildet, sondern mit den Messwerten die noch im Speicher vom> letzten Aufruf stehen. Wenn der Trigger etwas ungenau funktioniert,> werden dadurch verschiedenste Werte gemittelt.
Das wäre allerding etwas merkwürdig. Wundern täte es mich allerdings
nicht, nach dem was ich bislang schon alles im Coding gefunden habe.
Aber schön, dass Du Dich da reinkniest, ich gebe zu ich hatte keine
Lust, Assembler ist immer so mühsam.
Da gut optimiertes C-Coding auch nicht langsamer ist war ich schon am
überlegen ob man das nicht in C umschreibt.
Gruß Hayo
Hallo,
@ egberto: deine Probleme kann ich nachvollziehen, probier mal mit
dem angehängten loader.flash aus dem "Offical_Build", bei mir geht das.
@ Stefan: Probier mal, es sieht wirklich nicht so schlimm aus. Freue
mich auf Rückmeldungen! Wie du das mit dem Trigger meinst, verstehe ich
nicht. Der Mittelwert sollte ja schon aus aufeinanderfolgenden Messungen
berechnet werden.
Gruß, Guido
Hallo,
erstmal vorallem Danke an Hayo und Bruno für die bisherige hervorragende
Arbeit.
Ich habe mich mal mit der Idee beschäftigt das Flash für die
Entwicklungsarbeit zu umgehen und die Firmware direkt ins RAM zu laden.
Das geht gut in dem man anstatt dem Loader einfach ein "r0" an den
Anfang schreibt um den Relocate zu umgehen.
Das angehängte Makefile erzeugt zusätzlich zum TomCat.flash ein
TomCat.ram welches man ohne lange Wartezeit sehr schnell ins RAM
laden kann.
Durch den S8 Record am Ende wird die Firmware dann auch gleich
gestartet.
Dieser "S8" Record ist vermutlich auch der Grund für den Timeout
wenn man das Flash beschreibt, da der GERMS Monitor dann die
Firmware starten will, aber ein einer falschen Stelle.
Im Flash File sollte man diesen Record entfernen (mach ich mich als
nächstes drüber).
Mit gtkTerm kann ich das Ram File in knapp 3 Minuten zuverlässig laden,
damit spart man viel Zeit beim Testen, und das Flash wird auch nicht so
oft neu beschrieben was der Haltbarkeit des selben zu gute kommt.
Gruß,
Günter
Könnte man eigentlich die Bootzeit verkürzen indem man den
Startbildschirm rausnimmt, der 5 Sekunden angezeigt wird?
Man kann ihn ja immer noch über Utility/About Oscilloscope anzeigen.
Außerdem: Nach dem verstellen der Zeitbasis, wenn der Scrollbalken
ausgeblendet wurde, bleibt die Anzeige kurz stehen. Ist das normal?
branadic schrieb:
> Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch> nicht richtig funktioniert?
Ich hab die Search Zero Funktion bis auf ein paar kleine Reparaturen
wieder auf original gesetzt weil ich die Feinkorrektur in Calibrate DAC
machen will.
> Ansonsten sieht die FW bei mir momentan stabil aus, werd mal noch ein> wenig herumprobieren.
Einen kleinen Bug hab ich eben noch gefunden und auch schon beseitigt,
nach Calibrate Zero läuft das Signal nicht wieder los. Man muß erst am
Timebase-Knopf drehen bevor es weitergeht.
Dass Dein einer Kanal bei 0000 liegt ist schon Glücksache, das Glück
haben nicht Viele (ich denke da z.B. an Bruno). Bei mir liegen auch alle
Offsets zwischen 0 und 3.
@Egberto
Ich hab das nicht mit ins Package reingetan, weil sonst der Umfang zu
sehr anschwillt und das Limit irgendwann erreicht ist. Ich kann aber mal
ein aktuelles Build auf Google Groups ablegen und die Links dahin
aktualisieren (mach ich morgen).
Gruß Hayo
Hi,
gerade habe ich mal die Firmware auf allen Kanälen durchgetestet und es
sah recht gut aus (interner Rechteckgenerator).
Später dann (30 Minuten) habe ich diese Tests nochmal duchgeführt und
gemerkt, dass die Kurven nur bei eingehendem Signal gezeichnet werden.
Sobald der Triger weg ist, bleiben die Kurven stehen - böse Sache. Wenn
ich den getriggerten Eingang auf Null gelegt habe, steht immer noch die
'alte' Kurve. Sobald das Signal wieder am getriggerten Eingang liegt,
wird das Bild wieder gemalt. Ist aber auch möglich, dass ich irgendwo
zwischendurch was verdreht habe (Level, protrigger)...
Allerdings habe ich die Tests immer nur mit einem geschalteten Eingang
durchgeführt. Wie es sich mit 2+ Signalen verhält, weiss ich nicht.
Im großen Ganzen ist der Rauschteppich aber merklich kleiner geworden -
Danke dafür.
Michel
Sorry,
hab an den EInstellungen gespielt...
Wenn ich von 'Edge' auf 'Pulse Width' gehe. Ein Redraw findet statt
(Marker rechts und links zucken, nur die Kurven werden nicht neu
gezeichnet. Allerdings denke ich mal, dass die Einstellungen nicht so
ganz passen: Delta T 115us bei 1kHz Signal... ?
Bild ist nur mit 'nem Handy aufgenommen, sorry dafür. Hatte keinen Bock
die Kamera zu suchen.
Michel
@Michel
Ok Problem erkannt. Allerdings habe ich festgestellt, dass es nicht an
meinen Änderungen liegt, denn die original FW 1.4 hat genau das gleiche
Problem.
Gruß Hayo
Hab noch mal ezwas rumgetestet, sobald die Triggereinstellungen zur
Pulsweite passen läuft er weiter. Mir fehlt jetzt etwas die Erfahrung
mit anderen DSOs, insofern weiß ich nicht ob dies als Fehler anzusehen
ist, oder ob es gewollt ist. Kann hier jemand weiterhelfen?
Gruß Hayo
Da ich in den letzten Jahren nur Hochsprachen gemacht habe, traue ich
mir eine solche hardwarenahe Programmierung nicht zu, würde aber gerne
helfen...
@Hayo:
vielleicht sollte ich mich mit dem USB beschäftigen? Die serielle
Schnittstelle geht mir auf den Zwirn. Vielleicht auch den Updater
(Option: In's RAM oder Flashen...)
Gibt es einen Teil im Code, der den USB behandelt? Ich bin leider
FPGA-mäßig nicht so fit (s.o.), ist die serielle Schnittstelle direkt in
den FPGA integriert? Die Aktivierung über die Funktionstasten läßt ja
sowas vermuten...
Kann ich die Entwicklung auch unter Windows machen oder ist es unter
Linux einfacher?
Werde mal auf Google Groups nach den entsprechenden Quellen fahnden...
Michel
Oszi-seitig hängt am USB ein Cypress FX1. Das ist ein USB-fähiger
8051er. Der FX1 ist außer per JTAG nur per einer weiteren UART mit dem
FPGA verbunden. Das heißt du gewinnst nicht viel.
Für die Anwender ist der FX1 nur ein teurer USB<->RS232 Wandler, aber
für die FPGA-Bastler kann man auf den FX1 auch eine nette Firmware
laden, die das Oszi dann zum Rechner hin wie einen Altera ByteBlaster
aussehen lässt. Somit kann man direkt ohne das Gerät zu öffnen neue
Configs in den FPGA übertragen.
Beide UARTs (die für den seriellen und die für den USB-Anschluss) werden
im FPGA realisiert und sehen von der Software her deshalb vermutlich
auch beim NIOS aus wie normale serielle Schnittstellen. Außerdem denke
ich dass auch an der USB-UART bei 115200 Baud schluss ist. Aber das ist
jetzt Spekulation.
Hallo,
Danke Crazor, gute Erklärung.
Was ich mich in diesem Zusammenhang schon öfter gefragt habe:
Warum muss ich beim Welec-Updater den Germs-Monitor zum Upload starten,
beim original W2000-updater von Welec nicht? Offensichtlich gibt es
einen grundsätzlichen Unterschied zwischen den beiden Update-
Verfahren?!
Hat Jemand tiefere Erkenntnisse diesbezüglich?
@werner: Für einen Updater per USB wäre ich seeeehr dankbar!
Mit diesen USB-seriell ist das echt ne Qual.
Gruß, brunowe
... ich hab' mal'n Bischen rumgesucht...
Leider bringt er es laut irgendeinem Schema auf Google Groups nur auf
57k zum FPGA, laut Datenblatt kann der Cypress bis zu 230k. Wie die
Anbindung an den FPGA funktioniert, muss ich erst rauskriegen.
Bleibt mir die Firmware wohl nicht erspart...
@Hayo
Ist es vielleicht möglich mir zwei weiteren Funktionstasten das Scope an
dem USB lauschen zu lassen?
Was macht eigentlich die Firmware für den Cypress im Originalzustand?
Nur Sampledaten ausgeben?
Michel
Hi, das sind jetzt aber viel Fragen,
- erstmal kann jemand bei der Sache mit dem stehenden Signal
weiterhelfen und mal kundtun ob das so sein muß oder nicht?
- es gibt USB-Routinen in der FW. Wenn jemand die Windows oder
Linux-Seite übernimmt, könnte ich die Verarbeitung auf der DSO-Seite
übernehmen.
- Der GERMS-Monitor ist normalerweise Bestandteil aller Developmentkits
(hatte ich auf meinem DSP56000 Board auch) und ist wegen Minimalcodings
nur auf RS232 ausgelegt. Die Schnittstelle ist eigentlich nicht für den
Normalbetrieb gedacht, aber freundlicherweise hat WELEC sie gewollt oder
evtl. sogar ungewollt zur Verfügung gestellt.
- Zur aktuellen Beta die bei mir gerade heranwächst: Der DAC-Abgleich
wird langsam rund. Ich mache gerade noch ein paar Tests, ich denke
morgen müßte ich soweit sein.
Gruß Hayo
Hallo Hayo,
also ich kann nur von meinem täglichen Arbeitsgerät berichten:
Ist die Triggerquelle weg, dann wird die Anzeige auch weiterhin mit den
digitalisierten Werten aktualisiert, allerdings aufgrund des fehlenden
Triggers wandert das Signal wahllos durch den Bildschirm.
So kenn ich das jedenfalls und das macht auch irgendwo Sinn.
Zugegebenermaßen arbeite ich mit einem DPO, nicht mit einem DSO.
Vielleicht weiß jemand anderes etwas anderes zu berichten.
Gruß, branadic
Hallo Hayo,
mir ist noch eine Sache aufgefallen.
Angenommen ich habe eine Zeitbasis von 5ms, lasse mir ein Signal
anzeigen und stoppe dann, dann sollte ich theoretisch bis 5ns herunter
den Zeitbereich verstellen können und somit im aktuellen Ausschnitt
näher an das Signal heran zoomen können. So kenn ich das zumindest von
dem Tek mit dem ich arbeite.
Tatsächlich kann ich aber nur bis 1ms/div verstellen. Klar kann ich das
Signal nur im Rahmen der aktuellen Samplerate auflösen, dennoch sollte
das funktionieren.
Das dies notwendig sein kann weiß ich aus meiner aktuellen Arbeit. Mit
einem einfachen Triggerereignis hätte mir da nicht geholfen, aber das
Reinzoomen.
Man muss immer davon ausgehen, dass man am Anfang nicht weiß wonach man
in einem Signal sucht. Erst wenn man weiß wonach man sucht (dazu sollte
man das Ereignis mal wenigstens kurz über den Bildschirm gerauscht haben
sehen) kann man den Trigger auf ein entsprechend Ereignis einstellen.
Daher auch mein oberer Beitrag nach Sinn oder Unsinn der
Bildschirm-aktualisierung bei fehlendem Triggerereignis.
Beste Grüße, branadic
Hallo alle,
da ja Einiges aufgelaufen ist, mal ein paar Anmerkungen.
@ branadic: Das eigentliche Problem ist ja, dass afaik es keine
Triggerung gibt. Es wird gesampled und anschließend das Sample
nach einem passenden Event durchsucht. Das mit dem Zoomen im
Stop-Modus schaue ich mal an. Ich fürchte nur, dass es mal wieder
kein Bug sondern ein Feature ist, weil es sonst garnicht geht (Hayo
kann da nix für).
@ Hayo: Mach dir keine Gedanken um den Quatsch mit PW-Triggerung. Das
ist was für Logicanalyzer und im Source wohl noch drin wie andere
LA-Fragmente.
@ Michael Werner: Ob USB oder RS232 spielt eigentlich keine große
Rolle. Ein USB-Zugang wäre halt für die Leute wertvoll, die keine
RS232-Schnittstelle mehr haben. Einfach wird das aber nicht, da
sich das Welec als HID anmeldet und damit ein entsprechender Treiber
benötigt wird. Eine verbesserte Version des Welec-Updaters wäre
schon schön. Die enorme Flashdauer hierin wird wohl hauptsächlich
durch den Einsatz einer Klasse für RS232 hervorgerufen, die sowohl
für Linux als auch Windows nutzbar ist. Uhhnd, blos nix gegen den
GERMS-Monitor, der hilft sogar, wenn man fast alles kaputt geflasht
hat.
Gruß, Guido
Zum Trigger: Agilent bietet die 2 Einstellungen "Normal" und "Auto".
Erstere zeichnet nur neu, wenn auch ein Trigger-Ereignis stattgefunden
hat, letztere triggert immer mal wieder (0.3 s?) und zeichnet auch, was
dann gemessen wurde. Beide sind nützlich.
Ein Oszi ohne Pulsweitentriggerung kommt mir nicht mehr ins Haus. Das
ist mitnichten etwas für einen LA!
@Karl
das heißt also das WELEC läuft im "Normal" Modus, und es fehlt
eigentlich nur der "Auto" Modus.
Es ist also kein Bug sondern ein fehlendes Feature - korrekt?
Hayo
So, ich kann nun auch compilieren. Wenn es also eine Kleinigkeit gibt,
die sich für den Einstieg eignet könnte ich mich daran versuchen. Werde
in der nächsten Zeit mal versuchen mich in den Code einzuarbeiten...
Uum Reinzoomen:
in der Uni arbeite ich mit einem Agilent. Dort kann man im Menü auf
"High Resolution" umstellen. Dann samplet das Osiz höher und man kann
ohne Probleme reinzoomen. Das ist schon sehr praktisch.
Ob man sonst eine Beschränkung in der Zeitbasis hat, kann ich aber
gerade nicht sagen.
Hat schon jemand das Makefile von Günter ausprobiert? Wenn das
funktioniert wäre es ja super zum Testen. Werde mal heute Nachmittag
probieren ob es bei mir klappt.
MfG, Michael
michaelk schrieb:
> So, ich kann nun auch compilieren. Wenn es also eine Kleinigkeit gibt,> die sich für den Einstieg eignet könnte ich mich daran versuchen. Werde> in der nächsten Zeit mal versuchen mich in den Code einzuarbeiten...
Die Datenübertragung via USB für die PC-Software ist von mir weder
getestet noch komme ich dazu hier was zu bauen (evtl. Erweiterungen).
Hier wäre also Unterstützung notwendig.
Mein letzter Stand war, dass die FW1.2 einen Fehler in der
Datenübertragung hat, und die Open Source FW basiert ja auf einer frühen
Version der 1.2 FW (anscheinend aber nicht auf der offiziellen FW1.2).
> Uum Reinzoomen:> in der Uni arbeite ich mit einem Agilent. Dort kann man im Menü auf> "High Resolution" umstellen. Dann samplet das Osiz höher und man kann> ohne Probleme reinzoomen. Das ist schon sehr praktisch.
Solche Sachen müssen erstmal auf die Wunschliste, es macht keinen Sinn
damit anzufangen solange so viele unerledigte Baustellen offen sind.
Deshalb bin ich mit der FFT ja auch noch nicht weiter, da ich einsehen
mußte, das es einfach keinen Sinn macht. So langsam kommt aber Struktur
in die Sache und ich denke wir können bald anfangen die Wunschliste
abzuarbeiten.
> Hat schon jemand das Makefile von Günter ausprobiert? Wenn das> funktioniert wäre es ja super zum Testen. Werde mal heute Nachmittag> probieren ob es bei mir klappt.
Ich werde heute ein komplettes Build zur neuen 0.62 beta zur Verfügung
stellen
Hayo
Kurt Bohnen schrieb:
> Was meint ihr zum weglassen des Startbildschirms?
Meinst Du den ganzen Startbildschirm mit Versionsanzeige etc. oder nur
das Logo? Ich finde das immer ganz nützlich. Außerdem braucht die Kiste
die Zeit ohnehin um sich zu initialisieren.
Ich kann aber gerne mal eine logofreie Version machen wenn das der
konsenz ist.
Hayo
@Kurt
ja und es wird auch noch etwas länger dauern wenn ich die FFT
implementiere, da ich die Zeit der Sartsequenz nutzen werde um die
trigonometrischen Tabellen anzulegen (zumindest solange die nicht im
Flash untergebracht sind). Diese Funktion ist zur Zeit nur deaktiviert
weil ich mit dem Rest der FFT noch nich´t so weit bin.
@all
Zur Zeit bin ich beim Feintuning der DAC-Calibration Routine. Dabei bin
ich auf einige Ungereimtheiten (mal wieder) beim Setzen der ADC-Register
der Kanäle 3 + 4 gestoßen. Evtl. könnten hieraus einige der für Kanal 3
+ 4 gemeldeten Effekte resultieren. Ich werde der Sache mal nachgehen.
Gruß Hayo
Hallo,
nochmal zur Triggerung: mein Tek TDS210 verhält sich da exakt
genauso wie die Beta 0.59. Von Fehler kann also wohl keine Rede
sein, eher von Wunschliste.
Wenn sich jemand an der Firmware was vorknöpft, bitte hier
melden, damit nichr mehrere Leute am selben Problem arbeiten. Das
gibt sonst nur Frust und Probleme gibt es ja genug für alle.
Gruß, guido
@ Guido:
kannst Du mir mal einen Tipp geben, wie Du die Entwicklungsumgebung auf
Ubuntu eingerichtet hast? Das, was im Forum stand, war ein wenig kurz
und unsortiert. Ich bin gerade dabei 'Mint' bei mir einzurichten,
gefällt mir besser als normales Ubuntu.
@Hayo:
kann ich Dein komplettes Build so übernehmen oder muss ich Anpassungen
machen? Sind Deine letzten FWs (oder die letzte) komplett oder muss ich
die alten Source dazubauen?
Besten Dank im Voraus
Michel
@ Michael W: Ich habe garnichts eingerichtet (wenn ich mich recht
erinnere). Nur das ndk4nios nach /usr/local kopiert (ausgepackt).
Im Makefile musste ich noch /usr/include in die Include-Liste
aufnehmen. Zum Kompilieren muss ich einmal/Tag den Pfad erweitern,
mit meiner Einrichtung mit:
"export PATH=$PATH:/usr/local/ndk4nios/bin".
Dann läuft make im "Official Build" durch. Für neue Betas mache ich
erst make clean und überschreibe dann das src-Verzeichnis im
Official Buil mit Hayos neuem src.
@ Michael W.:
die Einrichtung auf Ubuntu ist eigentlich sehr einfach. Du lädst dir die
deb-Pakete von der Google-Groups-Seite runter und installierst sie
(entweder per Doppelklick oder im Terminal mit dpkg -i ...). Danach
musst du noch den Installationspfad (z.B. /opt/cdk4nios) in die
PATH-Variable eintragen (z.B. export PATH=$PATH:/opt/cdk4nios/bin). Dann
brauchst du noch unix2dos. Das kannst du über die Paketverwaltung
installieren (tofrodos). Danach solltest du im Terminal per make-befehl
compilieren können.
Hi,
danke erstmal, nach dem zweiten Versuch habe ich Mint dann auch
draufbekommen (Installerscript ist wohl buggy). Nachdem mir das Script
den Windows Boot zerschossen hat, muss ich erstmal sehen, wie ich den
wieder hinbekomme - shit, ist mir ewig nicht mehr passiert (hab seit
Slackware 4.x in regelmäßigen Abständen mit diversen Linuxen gespielt).
Ärgerlich, wahrscheinlich muss ich Alles platt machen und wieder neu
installieren (Win & Linux) :-(.
WinXP Boot macht Bluescreen...
Michel
>wahrscheinlich muss ich Alles platt machen und wieder neu>installieren (Win & Linux) :-(.
Blos nicht! Eine Reparatur müsste doch einfach sein, erstmal
mit der Windows-CD. Weitere Möglichkeiten könnte ich noch
suchen.
Guido
Das komplette Build welches ich heute auf Google Groups zur Verfügung
stelle muß man einfach nur in ein beliebiges Homeverzeichnis kopieren.
Nach einem "make clean" und anschließendem "make all" (man muß natürlich
ins Buildverzeichnis wechseln) sollte alles durchlaufen.
Hayo
So hier kommt sie die 0.62 beta.
Highlight: Die DAC-Kalibrierung funktioniert jetzt richtig gut. Ich habe
eine How to für den Abgleich beigelegt.
Zusätzlich habe ich Registerwerte für den Kanal 3 + 4 verändert. Bei mir
konnte ich keine Auswirkungen beobachten. Wer was feststellt bitte mit
detailierter Beschreibung posten.
Die Beschreibnungen für die Linuxinstallation habe ich mit neuen Links
versehen u.a. zum aktuellen Build 0.62. Die Sources und das komplette
Build sind auf Google Groups verfügbar.
http://groups.google.com/group/welec-dso/files ->
BlueFlash_Build_0_62.zip
Gruß Hayo
Hallo Bruno,
ich habe gerade deine neue FW aufgespielt und wie beschrieben den
Abgleich durchgeführt, für alle Kanäle in allen Spannungsbereichen.
Die Linien liegen sauber um Null und schauen recht glatt aus.
Danach habe ich mal das 1kHz-Testsignal hergenommen und mir auf den
einzelnen Kanälen angeschaut.
Trotz DC-Coupling wird das Signal auf allen Kanälen wie AC-Coupling
dargestellt.
Auf Kanal 2 stimmt auch irgendwas nicht. Hier wird das Signal um Faktor
8 größer als auf den anderen Kanälen wiedergegeben. Hab alle Kanäle auf
10:1 eingestellt. Kanal 1 3 4 sind auf Einstellung 500mV/div, Kanal
zwei auf 2V/div.
Auf Kanal drei zeigen sich mit dem Testsignal am Tastkopf größere
Störungen/ Ausbrecher, nimmt man das Signal wieder weg schaut die Linie
glatt wie zuvor aus.
Soweit gerade die ersten Dinge, die mir aufgefallen sind.
Ich hoffe es ist detailiert genug beschrieben. Ich bitte das Photo zu
entschuldigen, aber ich denke man kann das von mir beschriebene erahnen.
Beste Grüße, branadic
Mist aber auch, scheine auch schon irgendwie durch den Wind zu sein. Das
passiert, wenn man mit dem Kopf gleichzeitig bei verschiedenen Dingen
ist. Streiche Bruno und schreibe Hayo. Asche auf mein Haupt!
Gruß, branadic
branadic schrieb:
> ich habe gerade deine neue FW aufgespielt und wie beschrieben den> Abgleich durchgeführt, für alle Kanäle in allen Spannungsbereichen.> Die Linien liegen sauber um Null und schauen recht glatt aus.
Wie bei mir auf beiden Geräten. Ich hatte allerdings das Gefühl das die
Nulllinien auch noch eine leichte thermische Drift haben. Wenn das Gerät
kalt ist liegt der Nullpunkt ganz leicht verschoben zum warmen Gerät.
> Danach habe ich mal das 1kHz-Testsignal hergenommen und mir auf den> einzelnen Kanälen angeschaut.> Trotz DC-Coupling wird das Signal auf allen Kanälen wie AC-Coupling> dargestellt.
Ich hab mal mit dem Signalgenerator getestet, die AC/DC-Kopplung
arbeitet korrekt.
> Auf Kanal 2 stimmt auch irgendwas nicht. Hier wird das Signal um Faktor> 8 größer als auf den anderen Kanälen wiedergegeben. Hab alle Kanäle auf> 10:1 eingestellt. Kanal 1 3 4 sind auf Einstellung 500mV/div, Kanal> zwei auf 2V/div.
Du mußt Dich da irgendwie beim Messen verhauen haben. Hast Du Tastköpfe
verwendet? Wenn ja, sind die alle auf 1:1 eingestellt?
Hab mit dem Signalgenerator an 50 Ohm Abschluß mit 1KHz mit Deinen
Einstellungen getestet - alles ok.
> Auf Kanal drei zeigen sich mit dem Testsignal am Tastkopf größere> Störungen/ Ausbrecher, nimmt man das Signal wieder weg schaut die Linie> glatt wie zuvor aus.
Nicht meine Schuld, bzw. nicht die der FW. Das sind Störungen bzw.
Schwingungen die zusätzlich eingekoppelt werden.
> Soweit gerade die ersten Dinge, die mir aufgefallen sind.
Danke für die schnelle Rückmeldung
> Ich hoffe es ist detailiert genug beschrieben. Ich bitte das Photo zu> entschuldigen, aber ich denke man kann das von mir beschriebene erahnen.
Das Foto ist allerdings harter Toback. So sieht mein Gesichtsfeld nach
einer durchzechten Nacht aus ;-)
Gruß Hayo
Hallo Hayo,
nein ich habe mich nicht verhauen. Ich habe die Tastköpfe verwendet und
alle auf 10:1 eingestellt, hatte ich ja auch geschrieben.
Und wie gesagt, AC/DC-Coupling funktioniert bei mir mit der neuen FW
nicht mehr korrekt.
Das Kanal drei Störungen zeigt wollt ich auch nicht auf die FW schieben,
wollt es nur erwähnt haben.
Wegen dem Photo, so sieht das halt aus, wenn man das Telefon als Kamera
verwendet.
Gruß, branadic (der die FW jetzt noch mal erneut aufspielt)
Help compile...
Ich bekomme immer
michael@michael-laptop ~/W20xx_Firmware/src $ make all
# 2009.05.17.19:07:48 --- (Note: to make for Nios 16, try "make clean
all M=16")
make: *** Keine Regel vorhanden, um das Target »obj/TomCat.cpp.o«,
benötigt von »obj/TomCat.out«, zu erstellen. Schluss.
-----
what's wrong?
Michel
Und so die AC/DC Kopplung.
Das Signal hat einen DC-Offset von ungefähr halber Sigalamplitude wie
man sehen kann.
Oben auf Kanal 1 DC-gekoppelt unten auf Kanal 2 AC-gekoppelt. alles wie
gehabt bei 1 KHz an 50 Ohm
Hayo
Ich hab bisher nur die DAC-Kalibrierung getestet, und das klappt am 2024
nunmehr einwandfrei. Alle Kanäle liegen genau auf der Höhe des
Nullmarkers. Super Sache. :)
Jetzt stört an sich "nur" noch das utopische Rauschen. Solange man in
den 5er Bereichen messen kann, geht es auch so, aber leider hab ich
zufällig gerade eine Standardanwendung, wo es eben nicht klappt.
/Hannes
Michael W. schrieb:
> Help compile...>> Ich bekomme immer> michael@michael-laptop ~/W20xx_Firmware/src $ make all> # 2009.05.17.19:07:48 --- (Note: to make for Nios 16, try "make clean> all M=16")> make: *** Keine Regel vorhanden, um das Target »obj/TomCat.cpp.o«,> benötigt von »obj/TomCat.out«, zu erstellen. Schluss.
Wenn ich das richtig sehe hast Du die Anleitung nicht richtig gelesen.
Du machst Dein make all im Sourceordner, richtig? Du must dazu aber im
Buildordner sein, damit der Compiler alles findet. Steht auch in der
Anleitung.
Versuchs nochmal so.
Gruß Hayo
@Hannes
Tja den Rest Rauschen kann man nur Reduzieren, wenn man die
Eingangsteilung verändert, und zwar so, dass der Fullscalebereich des
ADC besser genutzt wird. In den 2er und 1er Bereichen werden nur 128 Bit
genutzt. Dadurch muß das Signal so aufgezoomt werden, dass das Rauschen
natürlich richtig heftig wird.
Hayo
Was mir gerade so durch den Kopf geht -
Man könnte natürlich die vorhandenen Bereich umskalieren.
Der 1er Bereich wäre dann ein 2er Bereich und der 2er ein 4er. Damit
sollte das Rauschen dann minimal sein. Die Schrittweite beim Umschalten
wäre dann allerdings nicht mehr normgerecht.
Hayo
Hm, das ist mir ansatzweise klar, und ich warte ja schon sehnsüchtig,
dass ihr euch im Zusammenspiel zwischen Hardware- und Firmwarefraktion
eine ganz tolle neuartige Methode einfallen lasst. :-D
/Hannes
Hallo Hayo,
ich hab die FW erneut aufgespielt, es ändert sich nichts.
Der Faktor auf Kanal 2 hat sich als Faktor 10 herausgestellt. Ich messe
direkt mit dem Tastkopf an der Probe-Buchse. Ich lass das Gerät jetzt
mal eine Weile laufen und mache nachher ein paar Messungen mit dem
DDS-10.
Die deutlich größeren Störungen auf Kanal 3 waren in den vorherigen
FW-Versionen nicht so extrem. Werd noch mal ein wenig herumspielen.
AC/DC-Coupling macht bei mir keinen Unterschied, keine Ahnung was da los
ist.
Gruß, branadic
branadic schrieb:
> Der Faktor auf Kanal 2 hat sich als Faktor 10 herausgestellt. Ich messe> direkt mit dem Tastkopf an der Probe-Buchse.> Die deutlich größeren Störungen auf Kanal 3 waren in den vorherigen> FW-Versionen nicht so extrem. Werd noch mal ein wenig herumspielen.>> AC/DC-Coupling macht bei mir keinen Unterschied, keine Ahnung was da los> ist.
Bei allen drei Punkten spielen Dir garantiert die Tastköpfe einen
Streich. Deshalb mache ich meine Testmessungen auch immer an 50 OHm,
denn da gilt:
What You see it what You mess (oder so ähnlich).
Hayo
Hallo zusammen!
@Hajo
Irgend etwas stimmt wohl doch nicht mit Deiner Erklärung?
Laut Stromlaufplan und laut meiner Messung mit Multimeter sollte das
1kHz Referenzsignal doch etwa symmetrisch um die Masse liegen. Ergo
sollte es keinen Unterschied zwischen AC- und DC-Kopplung geben!
Oder?
Gruß Jürgen
Hallo Hayo,
die Spannungsbereiche lassen sich ja noch leicht etwas verbessern,
wenn man die Verstärkungen 1.25/2.5/5 wählt. Hatte ich mal eine
Firmware mit gebaut, bin aber nicht zum Testen gekommen und
sonst hatte wohl auch keiner Lust.
Damit hätten wir 200/160/160 Werte. Hätte mich interessiert, warum
Wittig das geändert hat.
Ein 4er Bereich neben dem 5er ist halt suboptimal.
Gruß, Guido
Jürgen schrieb:
> Irgend etwas stimmt wohl doch nicht mit Deiner Erklärung?> Laut Stromlaufplan und laut meiner Messung mit Multimeter sollte das> 1kHz Referenzsignal doch etwa symmetrisch um die Masse liegen. Ergo> sollte es keinen Unterschied zwischen AC- und DC-Kopplung geben!
Meine Tests sind alle mit einem externen Signalgenerator durchgeführt an
50 Ohm. Wenn ich im DC-Betrieb einen Offset draufgebe wird dieser auch
korrekt dargestellt. Bei AC-Kopplung geht das Signal kurz mit dem Offset
mit und geht dann aber wieder auf Mitte.
So soll es doch auch sein oder?
Was das Testsignal angeht, ich hab es mit dem Tastkopf gemessen - wie Du
schon sagst, da es keinen DC-Offset hat sieht es in beiden
Kopplungsarten gleich aus.
Hayo
Hi Hayo,
das Build fehlte, besten Dank. Bei Google groups war es aber nicht oder?
Nur Dein neues war da. Nun bekomme ich:
...
# 2009.05.17.20:12:57 --- Converting TomCat to S-Record
cat loader.flash > TomCat.flash
cat TomCat.srec >> TomCat.flash
unix2dos TomCat.flash
# 2009.05.17.20:12:57 --- Making TomCat.nm
# 2009.05.17.20:12:57 --- Making TomCat.objdump
Segmentation fault
make: *** [obj/TomCat.objdump] Fehler 139
michael@michael-laptop ~/Build $
....
'n Tipp?
Danke
Michel
Hayo schrieb:
> Meine Tests sind alle mit einem externen Signalgenerator durchgeführt an> 50 Ohm. Wenn ich im DC-Betrieb einen Offset draufgebe wird dieser auch> korrekt dargestellt. Bei AC-Kopplung geht das Signal kurz mit dem Offset> mit und geht dann aber wieder auf Mitte.
Ach so, na dann passt ja alles!
Vielleicht hat Guido ja Recht mit disablen des Testgenerators ;-)
Jedenfalls ist die Bildwiederholrate in der 0.62-er super!
Jürgen
So, ich habe jetzt noch mal die FW neu aufgespielt, alle Leitungen
gegengeprüft, da war tatsächlich der Wurm drin und alles kalibriert.
AC/DC funktioniert jetzt auch bei mir, hab jetzt mein DDS10 dran und
einen Rechteck angeschaltet.
Das Terminalprogrammt spuckt nach der Kalibrierung und dem Abspeichern
der Werte auf allen ADC's einen Offset von 0 aus.
Die DAC-Korrekturwerte liegen bei mir zwischen 82 und 133.
Was aber als Behauptung stehen bleibt ist, dass Kanal 3 bei mir schon
mal in einer der vorherigen Versionen schöner aussah.
Die Störungen sind bei einem Rechtecksignal noch recht klein, schalte
ich aber auf Sinus um machen sich die Störungen um so mehr bemerkbar.
Aber etwas ähnliches hatten wir ja schon einmal als Thema. Bei Kanal 3
schein Welec irgendwas versaut zu haben.
In der x-y-Darstellung scheint der Offset von Kanal 1 und 3 invertiert
zu sein. Dreh ich nach links wandert das Signal nach rechts. Muss ich
hier nur umdenken oder sollte das nicht anders sein? Ich meine mich
daran erinnern zu können, dass das beim Tek anders ist.
Gruß, branadic
Michael W. schrieb:
> Hi Hayo,> das Build fehlte, besten Dank. Bei Google groups war es aber nicht oder?> Nur Dein neues war da. Nun bekomme ich:
Wie schon oben geschrieben:
http://groups.google.com/group/welec-dso/files
-> BlueFlash_Build_0_62.zip
> make: *** [obj/TomCat.objdump] Fehler 139
Den 139 er Fehler bekomme ich momentan auch. Weiß aber nicht woran es
liegt. Betrifft aber anscheinend nicht die erzeugte Firmware, denn die
läuft trotzdem problemlos. So wie es aussieht ist es nur der Objektdump
der davon betroffen ist.
Hayo
@Hayo:
ich hatte Deinen Build bei Google Groups schon gefunden nur das
Originale nicht. Und die paar Dateien in den Firmwareupdates kamen mir
für ein Build immer sehr wenig vor.
Denn kann's jetz ja für mich auch losgehen :-)
Kann man die Source für den Updater irgendwo laden? Ich finde nur
'Exen'...
Michel
ich hab hier auch so eine fw bei der in allen bereichen die 1,25
vorverstärkung aktiv ist. es ist die .59 von hayo. falls jemand sich mal
den unterschid ansehen will.
@hayo
ist denn die änderung für adc fullscale nicht ziemlich umständlich? es
müssten ja eine menge änderungen gemacht werden. ein interessanter test
währe es sicherlich.
sunny schrieb:
> ist denn die änderung für adc fullscale nicht ziemlich umständlich? es> müssten ja eine menge änderungen gemacht werden. ein interessanter test> währe es sicherlich.
Ist schon in Arbeit, kommt nachher, muß erstmal uploaden und testen.
War selbst mal neugierig...
Hayo
Hier die umskalierte 0.62 experimental. Sehr eindrucksvolle
Demonstration dessen was ich an Theorie hier schon zum Besten gegeben
habe.
Besonders interessant für diejenigen, die wie ich zwei Geräte haben und
daher direkt den originalen 200mV Bereich mit dem umskalierten 200mV
Bereich vergleichen können.
Wenn jetzt der Eingangsteiler für die 4er und für die 2er Bereiche um
Faktor 2 angepasst würde (Widerstände ändern) dann hätten wir auch
wieder unsere 2er und 1er Bereiche aber mit dem reduzierten Rauschen.
Wenn ich mir das so ansehe bin ich echt am Überlegen ob ich mir da ein
paar andere Widerstände reinlöte.
Gruß Hayo
Guten Abend zusammen,
vorab erstmal meine volle Hochachtung an alle, die hier Zeit und Nerven
investieren, um nicht nur sich sondern auch der Allgemeinheit etwas
Gutes zu tun.
Da ich momentan selbst auf der Suche nach einem günstigen DSO bin,
verfolge ich die Entwicklungen um die Wittig- Oszis seit etwa einer
Woche. Mit den ständigen Verbesserungen werden die Geräte zunehmend
interessanter für mich. Leider habe ich aber bis dato noch kein
vollständiges Bild im Kopf, was die Geräte denn nun können und was
nicht. Gibt es denn irgendwo eine Übersicht die darstellt, was
- fehlerfreie Funktionen
- eingeschränkt benutzbare Funktionen
- fehlende / nicht nutzbare features
an diesem Gerät (gemessen an normalen Eigenschaften eines DSO in der
Leistungsklasse) sind?
Falls es so etwas nicht gibt: lässt sich sagen, was die gravierendsten
Vor- und Nachteile, beispielsweise im Vergleich mit einem TDS210 o.ä.
sind?
Das würde mir eine Kaufentscheidung deutlich erleichtern....
Viele Grüße und macht weiter so,
odic
Hallo Hayo,
mal langsam zum Mitdenken. Du hast jetzt die Verstärkung des OPA
auf 1 geschaltet (keine Umschaltung mehr) und damit insgesamt die
Verstärkungen 1-2-4. Richtig? Damit wird Auflösung verschenkt.
Oder hast du 1,25-2.5-5 mit dem OPA immer auf Vu=1.25?
Welche Widerstände willst du denn umlöten? Da stehe ich völlig auf
dem Schlauch.
Gruß, Guido
@Odic
Es kommt auf Dein Einsatzgebiet drauf an. Für den Hobbybereich bei
Frequenzen bis 25 MHz auf jeden Fall ein Schnäppchen. Bei höheren
Ansprüchen nur nach Verbesserungen an Hard und Software. An beidem sind
wir dran - allerdings ohne Garantien. Für professionelle Zwecke lieber
ein Tek oder Agilent.
Hayo
Hallo odic,
ganz klar: wenn du ein Oszi für die tägliche Arbeit suchst, lass
die Finger von dem Welec. Wenn du für rel. wenig Geld ein tolles
Spielzeug mit Zukunft willst, bist du damit bestens bedient. Afaik
gibt es am Welec keine fehlerfrei Funktion, viele sind aber schon
benutzbar.
Soweit erstmal, Guido
Guido schrieb:
> mal langsam zum Mitdenken. Du hast jetzt die Verstärkung des OPA> auf 1 geschaltet (keine Umschaltung mehr) und damit insgesamt die> Verstärkungen 1-2-4. Richtig?
Falsch. Ich hab an der Verstärkung nix geändert. Ich hab bloß die
Skalierung für die Ausgabe geändert. Dadurch bleibt der 5er Bereich ein
5er Bereich aber der 2er wird ein 4er und der 1er wird ein 2er Bereich.
Ergibt die Schritte 5V/4V/2V/0,5V/0,4V/0,2V usw
> Welche Widerstände willst du denn umlöten? Da stehe ich völlig auf> dem Schlauch.
Wenn ich das richtig in Erinnerung habe gibt es ein Widerstandsnetzwerk
welches eine Vorteilung vornimmt (korrigier mich wenn ich da falsch
liege). Wenn man die Vorteilung für die beiden Bereiche um Faktor zwei
ändert dann kann man mit der umskalierten FW wieder mit den normalen
Bereichen arbeiten 5V/2V/1V/etc.
Hab ich das vernünftig erklärt oder war das eher konfuziös?
Hayo
Hallo Hayo,
ich fürchte heute wird das bei mir nix mehr. Wird aber langsam besser.
Ich glaube jetzt kann ich dir folgen (habe gerade 3 mal editiert).
Die Teiler sind aber nur für die Bereiche ab 100 mV/div zuständig,
Mit der Änderung fliegen die Grundbereiche 50-20-10 mV/div über
Board. Das ginge wieder nur mit mehr (Hardware-) Verstärkung.
Ich muss jetzt gleich noch einen (kurzen) Testberich schreiben.
Gruß, Guido
So jetzt sauber getrennt zur Beta 0.62:
@ Hayo: Super, die Kalibrierung von ADC und DAC funktioniert für
meine 2 Kanäle perfekt. Das ist wirklich ein Fortschritt, die
Testfunktionen können dann gelegentlich entfernt werden (damit
die Tasten frei werden ;-)).
Eine kleine Unstimmigkeit ist mir noch aufgefallen: Im Delayd-Mode
werden die Offset-Marken für beide Kanäle im unteren Fenster leicht
verschoben dargestell. Im oberen Fenster sind sie korrekt.
Nochmal Gruß, Guido
Hallo Hajo, hallo Guido,
100% Ack für Guido! Was soll wohin scaliert werden? Es kann alles
angepasst werden. Wo haben wir definiert was 100% für die Anzeige sind?
Bisher sind sicher nur 8Bit für 100% definiert :-) Sind 100% ADC jeweils
8 Divs(mit entsprechendem Faktor) = 100% TFT in jedem (1,2,5-er)Bereich?
Wollen wir uns an die üblichen Bereiche 1-2-5 halten?Alles weitere
leitet sich daraus ab. Mit Sicherheit ergeben die kleinsten
Softwarefaktoren auch das geringere Rauschen!
Dank Hajo`s bisheriger fantastischer Arbeit ist ein guter Stand
erreicht, aber es gibt genug Baustellen, die abgearbeitet werden müssen:
z.B. Triggerung allgemein, PW-Triggerung, USB-Comm... usw., somit die
endgültige Scalierung wohl auch von den Ergebnissen an der HW-Seite
abhängt! Die Scalierung sollte nach meiner Meinung jetzt nicht mehr die
höchste Priorität haben.
Gruß Jürgen
"keine fehlerfreie Funktion"... höre ich da einen gewissen Zynismus? ;-)
Danke für eure Antworten, ich muss aber doch nochmal nachhaken. Ich
vermute, dass noch niemand eine vollständige Qualifizierung des Geräts
durchgeführt hat. Daher frage ich gar nicht nach Punkten wie
Messgenauigkeit, Temperaturverhalten o.ä.
Vielmehr interessieren mich ganz pragmatische Punkte, die für ein
halbwegs vernünftiges Arbeiten mit dem Scope - selbst im Hobbybereich -
erforderlich sind. Hiermit meine ich beispielsweise:
- Skalierung von Amplitude und Zeitachse (schrittweise / frei, auch nach
der Triggerung)
- Verschieben der Signale in X- und Y-Richtung (auch nach der
Triggerung)
- (funktionierende) Einstellmöglichkeiten für die Triggerung (Single,
Normal, Auto, Triggerquelle, ...) und deren Zuverlässigkeit
- Möglichkeiten der Signalkopplung
- ...
Vielleicht könnte man - falls es so etwas noch nicht gibt - mal eine
Liste von Oszi-Eigenschaften inkl. (subjektiver) Bewertung deren
technischer Umsetzung im Wittig-Scope erstellen.
Ich habe zwar selbst kein Gerät, kann mich aber an der Erstellung der
Kriterien gerne beteiligen...
odic
hi hayo,
die ergebnisse sehen ja ganz nett aus. mit der änderung der verstärkung
des eingangsverstärkers ist das so eine sache. die verstärkungen für die
1,2 und 5er bereiche werden nicht durch ein wiederstandsnetzwerk
festgelegt.
es sind 3 volldifferenzial opv's verbaut welche intern fest auf eine
verstärkung von 2 eingestellt sind. die umschaltung der verstärkungen
erfolgt, indem 2 der 3 opv's etweder mit einem symetrischen (effektive
verstärkung=2) oder mit einem asymetrischen eingangssignal (effektive
verstärkung=1) betrieben werden. dafür wird jeweils ein eingang durch
einen analogschalter etweder auf masse oder auf den ausgang des vorigen
opv geschaltet.
man müsste diesen verstärkerteil also neu designen. daran arbeite ich
zzt. komm nur im momment nicht so recht weiter. wer interesse hat, kann
hier noch etwas mehr darüber lesen.
http://d-amp.org/include.php?path=forum/showthread.php&threadid=586&postid=last
Hallo odic,
>"keine fehlerfreie Funktion"... höre ich da einen gewissen Zynismus? ;-)
nö, kein Zynismus, uns macht das ja Spaß. Es ist halt momentan wirklich
so, dass die von dir angesprochenen Eigenschaften (was verstehst du
unter: nach der Triggerung?) vorhanden sind, zum größten Teil aber nicht
das gewünschte Ergebnis bringen. Wie du dem Thread entnehmen kannst,
wird
noch an der Darstellung der Messwerte auf dem Bildschirm gearbeitet, da
diese unbefriedigend ist. Die anderen Dinge (z.B. eine funktionierende
Triggerung) sind erstmal aufgeschoben, aber je mehr Leute sich an der
Entwicklung beteiligen, desto schneller geht es.
Gruß, Guido
@Sunny
Hm, schade, dann ist die Änderung der Vorteilung wohl doch etwas
schwieriger. Wenn Du und Bruno da weiter kommen könnte es ja dennoch was
werden. Ihr könnt ja auf jeden Fall die Anforderung im Hinterkopf
behalten.
@Odic
Die Punkte die Du hier aufzählst sind eher als unkritisch einzustufen.
Entweder sie sind schon benutzbar oder sie lassen sich rein
Softwaretechnisch nachrüsten. Kritischer ist da die Reduzierung des
Rauschens welches als eines der Hauptmankos von den meisten hier
wargenommen wird.
Dennoch läßt sich mit dem Gerät auch jetzt schon eine Menge im
Hobbybereich anstellen. Nicht zuletzt ist es eine schöne Spielwiese für
Optimierungswütige!
Eine kleine Sammlung an Punkten findest Du in dem Beta-Paket in der
readme Datei (bzw. liesmich) und im Header der tc_vars.cpp.
Hayo
Hi,
bei mir leider nicht alles ok nach dem neuen Update...
Werde wohl nochmal flashen.
Probleme:
Kanal 1 und 4 triggern nicht, Kanal 2 nur auf fallend und Kanal 3 auf
steigender Flanke. Da ist MEIN Build wohl doch nicht erfolgreich
gelaufen. Werde ich Hayo's Kater nochmal flashen (müssen)... :-/
Michel
@Kurt
Quick Measure und Cursorpositionen muß ich noch machen, das hatte ich
erstmal aufgeschoben bis die Skalierungsfragen geklärt sind, sonst muß
ich das evtl. doppelt machen.
@Michael
der Trigger funktioniert leider auch bei mir nur bedingt. Insbesondere
Rechtecksignale scheint er nicht zu mögen, während es bei Sinus
erheblich besser klappt. Auch das ist noch eine offene Baustelle die
ebenfalls mit der Skalierung zusammenhängt und deshalb von mir
aufgeschoben wurde. Dazu kommt, das mir die technische Umsetzung der
Triggerung noch nich so ganz klar ist.
Vom Coding her habe ich den Eindruck, dass es eine kombinierte Harware-
und Softwaretriggerung ist. Es werden für die Triggerung einige Register
gesetzt deren Zweck ich erst ergründen muß und es wird das Signal
Softwareseitig je nach Triggerung im Fensterausschnitt hin und her
geschoben.
Vielleicht können die Jungs von der Hardwarefront hier etwas zur Klärung
beitragen. Ich wüßte auch nicht, wie sonst der externe Trigger
realisiert sein sollte wenn nicht hardwareseitig.
@all
Da jetzt doch einige Köche im Brei rühren hier zur Abstimmung ein kurze
Roadmap die ich mir vorgenommen habe:
- Codeoptimierung an der Skalierung, wird nach außen nicht weiter
sichtbar sein, wird aber den Code wartbarer bzw. erweiterbarer machen
für den Fall dass wir die Verstärkung Hardwareseitig ändern.
- Rollmode/Shiftmode für die ganz langsamen Zeitbasen implementiern.
Hierzu hab ich mir inzwischen einige Gedanken gemacht und das
Konzept steht schon (in Rohfassung)
- Trigger und Cursor auf die neue Skalierung anpassen evtl. bei der
Gelegenheit die Triggerung optimieren
- Mathfunktionen noch mal an die neue Integerskalierung anpassen.
- FFT implementiern. Hab ich teilweise schon implementiert, aber zur
Zeit deaktiviert angesichts der drängenden Probleme an anderen
Stellen.
Eine echte Hilfe wäre es wenn diejenigen, die neu einsteigen sich mit
dem Coding vertraut machen indem sie nach Fehlern suchen oder
grundsätzliche Funktionen erforschen wie z.B.:
- es wird nach meiner Vergrößerung des Grids immer noch der untere Rand
des Signals abgeschnitten. Fehler liegt vermutlich irgendwo in
CopyPlanes() und/oder TransferPlanes() an der Größe der übertragenen
Bildschirmabschnitte.
- Im delayed mode hab ich leider noch eine Verschiebung drin zwischen
oberem und unterem Fenster.
- Wie arbeitet die Triggerung im Detail?
Hayo
Hallo Hayo,
die ext. Triggerung wird wohl hauptsächlich in Hardware erledigt
(Schwelle über PWM, ..., Ausgang direkt auf den FPGA). Ich habe
den Eindruck, dass die interne Triggerung nur über Software
simuliert wird. Bei meinen 2 Kanälen geht es mit der 0.62, aber
halt nur, wenn das Signal den halben Bildschirm füllt.
Das abgeschnittene Signal kommt imho nicht von TransferPlanes,
da dort die Grenzen für alle Planes gleich sind und das Grid...
ja korrekt überttragen werden. Da muss man die ganze Kette ab
READADC_ALL untersuchen. Habe jetzt von Stefan nichts mehr
gehört, wenn er sich nicht mehr meldet, nehme ich mir das mal
vor.
Ev. sollte man die Roadmap als Artikel im Wiki anlegen, da kann
sich dann jeder mit Wünschen und Arbeitswillen melden. Das
kann doch bestimmt jemand besser als ich?
@ Kurt: Hat das QuickMeasure denn mal halbwegs vernünftig
funktioniert? Ich habe es nie ausprobiert. Es gibt da eine
Funktion CALCQMDATA, die ist mehr als 2400 Zeilen lang. Ich denke,
da muss man erstmal Struktur reinbringen.
Gruß, Guido
Halbwegs vernüftig ja. Aber doch recht ungenau und nicht immer in sich
schlüssig.
Man sollte wirklich mal eine Wiki Seite machen: Wer arbeitet aktuell
woran, wer testet auf welchem Gerät, an welchen Problemen wird z.Zt.
nicht gearbeitet und aus welchem Grund...
Mein W2024 ist seit Donnerstag unterwegs. Hoffentlich kommt es Heute.
Dann kann ich die offizielle Firmware noch einigen Test unterziehen.
@Guido
Ich bin mir da nicht sicher ob evtl. doch auch auf Hardwarebasis
getriggert wird. Das gilt es aber auf jeden Fall zu klären bevor wir da
am Coding rumschrauben
Wenn Du die Sache mit dem abgeschnittenen Signal fixen könntest wär das
natürlich super. Mein Ansatz war, einfach mal die einzelnen Planes
abzuschalten (in Transfer Planes auskommentieren) evtl. auch mehrere
gleichzeitig und dann mal sehen von welcher Plane das Signal
überschrieben wird. Das schränkt die Suche doch ungemein ein.
Hauptverdächtige sind ohnehin die unteren Bereiche der UI-Planes evtl.
auch die Marker-Plane.
Gruß Hayo
Hallo Hayo,
die aktuelle FW1.4 wurde nicht von Wittig/Welec auf der Homepage bereit
gestellt.
Das mit dem Wiki (im Sourceforge) halte ich für eine gute Idee, zum
jeder angemeldete User Änderungen vornehmen kann.
Vielleicht können wir da heute Abend was in Angriff nehmen.
Gruß, branadic
Hallo,
Problem gelöst, es müssen in den Transfer-Routinen halt einfach
die zusätzlichen 16 Zeilen transferiert werden. Hierzu habe ich
einfach den Loop-Counter entsprechend erhöht.
@ Hayo: einfach in hardware_t vom Editor alle 7740 durch 8060
ersetzen lassen, das wars. Die Zahlen sind dezimal in Longwords,
falls jemand nachrechnen möchte.
Gruß, Guido
Hallo Guido,
>Das abgeschnittene Signal kommt imho nicht von TransferPlanes,>da dort die Grenzen für alle Planes gleich sind und das Grid...>ja korrekt überttragen werden. Da muss man die ganze Kette ab>READADC_ALL untersuchen. Habe jetzt von Stefan nichts mehr>gehört, wenn er sich nicht mehr meldet, nehme ich mir das mal>vor.
Das WE war leider keine Zeit. Ein abgeschmierter Xp-Rechner in einer
saublöden Hardwarekonfiguration hat den ganzen Sonntag gekostet...
In den ganzen READADC-Assembler-Funktionen steige ich einigermaßen
durch. Wie ihr sicher erwartet habt, ist das nicht für schwache nerven,
wenn ich euch jetzt ein paar Details erzähle. Das der Code überhaupt je
funktionsfähig wurde, grenzt fast an ein Wunder.
@Hayo
Ich bin mir nicht sicher, wie weit du dich in den Assembler-Code
eingearbeitet hast, weil da ein Fragezeichen im Code angefügt ist. Für
das Verständnis erkläre ich mal einwenig den Ablauf der einzelnen
Funktionen
Also: zuerst muss READADC_ALL2 aufgerufen werden. Die Funktion liest den
genannten Kanal aus und speichert die gewünschte Anzahl Werte im
Speicher an der Andresse DataArray1.
Danach muss PREPARE_READADC aufgerufen werden. Die Funktion speichert
die Offsetwerte der vier ADC eines Kanals und die Anzahl der Samples in
globale Register.
READADC_ALL liest die in READADC_ALL2 eingelesenen Daten wieder aus und
sortiert um, verarbeitet sie weiter (invertieren, Offset-Abgleich,
Averaging) und speichert sie wieder ab. Die which-Parameter wird (so
sehe ich das) nicht abgefragt (ist also überflüssig).
Problematisch ist der Code an mehreren Stellen:
- Die Übergabe der einzelnen Funktionen erfolgt über globale Register
(gibt davon insgesamt 7 Stück). Da zwischen den ASM-Blöcken noch C-Code
liegt ist meineserachtens nicht sichergestellt, dass die Register auch
noch richtig gesetzt sind. Vielleciht ist irgendwo noch ein
Schutzmechanismus. So gut kenne ich mich damit aber nicht aus.
- In READADC_ALL2 kann man zwar einen anderen Adressbereich zum
Zwischenspeichern als Parameter angeben. Davon ist ab schwer davon
abzuraten genauso wie vor jeder Veränderung der Speicheraufteilung im
RAM. In den ASM-Blöcken finden sich nämlich Hart-Codierte Adressen
wieder. Alle Stellen zu finden, wo der Entwickler zu faul war,
Konstanten oder Zeiger zu verwenden, dürfe ziemlich aufwendig werden ;-)
Das Invertieren und Averaging findet unter Einbeziehung des
ZeroLevel-Wertes statt. Der Offset zum ZeroLevel wird allerdings erst
nach dem Averaging und Invertieren subtrahiert. Das ist wohl nicht
wirklich schlau ;-), da der Offset-Abgleich (zumindest beim Invertieren)
in die falsche Richtung wirkt
Gruß,
Stefan
Hallo Firmware-Gemeinde,
ich war mal so frei im Sourceforge-Wiki eine Seite für die Firmware
anzulegen. Ich war außerdem mal so frei Hayo's aufgeführte Roadmap
gleich mit zu übernehmen.
Soviel ich weiß hat Hayo ja einen Souceforge-Account. Alle anderen
FW-Entwickler würde ich bitten wollen, sofern nicht vorhanden, einen
solchen Account anzulegen, damit ihr im Wiki aktualisieren könnt.
Somit hätten wir eine gemeinsame Plattform, wo auch die Firmware erfasst
ist. Natürlich können wir die Seite um die bereits implementierten
Funktionen erweitern.
Beste Grüße, branadic
Hallo Stefan,
schön von dir zu hören ;-).
über die Inputregister würde ich mir nicht allzuviel Gedanken
machen, davon gibt es ja mehrere Sätze und ich unterstelle
einfach, dass der C-Compiler das im Griff hat.
Sowas mit der verdrehten Reihenfolge habe ich vermutet,
vielleicht kannst du das einfach mal umdrehen und probieren.
Wenn es dann doch wieder Probleme gibt, müssen wir da halt
tiefer einsteigen.
æ branadic: Bravo, mit direktem Link, damit sogar ich das finde.
Muss ich gleich verbookmarken. Ev. sind ja da die Ladezeiten
kürzer als heute im mikrocontroller.net.
Gruß, Guido
Mann! Da ist (bzw. ißt) man nur kurz beim Griechen und schon geht hier
die Post ab.
@Guido
Super, das hat mich schon die ganze Zeit genervt. Aber irgendwie hatte
ich auch keine Lust danach zu suchen. Sehr cool! Werd das mal gleich
einbauen.
@Stefan
Na das nenne ich eine echte Detailanalyse. Den groben Ablauf hatte ich
mir schon so rausgelesen, zumindest reichte es aus die Funktionen in
meinen Abgleichroutinen einzusetzen. Aber was da im Detail abging hatte
ich noch nicht raus. Allerdings überrascht es mich irgendwie nicht, das
die grundlegenden Hardwareroutinen genauso zusammengeschustert sind wie
der Rest. D.h. wir müssen die ADC-Korrektur vor die Averaging und
Invert-Routine verlegen. Fühlst Du Dich berufen da Hand anzulegen?
@Branadic
Prima, das ist eine gute Idee und ja, ich hab einen User für SFN.
Allerdings gebe ich zu, dass die etwas anstrengende Menüstruktur und
Handhabung mich immer etwas abgeschreckt hat. Aber das ist natürlich ein
Grund sich da nochmal ranzusetzen.
@all
Ich freue mich über die inzwischen so aktive Hilfe und Resonanz. Wie man
sieht beschleunigt das den Prozess doch ungemein.
So werd mich mal schnell noch etwas ins Coding stürzen - Das Forum hab
ich dabei natürlich im Blick...
Hayo
So Jungs,
ich hab noch ein wenig in der Menu-Struktur herumgefuscht. Von der
Firmware-Page aus könnt ihr nun also in die Roadmap, in die History und
in die Wish-List wechseln. Hat alles seine eigene Seite, damit es auch
übersichtlich bleibt.
Ihr dürft euch jetzt an den Seiten verlustieren und erweitern.
Gruß, branadic
Hallo Hayo,
ich wollt' Dich nochmal gerne ärgern:
Gerade habe ich die 0.59 Firmware eingespielt, weil ich mir sicher war,
dass flankengesteuertes Triggern auf allen Kanälen funktionierte - und:
jawoll! In der 0.59 funktionierte die Triggerung besser als in der
Neuen.
Hier hast Du also irgendwas verändert, was nicht gut war.
(Obwohl mir der Abgleich wirklich gut gefällt, Triggerung ist mir fast
noch wichtiger.)
Zusammenfassung:
0.59: flankengesteuertes Triggern auf allen vier Kanälen sowohl steigend
als auch fallend: ok
0.62: Kanal 1 & 4: keine flankengesteuerte Triggerung möglich
Kanal 2: nur steigent; Kanal 3: nur fallend.
Jámas! alter Grieche ;-)
Michel
Hallo Hayo,
Habe gerade eben auch die 0.62 geflasht.
Auf Kanal 1 u. 4 funktioniert bei mir auch keine flankgengesteuerte
Triggerung.
Auf Kanal 2 funktioniert nur die Triggerung auf die fallende und auf
Kanal 3 nur eine Triggerung auf steigende Flanke.
lg Robert (W2024A)
Hm...
dann muß ich nochmal sehen was ich da geändert habe. meines Wissens hab
ich an der Triggerung nichts geändert. Allerdings hab ich ein Register
für Kanal 3 + 4 anders gesetzt. Ich Schau mal - wir wollen ja auch keine
Rückschritte machen.
Hab übrigens die Korrektur von Guido eingespielt, sieht gut aus so ohne
abgeschnittenes Signal.
Bis morgen
Hayo
@Guido,
es werden noch einige Pixel nicht richtig gesetzt.
@Hayo,
Wenn man misst und auf Stop drückt kann man ja in das Signal rein oder
raus zoomen. Dabei wird aber immer eine neu Messung gestart sodass die
alten Werte verloren gehen. Allerdings nur beim Autotrigger.
Normaltrigger und Singe Shot sind OK.
@Stefan
>D.h. wir müssen die ADC-Korrektur vor die Averaging und>Invert-Routine verlegen. Fühlst Du Dich berufen da Hand anzulegen?
Nach dem ich es jetzt geschafft habe, mit dem Makefile von Günter Jung
und gtkTerm, das Programm direkt in den Ram den Oszilloskops zu laden,
mach ich das doch glatt.
Ist echt praktisch, läuft nur ca 3min, auch unter Linux und über einen
RS232-Wandler. Bei mir war es nur zusätzlich noch nötig, gtkTerm auf das
"+" als Bestätigung vom Oszilloskop warten zu lassen und schon ging die
Post ab.
Stefan schrieb:
> Nach dem ich es jetzt geschafft habe, mit dem Makefile von Günter Jung> und gtkTerm, das Programm direkt in den Ram den Oszilloskops zu laden,> mach ich das doch glatt.>> Ist echt praktisch, läuft nur ca 3min, auch unter Linux und über einen> RS232-Wandler. Bei mir war es nur zusätzlich noch nötig, gtkTerm auf das> "+" als Bestätigung vom Oszilloskop warten zu lassen und schon ging die> Post ab.
Ich bin nicht im Bilde! Wie geht das? Kannst Du mal eine detailierte
Beschreibung geben, oder sagen wo es eine gibt? Das hört sich ja so an
als wenn man die Entwicklungszyklen dramatisch verkürzen könnte.
Mach mich schlau!
Hayo
Kurt Bohnen schrieb:
> @Guido,> es werden noch einige Pixel nicht richtig gesetzt.
Ja hab ich schon gesehen, das ist aber anscheinend eine andere
Baustelle, die den Gridlayer betrifft, denn die Signale sind soweit ich
gesehen habe nicht davon betroffen. Ich vermute, das da irgendwo Pixel
im Löschmodus gesetzt werden in der Gridroutine ("set" Parameter auf
Null).
> @Hayo,> Wenn man misst und auf Stop drückt kann man ja in das Signal rein oder> raus zoomen. Dabei wird aber immer eine neu Messung gestart sodass die> alten Werte verloren gehen. Allerdings nur beim Autotrigger.> Normaltrigger und Singe Shot sind OK.
Muß ich mir heute abend mal ansehen.
Gruß Hayo
@Hayo
Funktioniert super! 3min pro Zyklus unter Linux. Allerdings verwende ich
nicht mehr gtkTerm sondern ein eigenes Perl-Skript zum Upload.
Günter hat weiter oben ein neues Makefile gepostet
(http://www.mikrocontroller.net/attachment/50963/Makefile.zip)
Das erzeugt eine TomCat.ram, die genau wie die ursprüngliche .flash
aufgebaut ist, nur fehlen darin die Befehle, den Flash zu löschen und in
den Flash zu schreiben. (So sehe ich das) Deshalb wird der Code direkt
in den Ram geschrieben und mit dem letzten Befehl gestartet.
Ich habe mein provisorischen Perl-Skript angehängt. Bitte nicht schlagen
für die Form. Ist nur zum testen, funktioniert aber schon einwandfrei.
Bei Bedarf gibts auch eine schönere Form. Habe dafür aber jetzt keine
Zeit
Damit das läuft musst du natürlich noch deine Schnittstelle im
Perl-Skript auswählen und das Skript in den Build-Ordner legen.
Wenn Perl das Modul nicht findet musst du das hier installieren:
http://search.cpan.org/CPAN/authors/id/C/CO/COOK/Device-SerialPort-1.04.tar.gz
mit (als root)
perl Makefile.pl
make
make Install
Heute Abend habe ich wieder mehr Zeit.
Gruß,
Stefan
@Robert + Michel
Ok Jungs Ihr hattet Recht. Ich hab tatsächlich was am Trigger geändert
in der 0.60 die ja nicht als beta rausgegangen ist. Das läßt sich
schnell wieder fixen. Allerding ist das genau die Stelle an der noch
optimiert werden muß um den Trigger besser zu machen. Ich werde das
erstmal wieder auf den alten Stand bringen und dann weiter sehen.
Danke!
Hayo
Kleine Ergänzung:
Das Perl-Skript erkennt eine fehlerhafte Übertraung und bricht dann ab.
Da das bisher noch nie passiert ist, ist auch keine automatische
Korrektur nötig. Nach dem letzten Befehl wartet das Skript auf eine
Rückmeldung kommt natürlich nicht mehr, da der Oskar schon läuft. Also
einfach abbrechen.
Stefan
Ok danke,
bin schon echt neugierig und kann es kaum erwarten nach hause zu kommen.
Hab mir mal Günters Beitrag vom 16.5. rausgesucht. Der ist irgendwie an
mir vorbeigegangen, dabei ist das ja eine wirklich interessante Sache.
Gut dass wir nochmal drüber geredet haben...
Gruß Hayo
@sunny
Keine Ahnung, ob das schon geht. Getestet hab ich es nicht. Kommentare
erkennt es jedenfalls nicht, die in der .flash drinnenstehen. Da müsste
man noch anpacken. Viel ändern muss man wahrscheinlich nicht mehr.
Stefan
Hallo,
Kurt Bohnen schrieb:
> @Guido,> es werden noch einige Pixel nicht richtig gesetzt.
super, ich dachte schon in hätte ein Hardwareproblem. :-)
Sehe ich aber nur mit Lupe. Die vertikalen Gridlinien
sind bei mir auch nicht ganz durchgezogen, da werde ich mal
suchen. Die fehlenden Pixel sind bei mir im letzten Drittel
des Schirms wieder da, wird nicht so leicht zu finden sein.
@ Stefan: hast recht, das Ramloaden ist schon super, vor
allem aus dem gtkTerm heraus.
Gruß, Guido
@Stefan
> RS232-Wandler. Bei mir war es nur zusätzlich noch nötig, gtkTerm auf das> "+" als Bestätigung vom Oszilloskop warten zu lassen und schon ging die
Hatte ich vergessen zu sagen, zusätzlich sollte man noch die CRLF
Anpassung einschalten
> Funktioniert super! 3min pro Zyklus unter Linux. Allerdings verwende ich> nicht mehr gtkTerm sondern ein eigenes Perl-Skript zum Upload.
gtkterm hat den Vorteil, daß man danach auch gleich im Terminal für
die serielle Schnittstelle ist.
@sunny
> dein script rennt ja durch wie schmitt's katze. super! lässt sich damit> auch die .flash datei übertragen?
das wird nicht zuverlässig funktionieren, da der GERM nach jeder
empfangenen Zeile ein '+' schickt, unabhängig davon ob der Teil zum
verarbeiten der Zeile fertig ist oder nicht. D.h. wenn der gerade mit
dem Schreiben eines Flash-Blocks beschäftigt ist, wird der Eingangs-FIFO
überschrieben, und dann hängt das ganze.
Ich denke man müsste nach jeweils 64k eine Pause von ein paar Sekunden
einlegen damit das ganze zuverlässig geht.
Ich wollte mich mal drüber machen das 'nr' Kommando aus dem SDK
(ist bei Linux nicht mit dabei) mit genau diesen Funtionen neu zu
schreiben, leider bin ich im Moment beruflich etwas im Stress so daß
ich nicht allzu viel machen kann.
Gruß,
Günter
Hallo Kurt,
>also bei mir habe auch die Signale fehlende Pixel auf beiden Kanälen.>Siehe Screenshot.
hast recht, ist bei mir auch so, sieht man nur mit einem
Rechteck. In der linken Hälfte fehlen die Pixel wohl in
jeder 2. Spalte, imd der rechten sehe ich sowas nicht.
Wird wirklich blöd zu suchen sein.
Gruß, Guido
@stefan
genau so schnell wie mit der .ram
@günter
ich hab es 4x durchlaufen lassen und keine probleme festgestellt. ich
glaub auch das + wird erst gesendt wenn der letzte vorgang abgeshlossen
ist. das sieht man gut am anfang wenn die speicherblöcke gelöscht
werden. da dauert es immer einen kurzen moment bist die bestätigung
kommt.
Hallo Hayo,
Ich habe gerade die Experimental Firmware (0.62) mit der umskalierten
Anzeige geladen.
Auf Kanal habe ich jedoch in den neuen Skalierungen (4V, 2V, 400mV,
200mV, 40mV, 20mV) extreme Ausreißer (siehe Screenshot). Wenn ich auf zB
500mV umschalte sind sie weg. Nach einer Zeit legen sich diese
Ausreißer.
@sunny
ich hatte genau die gegenteilige Erfahrung,
ist immer nach ca der Hälfte (ca 300k) stehen geblieben.
Bis dahin lief es immer genau so schnell wie ins RAM,
was mich zu der Vermutung bringt, das eben nicht bis zum
Ende des Schreibvorgangs gewartet wird bevor das '+' kommt.
Gruß,
Günter
Welches GTKTerm benutzt Ihr?
Das französische oder das deutsche? Von der Beschreibung her würde ich
ja auf das französische tippen in der Version 0.99.5, ist das korrekt?
Hayo
dann ist das vll. systemabhängig. ich missbrauche meinen satreciver für
die linux geschichten. das ist ja ein relativ langsames system.
möglicherweise bleibt dadurch genügend zeit für den schreibvorgang.
also sollte man vll. doch eine verzögerung einbauen. da ich bis gerade
ebend noch nie was mit perl gemacht habe, wüsste ich allerdings nicht
wie.
das letzte Mal das ich was in Perl gemacht habe ist leider 10 Jahre her.
Aber sowas wie ein 'usleep' gibt es sicher auch in Perl.
Gerade nachgeschaut, ist im Time::HiRes Modul: usleep ($microseconds);
Gruß,
Günter
so wie es aussieht gibt es wirklich zwei:
GTKTerm -> sowas wie xterm
gtkterm -> serielles Terminal
die unterscheiden sich nur in der Gros-/Kleinschreibung,
das war mir so auch nicht klar.
Gruß,
Günter
So,
habe jetzt dreimal hintereinander eine .flash Datei mit
GtkTerm übertragen. Hat dreimal geklappt, die 0.62
dauert etwa 3,5 Minuten, ältere Versionen gehen etwas
schneller.
Möglicherweise bremst das Terminalprogramm ausreichend
(mal weitere Tests anwarten). Ich hatte beim
WelecUpdater unter Linux den Eindruck, dass er etwa 3 bis
4 mal länger braucht als unter Windows (beim Download)
und dass die Gtk-Ausgabe hierfür veranzwortlich war.
Guido
Also bei mir geht es mit gtkterm nicht zuverlässig. Da überträgt er zwar
und startet. Danach hängt sich die Software aber so gut wie immer auf.
Deshalb das extra Skript, dass überprüft ob die Zeile wieder richtig
zurück kommt.
Stefan
Es liegt dann offensichtlich an der Geschwindigkeit des jeweiligen
Rechners.
D.h. zuverlässig wird es nur mit zusätzlichen Wartezeiten wie im perl
Skript gehen.
also normale RS232 oder USB-Adapter mach keinen Unterschied.
Hab' ich beides schon probiert.
Der unterschied zwischen einem einfachen USB-Adapter und einer
echten RS232 liegt hauptsächlich in der Ansteuerbarkeit der
Handshake-Leitungen.
Der GERMS benutzt aber keinerlei Handshake, weder Hardware RTS/CTS
noch Software XON/XOFF.
Gruß,
Günter
So,
nochmal für alle, die mit gtkterm Probleme haben, oder die lieber per
Skript den Code laden wollen, eine verbesserte Version.
Alle 2000 Zeilen wird 1 Sekunde gewartet.
Gestartet wird über eine Kommandozeile mit den Parametern (die natürlich
an die eigenen Bedürfnisse angepasst werden müssen.)
perl flashloader.pl /dev/ttyUSB0 TomCat.ram
Also gtkterm krieg ich überhaupt nicht zum Laufen. Bei .configure meldet
er etwas von missing TERMINAL_WIDGET.
Dann hab ich das mal mit Deinem ersten Script ausprobiert - wollte auch
nicht so richtig. Nach etwas rumgezackere hab ich dann dieses paket
installiert gekriegt mit irgendwelche Zusatzroutinen. Dann hab ich mal
Dein letztes Script ausprobiert - mit /dev/ttyS0 (hab einen echten RS232
Port) - und es läuft und zwar blitzschnell. Super, muß mir nur noch was
überlegen damit ich nicht immer die ganze Kommandozeile eingeben muß.
Hast Du echt prima hingekriegt, und das man ins RAM laden kann ist auch
echt klasse, danke nochmal an dieser Stelle an Günter.
Muß erstmal wieder los, bis nachher
Gruß Hayo
Hi,
also ich hab' das jetzt mal auch mit dem Laptop getestet.
Ich eindeutig ein Geschwindigkeits Thema.
Auf dem Laptop geht der Flashupdate sowohl mit echter RS232 als auch
mit USB-Adapter problemlos mit gtkterm, auf dem Arbeitsplatzrechner geht
nur das Perl-Skript zuverlässig.
Beim Laden ins RAM gibts kein Problem mit der Geschwindigkeit.
Gruß,
Günter
So,
ich hab gerade mal fix die flashloader.pl etwas aufgeräumt und mit einer
Timeout-Behandlung versehen, weil das Ding sonst bis zum
St.Nimmerleinstag wartet, wenn das DSO nicht reagiert.
/Hannes
EDIT: muss übrigens dem Autor des Scripts meinen tief empfundenen Dank
aussprechen, das macht das Testen^WRumspielen wirklich viel einfacher.
Hab grade nur mal so zum Spaß das Backup der Original-FW wieder
eingespielt, welches zum Sichern damals ca. 4,5h benötigt hat. Dauer des
Restore: ca. 7 Minuten. Ich LIEBE es. :D
Hallo Johannes,
könntest du vielleicht so gut sein und auf Sourceforge im Trac/Wiki
einen entsprechenden Beitrag zum exakten Vorgehen unter Windows/Linux
setzen, damit auch unsere internationalen Freunde etwas davon haben?
Wäre wirklich super und für die nächste Entwicklungszeit in einer
Übersicht festgehalten.
Besten Dank, branadic
Mal eine Frage als Perl-Unwissender. Kann man das Perlscript auch unter
Windows verwenden? Denn für Windows gibt es Perl doch auch. Muß man
evtl. noch was installieren?
Ich wollte das Script und eine Anleitung der nächsten Beta beilegen,
genauso wie der TomCat.ram für Leute die streßfrei einfach nur mal
testen wollen. Dafür wäre es natürlich nicht schlecht wenn man auch
Windows-User mit einbeziehen könnte.
Gruß Hayo
Klar, wenn du mir nochmal den Link gibst.
Mir wäre es zugegebenermassen allerdings lieber, wenn ich das Perlscript
mal versuchshalber für Windows und Linux tauglich mache (bisher geht es
nur unter Linux), das alles hierher schreibe und du das dann in SF
einstellst. Dort müsste ich mich erst anmelden... und überhaupt. :D
/Hannes
@Kurt + Guido
Die Pixelfehler kann man besonders gut sehen wenn man einen Kanal auf
Ground-Coupling schaltet und mit der Nullinie langsam durch den
kritischen Bereich fährt. Das sieht schon recht merkwürdig aus...
Hayo
Hallo Hannes,
so aufgeräumt sieht das Skript gleich nochmal besser aus ;-)
Da merkt man doch gleich, wenn jemand schon öfter Perl verwendet hat.
Hallo Hayo,
ich habe testweise mal die Assembler-Routine umgebaut und der Fehler
beim Invertieren ist weg. Probiere da noch ein wenig dran rum, um das im
Ganzen halbwegs zu verstehen.
Gruß,
Stefan
@ Stefan: Das klingt ja super!
@ All: Mir ist beim Debuggen aufgefallen, dass momentan nach fast
jeder Einstellungsänderung das Config-Flash überschrieben wird.
Muss man sich da Sorgen machen? Ich habe für meine Tests den
Funktionsaufruf in Tomcat auskommentiert.
Gruß, Guido
@Guido
Im Datenblatt, dass im Wiki mit dem Flash verlinkt ist, steht was von
"Minimum 1 million erase cycle guarantee per sector".
Hast also noch ein paar Versuche
Also heute geht es ja richtig ab hier oder? Fortschritte an allen Ecken
und Enden, so macht das echt Spaß!
Da kann ich auch gleich noch einen nachschieben - Trigger geht wieder.
Dann werde ich mal auf Guido und Stefan warten und dann eine schöne
runde 0.63 beta zum langen Wochenende rausschieben bevor ich mit dem
Rollmode/Shiftmode anfange.
Hayo
Hallo,
der Streifen bleibt. :-( Ich dachte dir Ursache wäre dieselbe wie
mit dem Pixelfheler. Der resulierte daher, dass die Menü-Plane
über das Grid kopiert wurde (UI_Plane2). Abhhilfe:
Am Anfang von TransferPlanes ändern:
Und in TransferDataPlane_asm_persistant die Loop-Variable von
1460 auf 1000 reduzieren.
Der Upload ins Ram hat aber nicht geklappt, da das Oszi immer
eine Microsofz-Behandlung gewünscht hat. :-(
Falls es sich jemand anschauen möchte, Anhang.
@ Stefan: Dann muss ich mir wohl doch keine Gedanken machen, ich war
von einem Hundertstel ausgegangen.
Gruß, Guido
So Hayo,
hier die abgeänderte Datei. Geändert hat sich nur etwas in der
READADC_ALL.
Zweimal hatte ich den fall, dass sich ein Kanal beim Verschieben vom
Nullpunkt vom Nullpunktpfeil proportional verschoben hat. Ein erneutes
ADC und DAC-Kalibrieren hat das dann behoben. Denke, dass muss woanderst
liegen. Das Rauschen nimmt jedenfalls jetzt nicht mehr zu beim
Invertieren.
Alles klar Ihr Beiden. Vielen Dank für die schnelle Lösung. Ich werde
das dann mal einfließen lassen.
Zum Flash - da gibt es keinen Grund zur Sorge, bis da das Ende der
Schreibzyklen erreicht ist sind die Leuchtkathoden vom Bildschirm schon
in den ewigen Jagdgründen und es gibt nur noch einen Blackscreen. Das
Wegspeichern ist deshalb so häufig nötig, damit das Oszi beim nächsten
Start wieder mit den alten Einstellungen starten kann.
Gruß Hayo
och eine Erfolgsmeldung - es reißt nicht ab - ich hab den Fehler mit
dem Triggercursor am oberen Gridrand beseitigt. Da blieb ja beim Drücken
des Default Setup immer eine Leiche irgendwo links oder rechts neben der
neuen Position zurück. Ist erledigt - nicht zuletzt dank der jetzt so
kurzen Upload Zeiten ins RAM.
Hayo
Ach ja zu guter Letzt - kaum noch auszuhalten - der Fehler 139 beim
Erzeugen des Objektdumps ist auch Geschichte.
So jetzt ist aber gut.
Bis morgen also
Hayo
Hab jetzt das Perlscriptchen (hoffentlich) OS-unabhängig gemacht. Bei
mir unter Linux geht es noch, jetzt müsste nur mal einer unter Windows
testen, ob es auch mit ActivePerl und dem Module Win32::SerialPort
klappt.
Zum Benutzen muss man wie gesagt je nach Betriebssystem das Modul
Win32|Device::Serialport installieren. Das geht unter Linux am
einfachsten mit dem distributionseigenen Paketmanager (das Paket heisst
üblicherweise in der Art wie perl-Device-Serialport oder etwas in der
Preislage), und wenn man es da nicht findet, dann in einem Terminal via
CPAN (Archiv von Perlmodulen):
1
su -
2
perl -MCPAN -e 'install Device::SerialPort'
Alle darauf folgenden Fragen immer nur mit Enter bestätigen, dann
sollten benötigte Module gleich mit installiert werden.
Wie man das unter Windows macht, ist mir gerade nicht klar, da gibt's
aber IIRC auch so ein Archiv bei Activestate.
Wenn das dann geklärt ist, kann man im Terminal folgendes ausführen
(vorausgesetzt, das Script befindet sich in einem Verzeichnis zusammen
mit der Tomcat-Datei und man befindet sich auch in diesem Verzeichnis
;-):
1
perl flashloader.pl /dev/ttyUSB0 TomCat.flash
Portbezeichnung und Dateiname sind natürlich entsprechend anzupassen.
/Hannes
Moin Leute,
nachdem ich mir gestern beim ersten Versuch des Flashens gleich mal
alles geschossen habe, habe ich am Skript noch ein bisschen
rumgefummelt. Es sendet nun nicht erfolgreich übertragene Zeilen
nochmals zu senden. Da meine serielle Schnittstelle etwas flaky ist und
gern mal alle zigtausend Zeichen eines verschluckt, war das auch absolut
notwendig, um das Gerät wieder zum Laufen zu bekommen ;)
Da ich aber mit der Version weitergebastelt hab, die ich gestern
Nachmittag irgendwann geladen habe, sind natürlich die neuesten
Änderungen noch nicht drin, aber ich schätze, einer der Perl-Profis wird
sich dem noch annehmen. Wichtig: Das Skript enthält KEINE sleeps mehr.
Die sollten aber nicht nötig sein, da im Fehlerfalle ja erneut gesendet
wird.
Ansonsten nochmal mein Aufruf: So viel wie hier aktuell los ist, würde
ich es sehr begrüßen, wenn auch der Hayo-Branch der Firmware sowie die
tollen Tools die hier entstehen, versioniert werden würden. Ihr seid
alle herzlich eingeladen, die vorhandenen Ressourcen des welecw2000a
Projekts bei Sourceforge zu nutzen ;) Dann gäbe es (endlich) eine
zentrale Anlaufstelle für alle Neulinge (und alten Hasen) und vorallem
einen Platz für dauerhafte Dokumentation!
Viele Grüße
Daniel
Crazor schrieb:
> Da ich aber mit der Version weitergebastelt hab, die ich gestern> Nachmittag irgendwann geladen habe, sind natürlich die neuesten> Änderungen noch nicht drin, aber ich schätze, einer der Perl-Profis wird> sich dem noch annehmen.
Ok, das werd ich dann mal mergen...
/Hannes
Kurt Bohnen schrieb:
> Das wird aber auch unter Windows laufen und zusammen mit einer passenden> tomcat.ram ausgeliefert? ;-)
Das ist das Ziel. Je praktikabler das Ganze wird, desto mehr werden es
ausprobieren und sich anstecken lassen...
Hayo
Hallo Hayo,
habe noch den hässlichen Balken beseitigt. Dazu muss in
tc_vars.h BOT_PLANE_MIN von 8480 auf 8600 vergrößert
werden. Das wird afaik eh nur benutzt um eine Init aus
dem Flash zu laden.
Gruß, Guido
Aufgemerkt!
Es gibt die 0.63 beta. So viele Fixes habe ich noch in keinem Release
auf einmal gemacht. Nicht übel.
Das komplette Build gibt es ebenso wie die Firmware bei Google Groups
http://groups.google.com/group/welec-dso/files
Ich habe das beigelegte Perlskript nochmal umbenannt und noch zwei
Shellskripte für den Flash und den RAM-Upload dazugetan. Es gibt auch
eine neue How to.
@Guido
Deine letzte Änderung hab ich noch nicht eingebaut, da ich nicht mehr
dazu gekommen bin mir das anzusehen.
Gruß Hayo
Hab jetzt diesen Schreibwiederholversuch da eingepflegt und es unter
Linux getestet, das klappt einwandfrei. Will mal sehen, ob ich jetzt fix
noch ein Activeperl mit Win32::SerialPort in die VM geballert bekomme
und es dort noch schnell testen kann. Oder fühlt sich ein
Windowsbenutzer berufen, das mal fix auszuprobieren?
/Hannes
@Kurt: welche Variante des Scripts hast du versucht? Die aus dem
FW-Archiv?
Das Problem mit dem Schreiben von nur einer Zeile pro Sekunbde hatte ich
auch schon, das lag am falschen Zeilenende. Muss ich also offenbar für
Windows anpassen. Fixe ich schnell, keine Angst, ich bin nur grade noch
am Windows-Perl-Installieren ;)
Hallo Hayo,
einfach Klasse! Das Triggern geht wieder auf Ch1 am 2012a funktioniert
wieder auf positive und negative Flanke auf dem Probe-Ausgang!
Gruß Jürgen
Hallo,
>@Guido>Deine letzte Änderung hab ich noch nicht eingebaut, da ich nicht mehr>dazu gekommen bin mir das anzusehen.
Falls es sich trotzdem jemand ansehehn möchte: auf Basis 0.63.
Hoffentlich klappt es bald auch für die Windowsuser mit dem
Ramupload.
Habe gearde gesehen, dass die Änderungen das Quickmeasure stören,
da muss ich wohl noch nachlegen. Als Nächstes schau ich mir aber
erst mal die Softbuttons an, die sollten einheitlich aussehen.
Gruß, Guido
Hi, ich sehe es regt sich noch was.
Bin schon an der 0.64 zugange und baue gerade den Ultra Slow Timebase
Modus ein (Shift und Roll). Mal sehen wann ich einen ersten Prototyp zur
Verfügung stellen kann.
@Jürgen
Jupp. So soll es sein.
Hayo
Kurt Bohnen schrieb:
> Geht immer noch nicht schneller.
Dann bin ich erstmal ratlos. Muss mir mal nen Rechner mit
Hardware-Serial und Windows besorgen, dann schau ich dort mal.
Wie viele Punkte (oder gar X) siehst du vor dem OK am Ende der Zeile?
/Hannes
Ist es normal, dass sich beide Signale exakt in der Schirm Mitte
befinden müssen damit die Mathefunktionen korrekt arbeiten?
Das Problem gibt es in der 0.62 und der 0.63.
Seit ich den Zero-Shift wieder eingebaut habe (DAC-Offsetverschiebung)
ist die Mathfunktion davon betroffen. Hier muß ich noch den neuen
variablen Zerolevel einbauen. da ich aber gerade in höheren
Programmiersphären schwebe (Shift und Rollmode) muß das erstmal warten
;-)
Hayo
@ Hannes Ich hatte das selbe problem wie Kurt unter Windows.
Um den download zu beschleunigen habe ich folgende zeilen geaendert:
53 $serial->read_const_time(1);
83 if ($readcount++ > 1000) {
es scheint das unter windows (ich verwende ActivePerl 5.8.8) immer
read_const_time(x) gewartet wird auch wenn genuegend zeichen empfangen
wurden!
Gemessen Zeiten download der version 0.64 mit echter UART:
download ins RAM: 2 min. 40 sek.
download ins FLASH: 2 min. 45 sek.
Martin
beim testen der .63 ist mir ein etwas im delayed modus aufgefallen.
gerät: w2024
signal: 1mhz rechteck 10vpp an ch1
main timebase: 100ns/div
bei einer delaed timebase von 50ns ist der auswahlbereich um ca 1div
nach rechts verschoben im vergleich zu dem was im delayed fenster
angezeigt wird.
ab einer delayed timebase von 20ns wird im delayed fenster ein völlig
anderer bereich des signales dargestellt.
hat man die signalaufzeichnung gestoppt und ändert den delayed
auswahlbereich, wird das aktuell angezeigte signal gelöscht und eine
erneute aufzeichnung gestartet. es ist also nicht möglich, den
zoombereich auf ein einmaliges event zu vergrößern oder zu verkleinern.
Martin H. schrieb:
> es scheint das unter windows (ich verwende ActivePerl 5.8.8) immer> read_const_time(x) gewartet wird auch wenn genuegend zeichen empfangen> wurden!
Nö, dann wäre es bei mir nicht gegangen. Aber der Hinweis ist gut,
danke.
/Hannes
Moin Moin!
Ich weiß net, ob's hier erlaubt ist.
Aber ich würde mein Oszi gerne Verkaufen,
ist ein W2022A mit 200 MHz / 2 Kanal.
Daher erstmal die vorsichtige Anfrage, ob das hier möglich ist.
Johannes Studt schrieb:
> Martin H. schrieb:>> es scheint das unter windows (ich verwende ActivePerl 5.8.8) immer>> read_const_time(x) gewartet wird auch wenn genuegend zeichen empfangen>> wurden!>> Nö, dann wäre es bei mir nicht gegangen. Aber der Hinweis ist gut,> danke.
Hab da jetzt nochmal bissl rumgegraben. Das Windows-Modul arbeitet auf
jeden Fall irgendwie anders als der Linux-Nachbau, es werden
(zumindestens hier) nicht bei jedem Leseaufruf die "geforderte" Anzahl
Bytes zurückgeliefert. Unter Linux steht bei mir vor dem OK immer genau
ein Punkt (ergo genau ein Leseversuch), unter Windows sind es
unterschiedlich viele, meist jedoch 2-3.
Der ganze Unsinn, den ich da mit Linebreaks verzapft hatte, war völlig
unnötig. Hab's jetzt so ungefähr wie Martin gemacht, und das führt auf
meinem System zu folgenden Zeiten für das Flashen der 0.63:
Linux nativ: 3m15s
WinXP in VM: 5m01s
Dauert zwar unter Windows immer noch deutlich länger, aber
verschmerzbar, denke ich. Die Zeit wird hier bei mir übrigens auch davon
beeinflusst, ob ich das cmd-Fenster sichtbar oder minimiert habe. Die
Ausgabe der Zeilen scheint ein durchaus erheblicher Faktor zu sein, und
offenbar ist da irgendetwas[TM] schlau genug, bei minimiertem Fenster
die Ausgabe einfach zu unterdrücken.
/Hannes
@ Hayo: Also gut, du hast es so gewollt. Bin ich eigentlich der
Einzige, bei dem bei Invertierung der Signale auch die ADC und
DAC Kalibrierwerte invertiert werden müssten? Stelle ich mir
etwas knifflig vor.
Gruß, Guido
@Guido
Das hab ich mir noch nicht so im Detail angesehen. Bist Du sicher, dass
die Werte invertiert werden müssen? Das wäre dann ja Stefans Baustelle
oder?
Hayo
Guido schrieb:
> @ Hayo: Also gut, du hast es so gewollt. Bin ich eigentlich der> Einzige, bei dem bei Invertierung der Signale auch die ADC und> DAC Kalibrierwerte invertiert werden müssten? Stelle ich mir> etwas knifflig vor.>> Gruß, Guido
Hallo,
kannst du das etwas genauer erklären? Meinst du vielleicht die leichte
Verschiebung des Signals um den Nullpunkt, wenn der Eingang
kurzgeschlossen ist?
Die Invertierung läuft folgendermaßen ab:
- Abzug des (AD-spezifischen) DAC-Korrekturwertes vom Eingangswert
- Berechnung der Differenz zum ZeroLevel
- Fallweise Addition oder Subtraktion der Differenz zum Zerolevel
(jenachdem ob davor drunter oder drüber)
Vielleicht stimmt der Offsetabgleich noch nicht ganz, Vielleicht kann
Hayo testweise eine zusätzlichen iterativen Abgleich einführen, der den
Offset solange verändert, bis das normale und invertierte Signal die
"gleichen" Werte haben.
Ich kann erst wieder ab Montag oder Dienstag testen. Deshalb kann ich es
nicht selber ausprobieren.
Gibt es eigentlich die Möglichkeit eine Zeitmessung über einen der Timer
einzubauen? Mich würde interessieren, welche Routine welche Zeit
braucht. Evtl. lässt sich die Geschwindigkeit an der Stelle dann ja
erhöhen. z.B müssen ja nicht immer alle 4000 Werte umkopiert werden,
wenn das Gerät läuft. Erst wenn auf Stop gedrückt ist, werden z.B alle
Daten aufbereitet.
Gruß,
Stefan
@ Hannes:
Habe deine abgeanderters script ausprobiert bei mir benötigt es ca. 5
min. 20 sek. und ich sehe immer zwei Punkte vor dem OK (bei meiner
Version waren es drei!) Um das besser zu verstehen habe ich mir die DOC
von Win32::SerialPort angesehen, di inizialisiert immer auch zwei
weitere Parameter (read_interval(x) und read_char_time(x)). Ich habe
diese versuchsweise in deinem Script ergaenzt, und siehe da: nur noch
ein Punkt vor dem OK!
Des weiteren ist es so möglich zu deine original Werten zurueck zu
gehen.
(read_const_time(1000) und 10 versuche).
Download ins RAM der 0.63 in ca. 2 min. 5 sec.
Download ins Flash der 0.63 in ca. 2 min. 12 sec.
Im Anhang meine Version (nur unter Windows getestet)
Martin
Martin H. schrieb:
> Im Anhang meine Version (nur unter Windows getestet)
Super Sache. Ich werde das dann später mal unter Linux testen, hab heute
leider keinen Brückentag.
/Hannes
Noch ein Nachtrag:
Der GERMSloader.pl braucht bei mir für TomCat.ram (0.63) 2:48, also
unter 3 Minuten. Das ganze unter Debian Linux mit USB-RS232
Konverter....
Dabei kommen 3-4 mal mehr als ein Punkt vor dem OK (bis zu 4)...
Hallo Hayo und Stefan,
ein Bild sagt mehr ... Der ADC- und DAC-Abgleich funktionieren
bei mir sehr gut. Invertiere ich das Signal (Kanal 2) wird es
unschön. Wenn ich damit neu kalibriere, sieht Kanal 2 so gut
aus wie Kanal 1. Dann die Invertierung wieder aus, sieht wieder
aus wie im Bild.
Ich vermute, dass da die Abgleichwerte invertiert werden müssen,
was eigentlich in der UI-Funktion erfolgen sollte.
Bin ich wirklich der Einzige, bei dem das so stark ist?
Gruß, Guido
Guido schrieb:
> Bin ich wirklich der Einzige, bei dem das so stark ist?
Definitiv ja! Bei mir ist das Signal immer gleich egal ob invertiert
oder nicht. Stefan hat hier also ganze Arbeit geleistet.
Aber deine Teilung der Bottom Plane sieht interessant aus.
Hayo
@Hannes + Martin
Ich möchte zusätzlich zu Linux auch unter Win XP Firmware laden. Was
brauche ich außer dem neuen Perlskript noch zusätzlich?
(irgendeine favourisierte Perlversion, Module?)
Hayo
>Aber deine Teilung der Bottom Plane sieht interessant aus.
Hmmh, ist die unveränderte FW 0.63. Ich sage ja, dass ich damit
irgendwie noch nicht zufrieden bin. ;-)
Muss mir später mal die Abgleichwerte der ADC anschauen.
Gruß, Guido
@ hayo
Ich verwende ActivePerl 5.8.8 (habe ich von
http://www.oldapps.com/Perl.php geladen).
Zusaetzlich benoetigst du das Modul Win32:SerialPort
Am einfachsten ist die Installierung via Perl Package Manager (PPM):
1. Neues Repository eintragen via Edit -> Preferences
und den Reiter Repositories
Name: Bribes
Location: http://www.bribes.org/perl/ppm
(ein ausfuerliches help findest du unter
http://www.bribes.org/perl/ppmdir.html)
2. Jezt kannst du das Modul Win32-SerialPort installieren:
Zeile mit Win32-SerialPort suchen und an klicken
Action -> Install Win32-Serialport 0.19
Das sollte alles sein.
Martin
Hallo Guido,
dein Phänomen ist mir neu. Und ich kann es mir auch noch nicht erklären.
Hast du probiert, nochmal alle Einstellungen zurückzu setzen und den
kompletten Abgleich neu gemacht? Poste mal die DAC-Korrekturwerte für
beide Kanäle und ohne Invertierung und mit Invertierung. Was passiert
bei Averaging? Und warum schaut deine Bottom-Plane so komisch aus?
Gruß,
Stefan
Hallo Stefan,
die ADC-Korrekturwerte: Kan1, 3110; Kan2. 3140;
DAC-Korrekturwerte: Kan1.77/94/70; Kan2. 15/96/76.
Die bleiben bei Invertierung gleich. Averaging summiert die
Störungen auf, sonst ändert sich nichts.
Was habt ihr nur mit meiner Bottom-Plane? Ich hab da nichts
geändert (noch!!!). Wie sieht die denn bei euch aus?
Gruß, Guido
Hallo branadic,
besten Dank, jo, ist bei mir anders.
@ Hayo: Gute Idee! Die 1.3 von welec hat nichts geändert, probier
jetzt mal mein Backup, sonst muss ich mal den alten Thread
durchwühlen. Btw.: Das Flashen über USB ist schnarchlangsam ;-).
Gruß, Guido
Hallo,
habe jetzt die Alpha 1.4 geflasht und damit eine saubere
Bottom-Plane. Anschließend die Beta 0.63 geflasht und jetzt
klappt es. Kann ich mir zwar nicht erklären aber man muss ja
nicht alles verstehen.
Danke Hayo für den Tip, sorry Stefan, ich hoffe ich habe dir
nicht allzuviel Arbeit gemacht.
Gruß, Guido
Hallo zusammen,
fühlt sich einer der Perl-Terroristen im Stande die Vorgehensweise zum
Flashen des Gerätes unter Windows noch mal genau aufzuführen?
Also was muss installiert werden, wie geht man vor.
Ich habe dafür einen extra Bereich im Trac unter Firmware eingerichtet:
http://apps.sourceforge.net/trac/welecw2000a/wiki/FWupload
Ich würde das gern wieder für alle festhalten wollen.
Beste Grüße, branadic
Guido schrieb:
> Die bleiben bei Invertierung gleich. Averaging summiert die> Störungen auf, sonst ändert sich nichts.
Meinst du damit, dass sie gleich bleiben, auch wenn du im invertierten
Zustand den Abgleich neu ausführst? Wenn nicht, dann mach das mal bitte.
Also erst normal die Werte, dann invertieren, wieder abgleichen und
nochmal die Werte notieren.
Ich könnte mich täuschen, aber deine DAC-Werte erscheinen ungewöhnlich
hoch zu sein.
Gruß,
Stefan
Can't locate object method "read_interval" via package
2
> "Device::SerialPort" at ../GERMSloader-win.pl line 51.
Hab diese beiden Parameter jetzt OS-abhängig gemacht. So geht es hier
unter Linux und in der XP-VM auch einwandfrei. Vielleicht ist das ja
jetzt ein Stand, der möglichst vielen Hardwarevarianten gerecht wird. :D
Linux: 3:14
Win-VM: 3:42
/Hannes
Hallo,
nochmal ausdrücklich: Sorry Stefan!
Wäre der Fehler mit der Bottom-Plane nicht gewesen, hätte ich
ewig suchen können.
Damit tauchen aber neue Probleme auf: Ich weiß jetzt, warum ihr
den Balken (der jetzt ja keiner mehr ist) besser findet. Die
Menü-Routinen sind völlig buggy und dieses wird durch einen
Flashload einfach überbraten. Resultat (irgendwer hatte es schon
gemeldet, ich sehe es erst jetzt) ist, dass für Cursor oder
QuickMeasure die Messwerte nicht mehr angezeigt werden. Das habe
ich schnell per Fallunterscheidung gelöst, jetzt habe ich die
Pixelfehler wieder. Da muss mal grundsätzlich aufgeräumt werden,
ich kümmere mich darum.
Gruß, Guido
@Guido
Alles klar, super dass Du Dich drum kümmerst.
@Hannes
Klasse mit dem Perl Skript. Bin noch nicht zum Testen gekommen da wir
dieses Wochenende Besuch haben, aber die neueste Version wird mit
aktualisierter How to in der nächsten Beta dabei sein.
Ansonsten auch noch Dank an alle die wie Branadic zur Dokumentation
beitragen, denn das Thema wird langsam so vielschichtig dass man leicht
den Überblick verliert, insbesondere als Neuankömmling.
Zur aktuellen Entwicklung:
Bin immer noch am Rollmode zugange, ist schon ganz nett anzusehen, aber
das Timing ist etwas widerborstig. Vorabdemo gibt es in Kürze. Das
Konzept und die aufgetretenen Probleme werde ich dann dem Wiki zuführen.
Guats Nächtle
Hayo
Hi, Ihr Perlen,
Ich bekomme den Germsloader einfach nicht zum laufen - jedesmal die
Meldung, dass das DSO nicht antwortet... :-(
Sowohl realer Port am PC als auch Konverter am Laptop bringt nichts.
Für einen Tipp wäre ich dankbar.
(Bei den Porttests bekomme ich auch nur ein durchwachsenens Protokoll -
ärgerlich...)
Michel
Hallo Michel,
ich habe bisher zwar nur mit dem WelecUploader geflasht, aber bei mir
hat es bisher auch maximal 25min gedauert, bis das neue FlashFile im
Gerät war.
Zum Germsmonitor: Es ist notwendig die beiden Softbuttons einen Moment
lang gedrückt zu halten (so etwa 2-3sec. mach ich das immer, um sicher
zu gehen, dass die Übertragung richtig initialisiert wird), nachdem man
den WelecUpdater zum Upload bewegt hat. Einfach nur kurzes Drücken wird
dich nicht zum Erfolg bringen.
Wie das bei der neuen Uploadmoglichkeit ist kann ich dir nicht sagen.
Gruß, branadic
Bei mir klappt der Start des Germsmonitor ganz gut, wenn man beide
Tasten drückt und dann die Rechte eher los lässt als die Linke... Da
reicht es dann auch nur etwa eine Sekunde zu drücken.
Michael W. schrieb:
> Ich bekomme den Germsloader einfach nicht zum laufen - jedesmal die> Meldung, dass das DSO nicht antwortet... :-(
Das Problem hatte ich allerdings auch schon. Das Win32::SerialPort-Modul
scheint den Port nicht korrekt zu initialisieren (bzw. ich tu es nicht
richtig mit dem Modul, je nachdem, wie man es sehen möchte :D). Ich
musste bisher schon ab und zu erst mit der WelecUpdater.exe einfach
einen Upload beginnen, nach ein paar Zeilen abbrechen und dann den
Script starten. Habe das bisher auf die Kombination aus XP in einer VM
und USB->RS232-Adapter geschoben. Falls das eher generischer Natur ist,
werde ich das nochmal untersuchen.
michaelk schrieb:
> Bei mir klappt der Start des Germsmonitor ganz gut, wenn man beide> Tasten drückt und dann die Rechte eher los lässt als die Linke... Da> reicht es dann auch nur etwa eine Sekunde zu drücken.
Klasse. Klappt hier auch einwandfrei.
/Hannes
Auch bei mir scheint der Port nicht richtig initialisiert zu werden.
Dann stelle ich kurz mit Hyperterminal eine Verbindung her und beende
sie direkt wieder. Danach funktioniert auch das Skript wieder.
PS:
Mein 2024 ist immer noch nicht da. Ich hatte das verfusselte Gerät am
9.5 zurückgeschickt. Seit dem 14.5. sollte das neue unterwegs sein. Zwei
Anfragen wegen der Trackingnummer blieben unbeantwortet. Montag werde
ich bei ebay den Artikel als nicht erhalten melden.
Johannes Studt schrieb:
> Script starten. Habe das bisher auf die Kombination aus XP in einer VM> und USB->RS232-Adapter geschoben. Falls das eher generischer Natur ist,> werde ich das nochmal untersuchen.
Man sollte sich wirklich mal mit Dokumentationen befassen. Ich glaube,
dass da bisher was fehlte. ;)
@Kurt bzw. $ANY_WIN_USER: bitte probier das jetzt mal, ohne vorher mit
HyperTerminal die Schnittstelle zu initialisieren. In meiner VM hat es
auf jeden Fall hingehauen.
/Hannes
Tse,
elende Computertechnik. :D
Dann bleibt halt, bis da mal einer den wirklichen Fehler erkannt hat,
nur der Umweg über die Initialisierung mit Hyperterminal. Wenn diese
Krücke in der Dokumentaion mit auftaucht, wird sich sicher schnell ein
betroffener Perlkundiger finden, der das dann mal wirklich repariert.
/Hannes
... Satatn Ziege !
Das ist ja wirklich schnell - Junge-Junge! Gefühlt keine 2 Minuten!
Bei mir hat's jetzt hingehauen. Besten Dank nochmal. So macht ein Flash
doch mal Spaß.
Werde ich mir also den Updaten vornehmen und mal sehen, ob ich das mit
dem auch hinbekomme...
Kann mir jemand diese Zeilen erklären:
- if ($line =~ /^#.*/) {
- while ($buffer !~ /\+/) {
Ich würde gerne den Updater umschreiben/aktualisieren. War in Lazarus,
oder?
Michel
@ Johannes Studt : Perl kenne ich zwar nicht, aber unter Windows muss
man meist die Flags des DCB noch auf 0 setzen. Z.B. $serial->flags(0)
oder so ähnlich. Die Flags sind hierbei LongInt.
Gruß, Guido
>- if ($line =~ /^#.*/) {>- while ($buffer !~ /\+/) {
1.Zeile: Klammer ausführen, falls keine #-Zeichen am Anfang der Zeile
vorkommt
2.Zeile: Schleife solange ausführen bis ein +-Zeichen zurück kam.
Perl ist schon eine geile Sprache ;-)
Johannes Studt schrieb:
> @Kurt bzw. $ANY_WIN_USER: bitte probier das jetzt mal, ohne vorher mit> HyperTerminal die Schnittstelle zu initialisieren. In meiner VM hat es> auf jeden Fall hingehauen.
Hallo Hannes,
Bei mir ist nun auch die Initialisierung in Ordnung.
Der unterschied laesst sich leicht testen.
1. COM Port mit einem Terminal program (z.b. Teraterm) auf eine andere
Baudrate stellen (z.b 1200 Baud).
2. Download mit GERRMSLoader.pl versuchen:
--> das alte script scheitert
--> mit dem neuen get's!
Martin
Moin,
der aktuelle GERMSloader ist echt super! Funktioniert immernoch mit
meiner gammeligen Schnittstelle perfekt (drei oder vier retries, geht
eigentlich). Einzig das letzte Datum in der Flash-Datei (S804852AFC50)
funktioniert nicht. Eventuell sollte noch eine speziellere Behandlung
für S8-Records eingebaut werden?
;Daniel
>Einzig das letzte Datum in der Flash-Datei (S804852AFC50)>funktioniert nicht.
Das Oszi schickt hier nichts mehr zurück. Deshalb wartet das Skript.
Gehen tut es aber trotzdem.
Kann man aber abfangen, wenn man will. Habe nur gerade keine Zeit, dass
anzupassen. Ist im Prinzip sogar schon drinnen, nur wurde es im Laufe
der Entwicklung an die falsche Position geschoben ;-)
Stefan
Stefan E. schrieb:
> So,> jetzt wieder mit Enderkennung.> Hab dem Skript, nachdem es jetzt soweit ja ganz brauchbar ist, mal eine> Versionsnummer verpasst.>
Hallo Stefan,
Meiner meinung nach war die end Erkennung vorher besser platziert (so
wird sichergestellt das auch die letzte Zeile richtig übertragen wurde).
Was fehlte ist eine Behandlung des S8 records (S8 bedeutet "Start
programm with 3 Byte Address" das bedeutet dass der GERMS Monitor
verlassen wird)
Ich habe das ergaenzt (V1.0.1)
Martin
Letzten Endes ist die Zeilennummer als Endkriterium eh Käse, weil nie
mehr kommen kann als der Inhalt der Flashdatei. Darum ist die Behandlung
des S8-Befehls als Abbruch-Kriterium sicher das Sinnvollste.
Gibt es noch mehr Befehle als nur S8, die das DSO rebooten oder
anderweitig an der Antwort hindern?
/Hannes
Johannes Studt schrieb:
> Gibt es noch mehr Befehle als nur S8, die das DSO rebooten oder> anderweitig an der Antwort hindern?
Tja GERMS steht für G (go) E (erase) R (relocate) M (memory) S (srec)
==> G ist auch ein Kandidat ohne Rückkehr
und natürlich S7 (4 Byte Startadresse) und S9 (2 Byte Startadresse)
Gruß,
Günter
Hallo,
ich spiele gerade am Kantentrigger rum. Habe den Kanal 1 mal umgestellt.
Kanal 2-4 sind unverändert. Ich finde, das Einstellen des Triggerpegels
funktioniert schon deutlich besser. Dazu ist zu beachten, dass bei
aufsteigend getriggerter Flanke, der obere Rand eines Signal gut erkannt
wird und der untere nicht. Bei negativer Flanke verhält es sich genau
umgekehrt.
Außerdem trifft die Flanke noch nicht den eingestellten Zeitpunkt. Das
kommt auch noch ;-)
Bitte mal rückmelden, ob es bei euch auch besser ist. Ich habe es bis
jetzt nur mit dem internen Signalgenerator getestet. Vielleicht kann
jemand mal andere Signalformen testen.
Hi Leute,
um keine Langeweile aufkommen zu lassen hier schon mal die versprochene
Rollmode-Demo. Der Rollmode setzt automatisch bei Timebases >= 5 S/Div
ein. Wenn Ihr kein geignetes langsames Signal habt könnt Ihr durch
Drehen am Zerolevel eine quasi Flanke erzeugen die dann den Verlauf des
Signals zeigt. leider ist das Timing immer noch etwas widerborstig wie
Ihr evtl. sehen werdet.
Der Shiftmode ist in Arbeit und kommt demnächst. Trigger und
Memoryscrolling stehen in diesen Betriebsmodi nicht zur Verfügung und
sind meines Erachtens auch eher überflüssig.
Gruß Hayo
@Stefan
wenn Du mit der Triggererkennung weiterkommst, poste mal das Coding,
dann kann ich das in die nächste Beta mit einbauen. Wie Du sicher
gesehen hast, hab ich an den Stellen auch schon meine Duftmarke
gesetzt...
Hayo
Hallo Hayo,
ich schicke dir bei Gelegenheit mal meine Änderungen. Hast du es mal
probiert, ob es bei dir auch besser funktioniert?
Ich habe die Berechnung für das Triggerschwellenregister mal neu
formuliert. Hier muss doch der Schwellwert in der Größenordnung, wie der
ADC im eingestellten Spannungsbereich Werte liefert, gespeichert werden
(also z.B. zwischen einen Wert zwischen 100 und 160)
@Sefan
Da bist Du auf dem richtigen Weg. Das stand bei mir auch noch auf der
Liste, aber man kommt ja zu nichts. Und zwar wollte ich statt des festen
Wertes, der definitiv falsch ist, mal die Berechnung des Zerolevels
verwenden so wie ich ihn in Hardware::ReadOut_Signal() zur Berechnung
des Ground-Coupling verwendet habe:
Virtual_Zero = ADC_ZERO + int((float)Virtual_ZeroLevelCH1 /
scale_factor[Selected_Voltage_CH1]);
Zum Vergleich sinngemäß die nicht funktionierende Originalroutine die
ich ersetzt habe:
Virtual_Zero = (ZeroLevelCH1 + 64) >> 1
So ähnlich sieht das ja auch beim Triggerlevel aus. Daher vermute ich
mal das es damit schon getan sein sollte.
Bin allerdings noch nicht zum Testen Deiner Source gekommen, da ich in
den letzten Tagen etwas eingespannt war und nur gestern abend schnell
mal die Demo rausgehauen habe.
Gruß Hayo
Sodala Hayo,
habe meine hardware_t.cpp in SourceForge hochgeladen. Änderungen sind in
UpdateTrigger, Handle_ADC, und in FindTrigger zufinden. Man könnte die
Werte, die in FindTrigger und UpdateTrigger jetzt berechnet werden auch
global zwischenspeichern. Bin mir aber nicht sicher, ob sich das für die
Geschwindigkeit her lohnt.
Ich bin jedenfalls ganz zufrieden. Er triggert sauber, auch auf den
Überschwinger den der interne Rechteckgenerator an der Flanke liefert.
By the way,
ich habe in SourceForge mal in die tc_vars.h eine Reihe defines für
MenuStatus eingefügt. Kannst du die per Suchen/Ersetzen in die Dateien
einfügen? Ich werde sonst verrückt ;-) Und wenn ich das mache gibts nur
ein Versionschaos, weil ich nicht weiß, wo du gerade werkelst.
Gruß,
Stefan
hallo
@stefan
ich habe deine änderung mal getestet. sieht gut aus. jetzt passt die
triggerung auch zu den triggermarken. es ist mir jedoch etwas
aufgefallen. getestet mit dem calib. rechteck. mit aktivem autotrigger
lässt sich nur bis zu einer zeitbasis von 200us triggern. bei
schnelleren zeitbasen funktioniert die triggerung nich mehr. es ist also
nicht möglich, sich die steigende oder fallende flanke eines rechtecks
genauer anzuschauen. im normalmodus des triggers funktioniert es.
@hayo und guido
ich hatte es weiter oben schon mal geschrieben als die .63 rausgekommen
ist. glaub aber es ist damals in der diskusion um das perl script
untergegangen.
es ging um die, seit der .63 fehlenden, werte der readout cursor und um
die merkwürdige verschiebung im delayed modus. bis 50ns wird das delayed
signal, in bezug auf den auswahlbereich, etwas verschoben dargestellt.
ab 20ns wird offenbar ein komplett falscher speicherbereich ausgelesen.
das delayed signal passt dann gar nicht zum auswahlbereich und wenn man
den auswahlbereich weiter nach links verschiebt, werden irgendwelche
konstanten daten aus dem ram im delayed fenster angezeigt.
übrigens zzt. lässt sich der build aus dem svn nicht compilieren weil in
tc_vars.h die deklaration von iScale_Factor auskommentiert ist. das
array wird aber in der InterpretUART-funktion benötigt.
gruß sunny
@ sunny
sorry, mein Fehler. Hab eine alte Datei verarbeitet. Etz müsste es
wieder passen.
Ich habe bis jetzt nur mit dem normalen Trigger getestet. Auto muss ich
dann morgen mal probieren.
Gruß,
Stefan
Hallo,
@ sunny: habe oben schon geschrieben, dass es bei mir jetzt auch
sichtbar ist und bin dran (Flash läuft gerade). Falls ich es
hinbekomme, muss ich erst nocht testen, welche Änderungen nötig
sind.
@ stefan: ah, dann probiere ich ev. später auch noch mal, ich habe
mit den Syntaxfehlern kapituliert.
Gruß, Guido
Hi Jungs,
bin grad zu hause eingetrudelt. Hier tut sich ja in letzter Zeit
geradezu erschreckend viel. Bin ich aus den letzten Monaten gar nicht
gewöhnt.
@Stefan
Ich werd mir Deine Änderungen morgen mal zu Gemüte führen und einbauen.
Evtl. werd ich schon früher eine neue Beta raushauen, damit die
Änderungen für alle verfügbar sind und wir auf der gleichen Basis
weitermachen. Die Perlskriptecke war ja auch recht aktiv. Da kommt
wieder eine Menge zusammen im nächsten Release.
@Sunny
Nein die Anmerkungen sind nicht untergegangen. Hatte nur noch keine
Zeit. Ich denke an den fehlenden Cursorwerten ist Guido dran, da das
wohl direkt mit den Änderungen an der Plane-Größe zusammenhängt. Die
Zeitverschiebung
des Delayed-Signals hab ich schon länger im Auge, hab dem aber keine so
hohe Priorität zugeordnet.
Gruß Hayo
Hallo,
hab die Probleme bis auf eine Pixelzeile reduziert und die
kriege ich auch noch hin. Dann fange ich noch mal mit einer
sauberen Beta 0.63 an, um die Änderungen auf das notwendige
Maß einzuschränken. Also, morgen oder übermorgen.
Gruß, Guido
@all
Ich bin etwas erstaunt, dass seit der Rollmodedemo kein einziger
Kommentar dazu gekommen ist. Liegt es daran dass
- die Funktion eher uninteressant ist?
- Ihr kein geeignetes Testsignal habt?
- Ihr nicht so richtig wißt um was es geht?
- Ihr mit anderen Themen beschäftigt seid?
Gruß Hayo
>Ich bin etwas erstaunt, dass seit der Rollmodedemo kein einziger>Kommentar dazu gekommen ist. Liegt es daran dass>- die Funktion eher uninteressant ist?>- Ihr kein geeignetes Testsignal habt?>- Ihr nicht so richtig wißt um was es geht?>- Ihr mit anderen Themen beschäftigt seid?
Habs sogar gestern noch ausprobiert, dann aber wohl vergessen zu
erwähnen.
Hat bei mir gut geklappt. Was noch abgefangen werden muss ist, dass man
nicht den Trigger-Modus auf "normal" stellen können darf.
Gruß,
Stefan
Hayo W. schrieb:
> - Ihr kein geeignetes Testsignal habt?> - Ihr mit anderen Themen beschäftigt seid?
Sorry. ;-)
Aber am Wochenende komm ich sicher dazu, mal wieder was zu machen.
/Hannes
@Stefan
Ja Du hast recht, mit dem Triggermode muß ich mir was einfallen lassen -
und genau das meinte ich, das war mir nämlich noch gar nicht
aufgefallen.
Danke Hayo
Hi,
mal ein paar simple Fragen zum Scope, bzw. Messen:
Gestern Nacht habe ich mal ein wenig die höheren Frequenzen an dem
W2024A getestet. Ich hatte eine Schaltung mit 20 MHz Quarz am Oszi (Pic
Brenner für USB von Sprut):
- Das Signal am Quarz war beinahe sinusförmig, erwartet hätte ich eher
ein Rechtecksignal. Allerdings habe ich keinerlei Erfahrungen und vorher
nie ein Signal am Schwingquarz gemessen. Außerdem war die Amplitude sehr
niedrig, 500 oder 600 mV, bei 10:1 Tastkopfeinstellung sind das dann ja
nur 50 bzw. 60mV. Erwartet hatte ich TTL-Pegel oder wenigsten die Pegel
für 3V Logik. Liegt die Sinusform an den kleinen Kerkos am Quarz?
- Das Signal hatte ich mit der Tastkopfeinstellung 10:1 gemessen. Als
ich auf 1:1 umgestellt hatte und die Empfindlichkeit am Scope
entsprechend in die andere Richtung geändert hatte, bekam ich kein
Signal auf den Schirm. Erwartet hatte ich das gleiche Signal oder
höchstens in der Amplitude unterschiedlich... Auch hier muss ich sagen:
vorher kaum/keine Erfahrungen mit dem Messen und dem Ändern der
Tastkopfeinstellungen.
Habe ich irgendwo Denkfehler? Wenn ich heute Abend wieder zu Hause bin,
könnte ich einen Screenshot posten.
Michel
Hallo Michael,
du hast tatsächlich einen Denkfehler. Der Tastkopf hat keinen
Verstärker, sondern einen "Abschwächer".
Wenn man den Tastkopf auf 10:1 stellt, dann wird dein gemessenes Signal
bei 1:1 Einstellung im Gerät um den Faktor 10 kleiner dargestellt.
Abhilfe schafft hier die Umstellung des betreffenden Kanals auf 10:1,
dann wird dein Signal wieder umgerechnet und mit "realer" Amplitude
dargestellt.
Aus einem Quarz kommt vereinfacht angenommen ein sinusförmiges Signal.
Tatsächlich besteht das Signal jedoch aus einem komplexen
Frequenzspektrum. Was du zu meinen scheinst ist ein Quarzoszillator.
Hier befindet sich noch eine aktive Schaltung unter dem Gehäuse, die für
das rechteckförmige Signal bestimmter Amplitude sorgt.
Gruß, branadic
Hallo Michael,
als Ergänzung zu branadics Erläuterung noch: Im 1.1 Betrieb hat
der Tastkopf ca. 40 pF Eingangskapazität. Wenn du das direkt an
den Quarz legst, reißt die Schwingung wahrscheinlich ab.
Gruß, Guido
@Stefan
Bin gerade dabei Deine Änderungen zu sichten und einzubauen. Sehe ich
das richtig, dass Du bei ReadOut_Signal() einen Parameter gelöscht hast
weil er überflüssig war?
Hayo
Hallo Hayo,
siehst du richtig. Der Parameter kam in der ganzen Funktion nicht vor.
Kommt auch kein Compilerfehler und es geht immernoch. Also weg mit den
Altlasten ;-)
Stefan
Alles klar!
Wie verwurstet das Coding war kann man auch daran sehen, dass trotz
zahlreicher Neuerungen von mir das Coding immer kleiner geworden ist
durch die ganzen Löschungen und Redesigns.
Trotz einiger Aufräumaktionen gibt es immer noch zig nicht benutzte
Variablen und Funktionen. Ein weiterer Kandidat sind die Routinen für
Timer 1 mit dem eigentlich der Autotrigger-Timout gesteuert werden
sollte. Nach meinen derzeitigen Erkenntnissen wird das aber überhaupt
nicht genutzt. Ich werde da noch mal weiter prüfen und gegebenenfalls
deaktivieren.
Gruß
Hayo
Jo,
da gibts noch eine ganze Menge Sachen, die einfach krank sind. Auch die
ganzen einzelnen Konstanten, die für alle Kanäle einzeln angelegt sind.
Wie blöd ist das eigentlich. Der Code würde sich mindestens auf die
Hälfte reduzieren, wenn der Kerl an der einen oder anderen Stelle ein
Array verwenden würde.
Am besten finde ich ja den Kommentar in der ursprünglichen Source:
>TMW: "Some bugs found, not easy to understand software structure">TMW: "All to be improved!!!"
Stefan
(THW ist das Kürzel des Namensgebers der Firma)
Ich denke die Aussage "Some bugs found" trifft das Ausmaß der Sache
nicht so ganz...
Das mit den nicht verwendeten Arrays hat mich auch schon genervt. An
einigen Stellen hab ich das auch schon geändert im Rahmen der DAC und
ADC-Kalibrierung. Aber es sind zu viele solcher Baustellen um es auf
einmal zu machen. Also weiter Stück für Stück.
Gruß Hayo
Hallo Leute,
ich möchte gern noch mal nachfragen, ob jemand noch einmal das genaue
Vorgehen für den Flash/RAM-Upload unter Windows und Linux zusammenfassen
kann.
1. Was für Tools werden benötigt?
2. Wie ist die Reihenfolge beim Upload?
Ich würde es natürlich begrüßen, wenn der- oder diejenige dies direkt
auf SF erledigen würde, damit alle Leute international etwas davon haben
und es auf der Projekthomepage gebannt ist.
Wir sind nach wie vor bestrebt mehr und mehr Übersichtlichkeit in die
Projekthomepage zu bekommen und ich denke wir sind da auf einem recht
guten Weg.
Ihr könnt euch ja selbst davon überzeugen und seid herzlich eingeladen
dabei auch mitzuwirken, sei es durch Beiträge oder
Verbesserungsvorschläge.
Vielen Dank, branadic
Hallo Hayo,
ich hoffe, dass die Pixelfehler jetzt endgültig behoben
sind. Es sind nur kleien Änderungen nötig, wie du dem
Anhang entnehmen kannst (sieht nur so lang aus, weil ich
einfach Codeteile kopiert habe um Suchbegriffe zu liefern).
Alle Änderungen in hardware_t.
Gruß, Guido
Ich werde für die nächste Beta meine "Beipackzettel" dahingehend
erweitern. Dann braucht nur noch einer den Text der englishen Fassung
ins SFN zu kopieren. Ist das ok?
Apropo, mein letzter Stand bezüglich GERMSloader-Skript war 1.0.2 - ist
das der aktuelle Stand?
Hayo
Hallo Hayo,
das wäre in jedem Fall sehr hilfreich. Ich würde das dann einpflegen.
Nebenbei bemerkt hat die Projektseite ein etwas anderes Gesicht:
http://apps.sourceforge.net/trac/welecw2000a/
Gruß, branadic
Ja ich hab mich da heute auch schon getummelt um Stefans Sourcen
runterzuladen. Macht wirklich einen netten Eindruck. Ich werde den Link
mal mit in mein Package aufnehmen. Was ich vermisse ist eine
Downloadecke wie bei Google Groops in der man ganze Softwarepakete für
den Download hinterlegen kann. Zudem mußte ich etwas nach unseren
Sourcen suchen, da ich sie nicht unter "FPGA" vermutet hätte.
Alles in allem aber schon sehr ansprechend und auch sehr hilfreich für
Neueinsteiger. Die Online-Versionsverwaltung ist auch nicht übel, aber
hier muß sich jeder seine Source selbst zusammenstellen aus den
verschiedenen Versionen. Da wären zusätzliche Komplettpakete ganz
hilfreich (oder hab ich die Ecke übersehen?).
Hayo
Hallo Hayo,
für den Upload/Download steht das Repository zu Verfügung. Hintergrund
ist einfach, dass die Sachen halbwegs geordnet sind und nicht einfach
wild upgeloadet werden und durcheinander in einem einzigen Ordner
liegen, wie es bei GoogleGroup der Fall ist.
Dies ist die Downloadecke für SF.
Eine Übersicht zur Repository Struktur ist auf der Startseite vom Trac
zu finden:
http://apps.sourceforge.net/trac/welecw2000a/wiki/Repository
Das die Sourcen zur FW ausgerechnet unter FPGA liegen ist auch bei uns
noch ein kleiner Diskussionspunkt.
Prinzipiell hat man recht zu sagen, dass die FW im FPGA läuft. Auf der
anderen Seite kann man aber wieder argumentieren, dass unter FPGA eher
das Design und der Softcore-Entwurf zu verstehen sei und die FW nur zur
Ansteuerung des Softcores da ist.
Man kann argumentieren wie man will und jeweils für und wider finden.
Vielleicht ist es ja schon hilfreich das Repository als Downloadecke
besser kenntlich zu machen?
Beste Grüße, André
Hallo Leute,
wie gerade schon mit André geklärt, ist das Repository nicht wirklich
für Release-Downloads zuständig. Sourcen gehören da rein zwecks
Versionierung, klar. Aber so ganze Zips, wie Hayo sie veröffentlicht,
gehören in die Sourceforge-Download-Ecke. Die ist allerdings etwas
ätzend zu verwalten, man muss die Sachen irgendwie erst per SFTP
hochladen, um sie dann per Webinterface aus diesem Staging-Server auf
die Seite zu bringen. Dafür kann man aber Kategorien und sowas alles
anlegen für die Downloads und auch direkt Versionen anzeigen usw.
Können das gern mal zusammen erproben, wie dort was hochgeladen wird.
Ich hatte das schonmal testweise für den USB-Blaster-Treiber gemacht,
und ich denke, wenn man das ein paarmal gemacht hat, geht das auch recht
fix von der Hand. Am Besten wäre, wenn Hayo oder jemand anderes, der die
Releases machen will, mal im Skype-Chatroom vorbeischaut, dann können
wir die Probleme zeitnah klären.
Grüße
;Daniel
Nachtrag: Der Rollmode hat was meditatives an sich. Einfach auf 200mV
stellen und den Finger an die Messspitze halten ;)
Was ich aber sagen wollte ist, dass die Indikatoren bei mir flackern,
also Trigger- und Ground-Level und der AC-Indikator. Nur mal so am Rande
Crazor schrieb:
> Nachtrag: Der Rollmode hat was meditatives an sich. Einfach auf 200mV> stellen und den Finger an die Messspitze halten ;)
Hier ist das Motto eile mit Weile. Man sollte schon etwas Zeit
mitbringen. Ich hätte das natürlich auch Zeitlupenmodus nennen können
;-)
> Was ich aber sagen wollte ist, dass die Indikatoren bei mir flackern,> also Trigger- und Ground-Level und der AC-Indikator. Nur mal so am Rande
Das flackert deshalb, weil zwischen zwei Meßwerten die Graphikroutine
(anders als im Normalmodus) mehrfach durchlaufen wird (bis der Timer
einen Interrupt auslöst) und bei jedem Durchlauf die Markierungen
gelöscht und dann neu geschrieben werden.
Hayo
Hallo zusammen,
für alle die genauso fit mit Perl sind wie ich hier mal schnell eine
kleine Anleitung für die Windows-User.
Ich hab mir Active Perl installiert. Anschließend hab ich mir noch
Win32-SerialPort-0.19 aus dem Netz geladen und unter C:\Perl\lib\
entpackt.
Nun über Start-->Ausführen-->cmd die Windows-Console starten und in das
Verzeichnis mit der .ram bzw. .flash Datei wechseln. Dort sollte sich
auch die GERMSloader_1.0.2.pl befinden. Mit cd und cd.. sollte man
vertraut sein.
Um die TomCat.ram in das Gerät über den Port COM1 zu laden muss in die
Console folgende Zeile eingetippt werden:
perl GERMSloader.pl COM1 TomCat.ram
@ Hayo:
Mir ist beim Verstellen der Zeitbasis ohne vorherige Kalibrierung
ausgefallen, dass Kanal3 ab 10µs wieder dutzende von Spikes bei mir
anzeigt, die bei 5µs und kleiner jedoch nicht auftreten.
Nach der Kalibrierung sind sie dann plötzlich weg. Falls also jemand mit
ähnlichen Symptomen zu kämpfen hat wei0 er wo er dran drehen kann.
Beste Grüße, branadic
Hallo Hayo,
vielleicht noch ein kleiner Nachtrag, bevor man die Console aufruft muss
der GERMSmonitor noch gestartet werden.
Ansonsten findet sich eine aktuelle (englische) Beschreibung zum Umgang
mit dem WelecUpdater und dem Upload via Perl unter Windows im SF-Wiki:
http://apps.sourceforge.net/trac/welecw2000a/wiki/FWupload
Beste Grüße, branadic
Hallo,
mal ganz naiv gefragt: konnten wir nicht eine der Testfunktionen
verwenden um direkt in den GermsMonitor zu springen? Damit könnten
wir den Upload weiter automatisieren (nicht dass jemand langweilig
wird ;-)).
Gruß, Guido
So, hier zum langen Wochenende was zum spielen.
Die neue 0.65 beta enthält im Wesentlichen den neuen Roll und den
Shiftmodus. Die Umschaltung findet Ihr im Timebasemenü (Main/Delayed).
Weiterhin habe ich die Änderungen von Stefan für die Triggerung
eingebaut. Allerdings klappte das trotz der eigentlich korrekten Formel
noch nicht so ganz 100 prozentig. Da die Ursache nicht offensichtlich
ist habe ich erstmal mit harten Korrekturen das Triggerverhalten so
hingebogen dass es ganz passabel läuft.
Der Fehler mit den fehlenden Cursorwerten ist noch nicht gefixt, da ist
Guido wohl dran, so dass der Fix erst in die nächste Beta einfließt.
Zur Source:
Die Ersetzungen mit den neuen #defines für die Menüs ist noch nicht
nicht ganz komplett, kommt aber noch.
Viel Spaß
Hayo
Hi,
hat jemand das Perl-Script schon unter Windows mit einem USB <-> Seriell
Adapter zum Laufen bekommen? Mit dem realen Port meines Rechners geht's
ohne Probleme, mit dem Adapter an meinem Laptop nicht :-(
Hab angefangen mich in den Updater einzuarbeiten - im Vergleich zu dem
Script wirklich häßlich :-/
Michel
Michael W. schrieb:
> hat jemand das Perl-Script schon unter Windows mit einem USB <-> Seriell> Adapter zum Laufen bekommen?
Ja.
> Mit dem realen Port meines Rechners geht's ohne Probleme, mit dem Adapter> an meinem Laptop nicht :-(
Was heißt "geht nicht"? Wenn du das genauer ausführen kannst, kann man
vllt was "löten" ;)
> Hab angefangen mich in den Updater einzuarbeiten - im Vergleich zu dem> Script wirklich häßlich :-/
Das werd ich mir jetzt auch mal ansehen, kann ja schliesslich kaum eine
große Änderung sein, die den WelecUpdater dann genauso beschleunigt wie
das Perlscript. Sind sicher nur irgendwelche Parameter des Ports bzw.
der Serial-Dingsda-Unit.
/Hannes
Hallo,
@ Hayo: den Fix zu den Cursorwerten habe ich gestern schon
gepostet. Hast du wohl übersehen.
@ all: Habt ihr auch Zeichenfehler im ganz linken Button? Falls
nötig mache ich noch Bilder. Ich suche seit 2 Tagen nach dem
Grund und habe schon Drawsoftbutton und Pixelp komplett neu
geschrieben. Ich glaube fast, dass ich da ein Hardwareproblem
habe.
Gruß, Guido
Mach mal Bilder, damit man sich was drunter vorstellen kann.
Bei mir spackt der linke Button auch hin und wieder etwas rum.
Deinen Fix hatte ich tatsächlich übersehen.
Pflege ich schnell nach, dann gibt es morgen eine neue Beta.
Hayo
Hallo,
erstmal ein Bild. Die Buttons sehen komisch aus, weil die Ecken
noch fehlen. Die Fehler sind aber die weißen Linien im linken
Button, sowohl im Menu als auch in den Cursordaten. Mit:
1
//Testlines
2
y=300;
3
4
for((x=0);(x<640);x++)
5
{
6
PIXELP(x,y,1,UI_Plane1);
7
}
8
y+=20;
9
10
for((x=0);(x<640);x++)
11
{
12
PIXELP(x,y,1,UI_Plane4);
13
}
14
y+=20;
15
16
for((x=0);(x<640);x++)
17
{
18
PIXELP(x,y,1,UI_Plane5);
19
}
habe ich noch drei Linien gezeichnet, wobei die graue (UI_Plane5) und
die gelbe (UI_Plane4) korrekt gezeichnet werden. Die weiße (UI_Plane1)
jedoch nicht.
Ich hänge im nächsten Post noch das Tomcat.ram an, dann könnt ihr
das auch mal probieren.
Gruß zum Ersten, Guido
Jupp,
linker Softbutton ist bei ir auch defekt (Überlagerung?).
@Jo
In dem Script bekomme ich keine Antwort vom DSO (timeout). Ziehe einen
Stecker ab und starte es, dann hast Du eine Fehlermeldung, die ich
bekomme.
Zum Updater:
Im Vergleich zum Script wirklich unübersichtlich. 1500 Codezeilen gegen
120 Scriptzeilen - das ist schon ein Unterschied - Naja, der Updater
kann ja auch Backup machen... Es wird wirklich alles von Hand gmacht,
jedes Zeichen wird analysiert, einen Timer gibt's noch - wirklich
umständlich.
Michel
Hallo Michael W.,
jo Überlauf um 1 LW, das würde aber bedeuten, dass die Plane falsch
definiert ist, was ich mir kaum vorstellen kann.
Mit dem Updater habe ich mich auch schon rumgeplagt. Ist wirklich
sehr unübersichtlich. Ich habe nur unter Linux das Schreiben in
die Edit-Komponente rauskommentiert und direkt in ein File
geschrieben. Damit habe ich mein Original-Backup in akzeptabler
Zeit hinbekommen. Schon das war aber ganzschön langwierig, also
viel Spaß ;-).
Gruß, Guido
Michael W. schrieb:
> In dem Script bekomme ich keine Antwort vom DSO (timeout). Ziehe einen> Stecker ab und starte es, dann hast Du eine Fehlermeldung, die ich> bekomme.
Wenn ich den Stecker ziehe, kommt die Meldung, dass es den Port nicht
gibt. Wenn es die Timeout-Meldung wirft, sollte er vorher auch einige
Punkte ans erste Zeilenende gemalert haben.
> 120 Scriptzeilen - das ist schon ein Unterschied - Naja, der Updater> kann ja auch Backup machen... Es wird wirklich alles von Hand gmacht,
Backup müsste man halt ins Perlscript auch einbauen, ist sicher kein
großer Akt.
> jedes Zeichen wird analysiert, einen Timer gibt's noch - wirklich> umständlich.
Jo, hab auch gerade Knoten im Hirn. :D Aber langsam lichtet sich der
Nebel.
/Hannes
@Hayo,
die ramloader.bat in deinem Archiv hat aus irgendeinem Grund falsche
Kommentare.
Am besten nochmal die hier ins Archiv packen:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"
Was muss man tun, um in den Roll/Shift Mode zu kommen? Bei mir sind die
beiden Softkeys ausgegraut. (W2022A)
So hier die 0.66 Beta mit dem Bugfix von Guido.
@Kurt
> die ramloader.bat in deinem Archiv hat aus irgendeinem Grund falsche> Kommentare.
Ist erledigt.
> Was muss man tun, um in den Roll/Shift Mode zu kommen? Bei mir sind die> beiden Softkeys ausgegraut. (W2022A)
Tja da hast Du wohl die Homeedition. Dann must Du auf Professional
upgraden, wird nicht billig... ;-)
Im Ernst: Der USTB-Modus (Ultra Slow TimeBase) wird automatisch ab
5S/Div aufwärts aktiv. Dann stehen auch die beiden Menüpunkte zu
Verfügung. Gleichzeitig wird das Delayed Menü deaktiviert und die
Triggerung zwangsweise auf AutoFreeRun geschaltet.
Hayo
Johannes Studt schrieb:
> Jo, hab auch gerade Knoten im Hirn. :D Aber langsam lichtet sich der> Nebel.
Ich geb's erstmal auf, das werd ich demnext mal komplett leerlöschen und
neu schreiben.
> Backup müsste man halt ins Perlscript auch einbauen, ist sicher kein> großer Akt.
Und darum hab ich das erstmal fix gemacht. Stell ich dann oder morgen
noch hier rein, wenn es wirklich fertig ist.
/Hannes
Super!
Dann werd ich das mal in die 0.67 mergen die ich eigentlich schon heute
reinstellen wollte, aber da warte ich noch bis Dein Skript kommt.
Hab noch einige Detailverbesserungen eingebaut und wieder mal
überflüssiges Zeugs über Bord gekippt (wie schon vermutet war alles zum
Thema Timer 1 so überflüssig wie ein Kropf - wer also für seine eigenen
Routinen einen Timer braucht...)
Für den USTB-Modus habe ich die Timersteuerung umgestellt, läuft jetzt
gleichmäßiger ohne Ruckler und ohne "Warmlaufphase".
Der XY-Modus wird jetzt im Menu deaktiviert wenn ultra slow gemessen
wird.
Gruß Hayo
Hayo W. schrieb:
> Dann werd ich das mal in die 0.67 mergen die ich eigentlich schon heute> reinstellen wollte, aber da warte ich noch bis Dein Skript kommt.
Wird wirklich erst heute im Laufe des Tages, hatte grade noch Besuch.
Sry.
/Hannes
Hm,
habs vorsichtshalber schon mal angehängt, falls ich heute Morgen doch
nicht dazu komme. Es funktioniert auf jeden Fall, aber die neue
Fortschrittsanzeige muss ich noch in den Schreibmodus übernehmen, und
sicher auch noch ein paar andere Kleinigkeiten fixen, die meine
Bettschwere jetzt verdeckt.
Es ist ein neuer Parameter dazugekommen, der den Modus bestimmt:
Als Modus-Parameter kann man Klein- wie Großbuchstaben mit Binde- oder
Schrägstrich nehmen, "/R" ginge also auch.
Wenn man die Adressen weglässt, verwendet das Script beim Auslesen
defaultmässig 0x040000 und 0x7fffff.
/Hannes
Sodele,
ich denke, so kann man's erstmal nehmen. Wär schön, wenn es dieser oder
jener zeitnah testet. Bei mir läuft das Komplettbackup von 0x40000 bis
0x7FFFFF in 0:40h durch, mit dem WelecUpdater hab ich das (nach Löschen
aller Bildschirmausgaben im Code) in 1:42h geschafft. Ist also durchaus
etwas schneller.
Schreiben geht nach wie vor wie bisher auch, nur die Fortschrittsanzeige
ist etwas hübscher.
Bedienung:
>> Als Modus-Parameter kann man Klein- wie Großbuchstaben mit Binde- oder> Schrägstrich nehmen, "/R" ginge also auch.>> Wenn man die Adressen weglässt, verwendet das Script beim Auslesen> defaultmässig 0x040000 und 0x7fffff.
Fehler werden fast gar nicht abgefangen, mal abgesehen von nicht les-
oder schreibbaren Dateien oder fehlenden Parametern. Insbesondere wird
NICHT gewarnt, wenn beim Auslesen der Firmware eine bestehende Datei
überschrieben würde. Also immer Augen auf beim Eierkauf.
/Hannes
Ich habe eben ein BackUp mit dem Script gemacht. Dauer 42 Minuten.
Im Vergleich dazu ein Backup mit dem Updater. Dauer 45 Minuten.
Allerdings liest das Script eine Zeile mehr ein.
Die letzten Zeilen vom Script:
S315007F0480050000000000803F266F420050FE9F005F
S315007F049077004000E9CA9944871A443663D64200FA
S315007F04A064000000000C9200000000002323232339
S313007FFFF0FFFFFFFFFFFFFFFFFFFFFFFFFFFF8C
r0
Die letzten Zeilen vom Updater:
S315007F0480050000000000803F266F420050FE9F005F
S315007F049077004000E9CA9944871A443663D64200FA
S315007F04A064000000000C9200000000002323232339
r0
Jo, ist aber nicht schlimm. Der Updater lässt Zeilen, die
ausschliesslich 0xFFFF enthalten, weg. Das mache ich auch, aber nicht
ganz so akkurat (ich suche nur nach kompletten Zeilen, und da die Zeile
nicht komplett ist, landet sie doch im Backup).
Interessant ist, das der WU bei dir fast genauso schnell ist wie das
Perlscript. Ist das beim Schreiben auch so?
/Hannes
Interessant...
Hab grade noch gesehen, dass das Schreiben unter Windows in einem
standardmässigen CMD-Fenster räudig aussieht, weil ich glatt über die 80
Zeichen Breite wegschreibe. Kommt zwar eigtl nicht drauf an, aber ich
habs trotzdem noch geändert.
/Hannes
[OT]
Hallo,
vorab entschuldige ich mich schonmal dafür, euren Thread zu
"missbrauchen". Ich mach's auch kurz. Versprochen ;-)
Ich würde mir gerne ein W2024A kaufen. Bei eBay werden die Scopes für
380 Euro - 450 Euro gehandelt. Kann man da zuschlagen oder kennt jemand
bessere / günstigere Anbieter?
Grüße,
ein-vielleicht-baldiger-W2024A-Besitzer
[/OT]
Mir ist ueberhaupt kein anderer Anbieter bekannt. Bei dem Ebay
Verkaeufer handelt es sich auch um irgendwen der Fa. Wittig.
Kurzum: Wenn nicht jemand die Nase voll von seinem Oszi hat und es dir
verkauft, ist Ebay der einzige Weg.
Gruessle
Interessent schrieb:
> Ich würde mir gerne ein W2024A kaufen. Bei eBay werden die Scopes für> 380 Euro - 450 Euro gehandelt. Kann man da zuschlagen oder kennt jemand> bessere / günstigere Anbieter?
Wenn Du ein W2014 günstiger kriegen kannst nimm es! So wie es momentan
aussieht unterscheiden sich die 100MHz Geräte und die 200MHz Geräte wohl
nur durch das Label. Ich selbst habe auch beide Varianten und effektiv
nutzen kann man beide ohnehin nur bis 25MHz (zumindest im
Originalzustand).
Hayo
Die bei Ebay ueblichen Preise natuerlich. Ich hab mein 2024 fuer 350,65
bekommen.
Nu schluss mit OT. Entweder ists dir den normalen Preis wert oder eben
nicht. Mehr Oszi fuer weniger Geld gibts ohnehin nirgends und Dank der
Spitzenarbeit von Bruno, Guido, Hayo & Co (alphabetische Reihenfolge ;))
wirds wahrscheinlich irgendwann sogar noch zu einem ganz gut brauchbaren
Geraet.
Gruessle
Hallo,
ich bin erst jetzt dazu gekommen die neue Beta zu testen. Das
sieht ja klasse aus. Die Triggerung funktioniert wirklich gut
und auch der Rollmode macht Spaß. Ich messe zwar selten soo
langsame Signale, aber der "Gummibandeffekt" durch den
Linienalgorithmus ist echt toll. Warum setzt der Rollmode erst
so spät ein? Das könnte doch ruhig schon bei 200 ms/div so
losgehen.
Es geht sichtbar voran, das liefert genau die nötige Motivation
um weiße Pixelfehler zu analysieren.
Gruß, Guido
Erstmal vielen Dank für die vielen Infos welche hier schon
zusammengetragen wurden.
Ich habe mich heute mal mit der USB-Problematik beschäftigt, mit dem
Ziel das Firmware-flashen etwas einfacher und vielleicht auch schneller
zu machen.
Nachdem mein Programm nun, zumindest im im groben erstmal funktioniert
ist mir allerdings klar geworden, das das zweite Ziel (schneller) mit
der derzeitigen Implementation leider nicht zu erreichen ist.
Was interessantes habe ich nebenbei trotzdem herausgefunden, nachdem ich
im Welec W2000Update ein bischen geschnüffelt habe.
Gebt mal, nachdem das Programm gestartet ist "89174" ein, dann
erscheinen einige weitere Buttons, mit denen man vielleicht irgendetwas
sinnvolles anstellen kann?
Soviel habe ich schon rausgefunden:
- c:\workfiles muß existieren dort werden die ausgelesenen Dateien
abgelegt.
- "USB-Reset" löscht den EEPROM vom USB-Controller also besser ! NICHT !
probieren
- Receive Flash liest irgendwelche Speicherbereiche aus und schreibt sie
in Files in o.a. Directory, Achtung dauert ewig wie oben schon
geschrieben.
Gruß
Hi Guido,
ich hätte den Rollmode auch gerne schon früher eingesetzt, aber hier
sind uns leider natürliche Grenzen gesetzt. Wenn ich den Timer auf Null
setze komme ich auf eine minimale Zeitbasis von 2,5 S/Div - für 2 S/Div
reicht es also gerade nicht mehr und die nächste ist dann 5 S/Div.
Ich habe den ADC-Count schon auf 128 runtergesetzt, aber das wirkt sich
nur auf das Auslesen aus, der Wandler wandelt trotzdem alle 16385 Werte
bevor er den Interrupt auslöst. Falls Du eine Möglichkeit findest das zu
ändern, könnte ich hier natürlich noch was machen.
Anbei mal der generelle Ablauf im Rollmode -> kann auch gerne zu
Dokumentationszwecken ins SFN-Wiki.
Im Übrigen bin ich schon die ganze Zeit dabei lauter kleine
Unstimmigkeiten zu beseitigen und den Rollmode für den XY-Betrieb
einzurichten. Mit dieser Funktion dürfte unser DSO wohl auf dem Markt
ein Unikum sein schätze ich...
Hayo
Hallo Hayo,
das wird schon ein riesiger Aufwand, weil in alle benutzte Funktionen
Fallunterscheidungen bzgl. USTB eingebaut werden müssen. Meine
Überlegung ist, die ADC sehr schnell laufen zu lassen und das
Timing über den Timer(2?) zu realisieren, wobei dessen eigentliche
Funktion in der ISR über einen Zähler mimikriert wird.
Es kommt aber auch noch eine vernünftige Realisierung der Funktionen
für Start/Stop und Single hinzu.
D.h.: Wenn dir Anderes wichtiger ist, lass es als Skelett erstmal wie
es ist. Im Vergleich zum Original zeigt es immerhin, wie es aussehen
sollte.
Wenn ich den verdammten Zeichenfehler gefunden habe, fange ich mal an
die ADC-Routinen in C umzusetzen (ich bin dann Disassembler ;-)).
Das könnte wirklich ganz interessant werden und die Rolle rückwärts
wäre bei zu langsamen Lauf leicht zu bewerkstelligen.
Gruß, Guido
Uups, ganz vergessen:
@ Fritz Richter: Das ist echt nett, die Postleitzahl von Herrn
Wittig? Die Flashdownloads betreffen wohl die zu ladenden
Hintergründe der Grafik. JTAG sieht ganz interessant aus. Ich
habe mich aber nicht getraut einen Button zu drücken, vllt.
probier ich noch. Wäre ja schön, wenn es mir mitteilt welche
Datei nicht gefunden wurde.
Gruß, Guido
Guido schrieb:
> Meine Überlegung ist, die ADC sehr schnell laufen zu lassen und das> Timing über den Timer(2?) zu realisieren,
Genauso funktioniert das ja jetzt auch -> siehe Schematik.
Hayo
So hier die Pfingst-Edition mit dem neuen Skript von Hannes. An dieser
Stelle noch mal meinen Dank an die Skriptschreiber, da die
Entwicklungszeit sich dadurch drastisch verkürzt hat. So schnell wie
jetzt bin ich vorher nie vorangekommen.
Die neue Version ist im Wesentlichen stabiler, fehlerbereinigter und hat
eine etwas geänderte Menüstruktur
Grid und Draw Switch sind jetzt im Displaymenü, der Browsebutton ist
jetzt im Timebasemenü.
An Bord ist natürlich das neue Perlskript von Hannes und angepasste
Shellskripte. Die Batchdateien für's Backup und Restore hab ich nicht
mehr geschafft, haben aber die gleiche Syntax wie die Shellskripte.
Gruß Hayo
Hallo Hayo,
die Schematik habe ich schon angeschaut. Wenn sich Timer2 nicht
feiner granulieren lässt (timerperiodh/l), müsste man das ev. in
den Timer1 einbauen, der ja ganz offensichtlich schneller kann.
Aber wie schon gemeint, es handelt sich doch um eine eher seltener
benutzte Funktion.
Gruß, Guido
Hallo Kurt,
> Und noch ein Backup der V1.4 von 0x00040000 bis 0x000DFFFF.
aha, dein Ersatzgerät ist wohl angekommen! Mach noch einen
einen Download mit Config-Bereich, kann man manchmal brauchen,
wie ich gelernt habe. ;-)
Gruß, Guido
Hallo Guido,
ja, das Ersatzgerät ist angekommen. Zwei mal ;-)
Das erste hatte auch Staub, ein klapperndes Metallteil und einen
Kurzschluss zwischen der Main/Delayed Taste und Mode/Coupling.
Das zweite hat nur noch Staub. Aber so wenig, dass es nicht mehr stört.
Hier noch der Config von 0x000E0000 bis 0x007FFFFF
@Guido
Das Problem ist nicht der Timer. Der läuft wie er soll und läßt sich
auch prima einstellen - übrigens sind alle drei Timer gleich aufgebaut -
das Problem ist, dass man mit der Timerperiode nicht kürzer werden darf
als die Wandlungszeit des ADC - und die ist leider so lang weil man
immer warten muß bis alle Werte gesampled sind. Einzige Möglichkeit wäre
rauszufinden wie man den ADC dazu bringt weniger Werte zu holen.
Hayo
@ Hayo: Das habe ich mir gedacht, aber ist es nicht möglich
die Samplerate von der Timenase zu entkoppeln? Die ADC können
ja nun mal rasend schnell. Ich frage so doof, weil ich denke
du hast da einiges parat, während ich erst die ganzen Menüs
durchwühlen müsste.
Gruß, Guido
@Guido
Ja hab ich gemacht, der ADC läuft im USTB-Mode mit vollen 1Gsa/S
(Timebaseregister mit 0xFFFFFFFF laden -> siehe tc_vars.cpp Zeile 353).
Davon werden dann 128 Werte genommen und zur Glättung das arithmetische
Mittel berechnet. Das ADC-Set hat aber wenn es den Interrupt auslöst
trotz allem 4 x 4096 Werte gesampled. Diese Ansteuerung ist im FPGA
realisiert und ich weiß nicht, ob es im Design vorgesehen ist auch
weniger Werte zu holen. Das hieße nämlich das irgendwo ein
Counterregister anders gesetzt werden müßte. Wenn wir allerdings die
hardwarenahen Routinen umsetzen stoßen wir ja vielleicht darauf.
Hayo
@ Hayo: Sorry, ich kapiere es immer noch nicht. Für die
4096 (*4) Sample benotigt der ADC doch nur rund 16 µs.
Das kann doch bei 100 ms/div nicht ausbremsen?
Gruß, Guido
Ja, das hatte ich auch so ausgerechnet. Dazu kommen natürlich noch die
Ausleseroutinen. Ich hatte rein rechnerisch auch mit einem etwas
schnelleren Zugriff gerechnet. Ich habe allerdings auch den Verdacht,
dass evtl. der Trigger da mitmischt und eine Verzögerung bewirkt, obwohl
eigentlich nicht getriggert werden sollte.
Hayo
Die Timersteuerung läuft allerdings jetzt auch etwas anders als bei
meinen Tests, evtl. läßt sich da jetzt noch was rausholen, muß ich mal
prüfen.
Hayo
@Guido
Durch Dein hartnäckiges Nachfragen hab ich nochmal diverse Tests
durchgeführt und festgestellt, dass ich auf dem Holzweg war...
Das begrenzende Element ist tatsächlich nicht die ADC-Routine (hatte
mich auch gewundert aber nicht gleich zum Nachdenken gebracht) sondern
(hätte ich auch gleich drauf kommen können) die Graphikausgabe.
Ich habe jetzt mal testweise mehrere Ausgaben pro Durchlauf ausgelassen
und - oh Wunder - die machbaren Zeitbasen wandern weiter nach unten.
Werde also noch ein wenig tricksen und mal sehen was so geht.
Danke für die Anregung
Hayo
@ Hayo,
hört sich gut an. Ich habe gestern mal mit der Umsetzung der
Assemblerroutinen in C angefangen. Bei dem Transfer der Daten
kann man wohl nicht sparen, da es sich um eine FIFO-Struktur
handelt. Es müssen daher immer alle Samples ausgelesen werden,
damit der FIFO wieder leer ist. Andererseits konnte man doch
mit einer der Testfunktionen sich ADC-Daten aufs Terminal
holen. Könnte man mal schauen, was da gemacht wird.
Gruß, Guido
@Guido
Prima, dass Du Dich da reinhängst. Ich denke es wird heute eine neue
Beta geben mit erweitertem USTB-Support. Ich würfel gerade das Timing
neu aus. Bis jetzt geht es bis 500mS - mehr wird auch schon etwas
anstrengend für die Augen.
@Hannes
Nochmal eine kleine Rückmeldung zum GERMSloader 1.1.2 - läuft super
stabil unter Windows und Linux. Bislang hab ich schon ca. 20 - 30
Uploads gemacht.
- Linux RAMload 180 S
- Linux Flashload 200 S
- Windows Flashload 136 S
Alles mit echter RS232.
Linux auf Athlon 2000 PC, Windows auf Intel Dualcore Lappy.
Hayo
@ Hayo:
Ich habe jetzt READADC_ALL2 und EXTRACTADCVAL umgeschrieben. Wird
schön kompakt und von der Geschwindigkeit her merke ich bisher
keinen Unterschied (bei EXTRACT... hatte ich schon Bedebnnken).
Sagt dir der Stil zu? Noch kann ich mich umgewöhnen.
Klar, die Grafik braucht ja über 0,1 s, hätte ich auch dran denken
können. Wunder sind damit wohl nicht möglich.
Gruß, Guido
Hm ich haette 2 Sachen, die mir an der Benutzeroberflaeche aufgefallen
sind:
Ist nur ein Kanal aktiv, so laesst sich dieser nicht abschalten,sondern
erst nachdem man einen andern eingeschaltet hat. Ich meine aber mich
erinnern zu koennen, dass das nicht immer so war. Wenn das eine
Verbesserung sein sollte, so finde ich sie eher unpraktisch, da dem
Benutzer so die Reihenfolge der notwendigen Tastendruecke zum Wechseln
eines Kanals vorgegeben wird. Klar ist es logisch sinnlos, jedoch
druecke ich z.B. meist auf die Taste, die dem Finger grad am naechsten
ist :D
Mein Oszi will nach jedem Einschalten auf Pusweite triggern, auch wenn
ich vorm dem letzten Abschalten auf Edge gestellt hatte. Das war bis vor
2-3 Versionen auch noch nicht so. Allgemeines Problem oder spinnt mein
Config-Bereich auch?
Gruessle und danke fuer die tolle Arbeit
André
Hallo,
ich hab mal (im Anhang ein Bild davon) die Flanke vom Rechteckgenerator
in 10ns /div aufgelöst. Ein Sample dürften also ca. 5 Pixel sein?
Jedenfalls, schaut es sehr hässlich aus. Wenn man sich jetzt die Zacken,
die so stark nach unten ausreißen, gedanklich um eine Zacke nach links
verschiebt, würde es scheinbar perfekt passen! ADC und DAC-Abgleich habe
ich frisch davor gemacht. Werden die Kanäle vielleicht verkehrt
ausgelesen?
Hallo Stefan,
mach das doch bitte gleich noch mit Kanal 2, damit man sieht ob
es kanalabhängig ist. Bruno W. hatte das auch schon mal gezeigt,
aber ich kapiere erst jetzt die Zusammenhänge.
Gruß, Guido
Ich hab jetzt ein Weilchen mit dem Trigger herum gespielt. Speziell fiel
mir auf, dass bei mir bei Zeitaufloesungen <= 100µs der Trigger auf
Kanal 2 nicht funktioniert. Fuer die Tests habe ich den internen
Signalgenerator benutzt.
Nach langem Herumspielen bemerkte ich dann auch noch, dass das Oszi
gelegentlich die Triggerquelle "vergisst" und kurzerhand auf Kanal 1
zurueck stellt.
Gruessle
André
Nach einer kleinen Firmware-Änderung sieht es jetzt schon viel besser
aus. Zumindest auf Kanal 1. Auf Kanal 2 hat sich die Situation dadurch
verschlechtert, weil der scheinbar woanderst vertauscht ist. Werde
gleich mal noch weng testen.
Hallo Hayo
In FW1.2.BF.0.68_beta funktioniert der RollMode nicht mehr.
In 0.66 schon... Ist das bei Euch auch so?
Habe das TomCat.flash verwendet.
l.G. Roberto
Hallo zusammen,
den Thread verfolge ich jetzt schon eine Weile und muss erstmal meinen
Dank rüberbringen an alle Beteiligten. Ich habe ein W2022A und die
FW1.2.BF.0.68_beta drauf. Beim Testen ist mir aufgefallen, dass die
Timebase 500ms/div als 1us/div angezeigt wird.
Danke und macht weiter so!
Peter
Oha jetzt ist hier ja ordentlich was los. Bin zur Zeit bei der 0.69
zugange, dehalb hab ich erst jetzt mal reingeschaut. Durch die kurzen
Uploadzeiten kommt man ja zu nichts anderem mehr...
@Guido
Das sieht doch schon ganz geschmeidig aus. Der Stil ist erstmal nicht
wichtig, Hauptsache es funktioniert, ist übersichtlich und dokumentiert
(und natürlich schnell genug).
@Andre
Die Kanalsteuerung hab ich nicht geändert, da mir das so auch sinnvoll
erschien. Das sollte also bei der originalen FW genauso sein.
Das mit der Pulsweitentriggerung ist bei mir noch nicht aufgetreten.
Vielleicht mal das default Setup aufrufen und sonst mal bei Zeiten einen
Configdump einspielen. Der Configbereich wird in der Tat anders beackert
als im Original und hat sich auch zwischen den Versionen etwas geändert.
Die Sache mit der Triggersource muß ich mal checken.
@Stefan
Sehr interessant. Bin gespannt was Du rausfindest. Beachte aber dass Du
da im interpolierten Bereich arbeitest. Nicht das sich da ein Fehler in
meiner Interpol. Routine eingeschlichen hat. Also am besten immer mit
dem 50nS Bereich nochmal eine Sicherheitsüberprüfung machen
@Roberto
Doch gerade bei der 0.68 sollte es sogar besser funktionieren. Heute
kommt noch die 0.69 mit erweitertem Rollmode. Ach hier gilt erstmal
default Setup dann weitersehen evtl. mal einen Dump einspielen (geht ja
jetzt schnell).
Hallo,
hab jetzt auch den Kanal 2 wie den Kanal 1 hinbekommen, dass die Flanke
schön aussieht.
Könnt ihr mal bitte testen, ob bei euch das Signal auf Kanal 2, mit dem
internen Rechteckgenerator, wie das oben gepostete verbesserte Signal
von Kanal 1 aussieht. Es ist derzeit NUR Kanal 2 verbessert. Kanal 1
dadurch vorrübergehend verschlimmert worden.
Außerdem ist bei 10ns/div die Interpolation deaktiviert. Also nicht
wundern, wenn es eine leichte Klötzchenbildung gibt.
Vielleicht kann Bruno damit mal seinen Sinus messen.
Danke,
Stefan
So hier schnell die 0.69 Beta mit erweitertem Rollmode.
Da die Signalausgabe als Zeitkonstante so stark eingeht, mußte ich für
die Refreshrate auch noch eine Fallunterscheidung für die aktiven Kanäle
einbauen. D.h. je weniger Kanäle gleichzeitig aktiv sind, desto höher
die Refreshrate. Die Refreshrate ist noch nicht ganz ausgeknautscht,
hatte ich keine Zeit mehr zu. Ebenso bei Timebase 500mS/Div und 3 + 4
Kanalbetrieb, wo die Zeitbasis nicht ganz korrekt ist.
@Stefan
Hab leider heute keine Zeit mehr zu testen,
Gruß Hayo
Es ist mir ein absolutes Raetsel, was mein Geraet da macht.
Ich habe gerade eine Stunde(!) versucht, das Bild zu erzeugen, das
Stefan da gezeigt hat. Der Trigger wollte auf allen Kanaelen einfach gar
nichts tun. Bis ich irgendwann wild auf Run und Single herumgedrueckt
hab: ploetzlich funktionierte es.
Nach genuegend langem Herum drehen an allen an Zeitaufloesung und
Triggerzeitpunkt habe ich es nun auch erreicht, dass der
Triggerzeitpunkt sich von der linken Div bis nach links ausserhalb des
Schirms schieben laesst. Weiter nacht rechts komme ich allerdings nicht
:D. Ist das ein verstecktes Feature, das ich nicht kenne oder hakts da
echt? :D
@Hayo
Stimmt. Es war auch frueher nicht machbar, dass ALLE Kanaele
ausgeblendet werden. Habs mit der OriginalSW getestet. Halte ich
persoenlich fuer ein fragwuerdiges Verhalten.
Gruessle
André
Hallo André,
>Ist das ein verstecktes Feature, das ich nicht kenne oder hakts da>echt? :D
Jepp, ist ein Feature, nennt sich PreTrig im Triggermenu. Wenn du
das hochdrehst, kannst du die Vergangenheit anscheuen.
Gruß, Guido
Hallo Stefan,
die Verbesserungen mit deiner FW-Version konnte ich bei mir jetzt nicht
nachvollziehen, sieht immer noch genauso wüst aus wie auf deinem ersten
Photo.
Gruß, branadic
Die Funktion Pretrig ist mir natuerlich nicht unbekannt :). In diesem
speziellen Fall hat sie jedoch nichts bewirkt. Irgendwie "hing" einfach
alles, ich bekomms aber leider auch nicht reproduziert.
Viele Gruesse
André
Hallo brandiac,
das habe ich befürchtet ;-) Wobei es bei mir wirklich super
funktioniert. Vielleicht kannst du mal ein Foto machen, wie es bei dir
genau aussieht? Also mit der Testfirmware und evtl. mit Hayos. Wäre echt
super.
Stefan
Hallo Stefan,
ich hab jetzt noch mal Hayo's 0.69er aufgespielt, da sehen die Flanken
so aus, wie auf deinem zweiten Photo.
Das mit der Pretriggerfunktion habe ich bisher immer als lästiges
Hindernis gesehen, denn als Vorteil. Gerade wenn man eine Flanke schön
auf Bildschirmmitte haben möchte ist das ein Krampf.
Beste Grüße, branadic
Hallo branadic,
hab bei mir auch mal die 69er getestet und bei mir schaut es wie immer
verschoben aus. Irgendwie kommen bei mir bei Kanal 1 die Daten von ADC4
um eine Periode zu früh und auf Kanal 2 die von ADC2 um zwei Perioden zu
früh.
Jetzt würde mich interessieren, bei wem das Problem überhaupt auftritt.
Egal auf welchem Kanal. Nicht das ich der einzige bin ;-)
Gruß,
Stefan
So, jetzt habe ich auch zum ersten Mal Eure Firmware (0.69) getestet. ->
SUPERARBEIT!
Genial auch der Ram-Loader. Von einem Linux-Netbook über USB-Serial hat
es etwa 210 Sekunden gedauert.
@Stefan:
Du bist nicht der einzige. Sieht bei mir ähnlich aus. Kanal 1 hat diese
Verschiebungen, Kanal 2 ist in Ordnung (W2022A).
Keep on the good work!!!
Michael
Hallo
Habe jetzt auch 0.69 getestet.
Roll-mode geht jetzt wieder (ab500ms). Leider ist die Anzeige nicht
kontinuierlich sondern es werden immer so ca. 2 Kästchen nacheinander
gezeigt.
Bei der 0.66 zeigte er die Linie kontinuierlich an. (ab 5s)
(Geladen mit dem .flash - FW)
l.G. Roberto
Hallo,
nur mal so eine Idee: Kann die unterschiedliche Darstellung bei der
Flanke vielleicht mit den verschiedenen "Hardware-Versionen", die ja
bereits im FPGA-Design vermutet worden sind, zusammenhängen? Das in den
unterschiedlichen Hardware-Versionen die Reihenfolge, in der die ADCs
ausgelesen werden, vertauscht worden ist?
Vielleicht sollten wir, zur FW-Version mit der dieser Effekt auftritt,
dazu schreiben welche Hardware-Version zugrunde liegt, dann ließe sich
vielleicht leichter eine Schlussfolgerung ziehen.
Ich kann es nur leider gerade nicht, da ich auf Arbeit bin.
Gruß, branadic
@Roberto
Ja das ist korrekt, wie ich schon angedeutet habe geht die
Graphikroutine als Zeitkonstante sehr stark in das Gesamttiming mit ein.
Daher war ich gezwungen die Graphikausgabe je nach Zeitbasis und Anzahl
der aktiven Kanäle solange auszusetzen zwischen den einzelnen
Meßwerterfassungen, dass in den etwas schnelleren Zeitbasen bis zu 400
Punkte ohne Ausgabe erfaßt werden. Dieses Refreshtiming ist noch nicht
ganz ausgereizt sondern erstmal konservativ ausgelegt um ein stabiles
Timing zu garantieren. Zur nächsten Version werde ich das in Richtung
kontinuierliche Ausgabe optimieren.
Gruß Hayo
branadic schrieb:
> nur mal so eine Idee: Kann die unterschiedliche Darstellung bei der> Flanke vielleicht mit den verschiedenen "Hardware-Versionen", die ja> bereits im FPGA-Design vermutet worden sind, zusammenhängen? Das in den> unterschiedlichen Hardware-Versionen die Reihenfolge, in der die ADCs> ausgelesen werden, vertauscht worden ist?
Das ist in der Tat nicht auszuschließen und sollte auf jeden Fall näher
untersucht werden.
> Vielleicht sollten wir, zur FW-Version mit der dieser Effekt auftritt,> dazu schreiben welche Hardware-Version zugrunde liegt, dann ließe sich> vielleicht leichter eine Schlussfolgerung ziehen.
Das macht mich jetzt auch neugierig, denn ich hab bei meinen beiden
Geräten die HW-Version noch garnicht verglichen.
> Ich kann es nur leider gerade nicht, da ich auf Arbeit bin.
Dito, werde mich morgen dazu äußern.
Hayo
Hallo zusammen,
ich habe im Trac eine Seite eingerichtet, wo der Gerätetyp, die
Hardware-Version, die FW mit der getestet wurde und ob die Darstellung
der Flanke in Ordnung ist festgehalten ist. Ich wäre euch dankbar, wenn
sich freiwillige finden würden und mir an
branadic (ät) users (pünktchen) sourceforge (pünktchen) net
ihre Daten zukommen lassen würden.
Die Übersicht findet ihr unter:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
Dies könnte entscheidene Aufschlüsse über Unterschiede bringen und alle
können davon nur profitieren.
Wir haben uns zu dieser Seite vor allem entschlossen, damit nicht jedes
mal neu nachgefragt werden muss welches Gerät und welche
Hardware-Version zugrunde liegt. Die Seite kann jederzeit beliebig
erweitert werden, sodass Rückschlüsse schneller getroffen werden können.
Wenn ihr euren µC-Nickname und/oder euren Sourceforge-Nickname ebenfalls
mit preisgeben wollt, so werde ich auch dies mit einpflegen.
Ich werde nachher auch meine Info's dazu dort festhalten.
Beste Grüße, branadic
Hallo,
das mit den Hardware-Revisionen habe ich mir auch schon gedacht.
Meines (W2022A 8C7.0L) ist mit der 1.3 FW ausgeliefert worden. Habe aber
die 1.4 FW aus dem Forum hier mal installiert. Evtl. liegt da noch etwas
im Config-Flash, das der FPGA selbst ausliest und bei mir jetzt falsch
eingestellt ist?
Meine 1.3er kann ich leider nicht mehr aufspielen um das zu testen ;-)
Vielleicht hat ja noch jemand eine 1.3er mit gesichertem Config-Bereich
für mich? Dann könnte ich das mal ausprobieren.
Der Effekt ist absolut reproduzierbar. Auch nach Aus- und Einschalten.
Sobald die ADCs zeitlich verschoben sind in der FW, passts.
Servus branadic,
super Idee. Ich kann die Bilder auch kleiner machen, wenn du willst ;-)
Dann wirds etwas übersichtlicher.
Wichtig ist evtl. auch, welche Kanäle betroffen sind und welche Firmware
im Original drauf war.
Hallo Stefan,
hab deine Daten mal mit aufgenommen. Welche FW im Original mal drauf war
sollte keine Rolle spielen.
Ein komplettes Backup vom Protected Bereich und vom Config Bereich
findest du hier in diesem Thread auch irgendwo. Das hatte Hayo mal
hochgeladen.
Welche Kanäle betroffen sind kann man natürlich hinzufügen. Ich hab es
bei mir auf allen Kanälen probiert und mit Hayo's FW ist das in Ordnung.
Gruß, branadic
Hallo branadic,
bei meinem W2012A mit HW 8C7.0F ensteht dieses Problem mit
Hayos Betas auch nicht (beide Kanäle o.k.). Original war die
FW 1.4 drauf, falls da jemand Statistik führen möchte.
Gruß, Guido
ja wir führen Statistik-s.o.
und weil es mit Fotos gleich viel offensichtlicher ist, anbei meine
Version.
Bei wem tritt das im Foto gezeigte/ beschriebene Problem mit den Probes
noch auf?
Gruß, brunowe
>Welche FW im Original mal drauf war sollte keine Rolle spielen.
Eben da bin ich mir nicht sicher. Es gab ja auch Probleme mit der ersten
Serie und der Firmware der A-Serie. Da gingen die Drehknöpfe nicht mehr.
Vielleicht gabs ja zwischenzeitlich wieder ein kleines Update im FPGA.
Und der neue Config-Bereich, den ich mir mit den Update auf 1.4
aufgespielt habe, bringt mein Oszilloskop durcheinander. Wäre doch auch
ein Grund, warum die 1.4 nie im Internet veröffentlicht wurde.
Hi branadic,
ich hoffe es ist ok, dass ich ebenfalls nicht maile sondern hier poste.
Ich kann gleich beide Varianten anbieten. Übrigens für alle die auch
testen wollen aber den Trigger nicht hinkriegen - bei mir hat der
Trigger nur gegriffen wenn ich auf Normal Mode geschaltet hab.
- W2022A / 8C7.0L gekauft 10.2008 mit FW1.3 getestet mit 1.2.BF.0.69
Kanal 1 - Flanke völlig vermurkst
Kanal 2 - Flanke ok
- W2014A / 8C7.0L gekauft 03.2009 mit FW1.4 getested mit 1.2.BF.0.70
Kanal 1 - 4 Flanke ok
Foto spar ich mir, da es im Fall 1 genauso aussieht wie auf den hier
veröffentlichten. Meinen Nickname kennst Du ja ;-)
Hayo
Es ist definitiv irgendwann in der Modellreihe einmal etwas an der ADC
Reihenfolge vertauscht worden. wer sich da noch dran erinnern kann- das
von Stefan beschriebene Problem hatte ich auch. Bei mir kam es
folgendermaßen dazu: Ich hab mir bei meinem W2022A mit 8C7.0E den config
Flash.- Bereich zerlegt und dann eine config von Hayo (welche wohl
ursprünglich von Markus stammt) drauf gespielt. Erst als ich mein
eigenes Flash-config wieder drauf hatte, war alles wieder ok.
Bei den Flanken- Messungen ist uns aufgefallen das es gravierende
Unterschiede zwischen den einzelnen Probes im x1 Bereich gibt. Die
Anstiegszeit des Cal. Signal unterscheidet sich damit tw. gewaltig von
Probe zu Probe (wohlgemerkt im x1- Bereich). Deshalb hier nochmals der
Tip, wenn's um Signale über 10MHz geht, oder um die Messung von
Anstiegszeiten- dann unbedingt im x10 messen.
gruß, brunowe
Hallo
Habe jetzt auch mal probiert.
Zuerst waren alle Signale nicht gut.
Dann öfters. Calibrate ADC /DCA gemacht.
Dann Flanke gemessen.. Flanken waren nicht sehr schön..
(Was ist das eigentlich für eine komische 3mm Buchse für die Probe..?)
Habe dann den Taskopf mit den zwei CO.Trimmer (neben CNC-Buchse)
eingestellt.
Da kriegt man dann die Flanke so hin, dass dieser Spike nur noch ca.
alle 3-4 sek aufblitzt. (Bei allen Kanälen komme ich da so hin)
Wenn der Tastkopf schlecht einstellt ist, werden genau diese Spikes
gößer.
Also dürfte es sich da um Störsignale von Außen handeln?!
Es mach auch schon was aus, wenn man die Masseleitung beim Tastkopf
anschließt und neben der Probe-Buchse, auf Masse legt!
l.G Roberto ( W2024A; HW.:8C7.0L ; FW.: 0.66)
>Ich hab mir bei meinem W2022A mit 8C7.0E den config>Flash.- Bereich zerlegt und dann eine config von Hayo (welche wohl>ursprünglich von Markus stammt) drauf gespielt. Erst als ich mein>eigenes Flash-config wieder drauf hatte, war alles wieder ok.
@Bruno
Genau so wird es bei mir auch passiert sein. Beim sichern gab es bei mir
allerdings ein Problem und die Datei ist futsch. Ich hab mal deine
W2000.flash von GoogleGroups probiert (V1-10-03). Hat aber nichts
geholfen. Hast du zufällig noch eine andere?
Nachdem das Problem jetzt ja wohl eher nur bei mir liegt, will ich euch
nicht weiter mit dem Testen von meiner Firmware nerven. Trotzdem Danke
für alle Rückmeldungen. Notfalls muss ich das bei mir halt irgendwie mit
einbauen einbauen ;-)
Muss keiner hier demnächst eine Diplomarbeit schreiben und sucht noch
ein Thema? Wie wärs mit "Neuentwicklung der FPGA-Software für W2000" g
Gruß,
Stefan
Hallo,
Damit unseren Programmierern die Arbeit nicht aus geht...
Es gibt unter:
http://apps.sourceforge.net/trac/welecw2000a/wiki/FWwishlist
eine Wunschliste für SW Erweiterungen.
Im Rahmen der Flanken- Messung ist mir aufgefallen wie praktisch die an
jedem analogen Oszilloskop vorhandene variable Verstärkung ist. Um die
Höhe eines Sprungsignals exakt auf 5 Div einstellen zu können, und damit
leichter die 10%-90% risetime ablesen zu können, ist so eine Streckung
in der y-Achse sehr praktisch.
Das Ganze ist in SW bestimmt mit mittleren Aufwand machbar. Allerdings
muss ein neuer Menüeintrag erzeugt und bei Anwendung der nicht
normierten Verstärkung klar darauf hingewiesen werden. Vielleicht fasst
sich ja mal ein Berufener ein Herz?
Gruß, brunowe
Und nochmal ich ;-)
Mir ist gerade noch aufgefallen, dass Hayo und ich die selbe
Hardware-Revision haben. Das ist schon komisch, vorallem weil Hayos
Geräte unterschoedlich alt sind und scheinbar viele verschiedene
Revisionen gibt. Ich gehe davon aus, dass wir beide die selbe Sicherung
verwendet haben (die hier im Forum irgendwo liegt.) Da wird wohl die
Revision mit abgespeichert sein. Also auch nur bedingt aussagekräftig.
Einspruch,
ich habe mir auch mal meine FW zerschossen. Hatte seinerzeit mal meine
Sicherung meines W2014A hier eingestellt und diese hat Hayo, dem Chaos
auf dem eigenen PC sein dank, mir wieder zur Verfügung gestellt. Diese
habe ich bei mir auch wieder eingespielt. Demnach müsste ich die gleiche
Hardware-Revision haben. Hab ich aber nicht.
Gruß, branadic
Hi, die Hardwareversion wird nicht aus dem Flash geladen sondern aus dem
FPGA. Es gibt eine eigene Funktion dafür Read_Version().
Wie viele gibt es denn jetzt mit vermurkster Flanke außer Stefan und
mir?
Hayo
@Stefan
Lass mir doch mal Deine Korrektur zukommen, eventuell kann ich eine
Funktion einbauen die über einen Testschalter die Geräteversion (mit
vermurkster Flanke oder ohne) ins Flash schreibt und dann die Korrektur
aktiviert oder nicht. Dann haben wir da auch wieder Gleichstand.
Hayo
Ehe man weiß, wie es zusammenhängt und was der Grund ist, ist so ein
"Ausgleich" für einen Fehler keine gute Idee. Das verleitet dazu, die
Ursache nicht weiterzusuchen.
/Hannes
@Bruno
Die Idee mit der variablen Verstärkung ist nicht schlecht, die fand ich
an meinem analogen Oszi auch ganz praktisch. Muß mal sehen wo ich das
ich die Prioliste einsortiere...
Hayo
@Hannes
Ich denke Stefan ist an der Sache dran. Wenn er da nähere Erkenntnisse
hat können wir weitere Maßnahmen einleiten. Zudem scheint mir die
Ursache soweit ich das verstanden habe zu sein, dass die FPGA-Logik die
ADC-Daten in der falschen Reihenfolge einsortiert, oder?
Hayo
Mein Einwand war eher genereller Natur. Ich hatte das nicht so
verstanden, als wenn schon Einigkeit darüber bestünde, was der Grund für
das Problem mit der verdrehten Auslesereihenfolge der ADC ist bzw. woran
man es festmachen kann, ob es besteht oder nicht. Aber vllt hab ich da
nur was überlesen.
Lass dir mal von mir nicht reinreden. :D
/Hannes
So,
Bruno hat mir sein Backup zugeschickt. Mit dem sind die Flanken jetzt
wieder "schön" ;-)
Übrigens hab ich jetzt mit dem Config die Hardware-Revision 8C7.0E
(vorher L) und, soweit ich mich erinnern kann, wieder eine andere
SerienNr.
Muss also doch letztendlich irgendwo im Flash stehen.
Gruß,
Stefan
@Stefan
- die Hardwareversion wird nicht aus dem Flash gelesen, kann man sich im
Coding ansehen, die wird durch einen Zugriff auf das PIO-Interface
ermittelt.
- Die Seriennummer wird aus dem Flash gelesen
- hab ich das richtig verstanden, das Du nur durch das Einspielen eines
anderen Flashdumps das Gezackere wegbekommen hast??? Dann würde ich
den Dump auch gern mal ausprobieren.
Ich war der Meinung ich hätte in beiden Geräten den gleichen Dump
eingespielt, muß ich mal checken wenn ich zuhause bin.
Hayo
Hallo,
da fehlt uns noch Einiges am Verständnis. Dass der Config-Bereich
mir die Buttomplane versaut hat ist ja leicht einzusehen. Aber dass
auch die Fehler bei der Invertierung hieraus resultierten?
Ich denke, die (und andere) werde ich bald wieder sehen, wenn ich
READOUTADC_ALL in C teste. :-)
Gruß, Guido
>die Hardwareversion wird nicht aus dem Flash gelesen, kann man sich im> Coding ansehen, die wird durch einen Zugriff auf das PIO-Interface> ermittelt.
Glaube ich dir ja auch sofort. Nur der FPGA kann sie ja auch wieder aus
dem Flash lesen. Sie hat sich bei mir halt definitiv geändert nach einem
kompletten Neubeschreiben mit einem anderen Backup.
>Ich war der Meinung ich hätte in beiden Geräten den gleichen Dump>eingespielt, muß ich mal checken wenn ich zuhause bin.
Kann durchaus sein. Wenn das eine etwas älter ist (so wie meines),
scheint es mit nen Einstellungen eines neueren Config-Bereiches Probleme
zu geben.
Vielleicht gibt hier ein Diff des Config-Bereichs genauer etwas
Aufschluss. Außerdem kann ich mal probieren, meinen FPGA temporär zu
updaten und mit einem 1.4er Config-Bereich zu betreiben.
Wenn also jemand sowiso schon ein Backup von seinem FPGA zu Hause
rumfliegen hat, weil er mit slogs Software experimientiert hat UND bei
ihm ab Werk die 1.4er Firmware drauf war, würde ich mich über die Datei
sehr freuen ;-)
Gruß,
Stefan
Ich bin gerade dabei für den Rollmode/Shiftmode das Timing und die
Refreshrate genau zu kalibrieren.
Dabei mußte ich feststellen, dass das Timing für die 500mS TB so stark
von der Zeichenroutine beeinfußt wird, dass die Funktion hier nicht
sinnvoll einsetzbar ist. In der nächsten Version werde ich also auf TB
1S zurückrudern mit der dann der USTB-Modus automatisch einsetzt. Die
500mS TB wird dann wieder konventionell ausgegeben.
Gruß Hayo
@Stefan
Das wäre jetzt mein nächster Ansatz gewesen, nämlich den FPGA auf einen
aktuellen Stand zu bringen um dadurch das Gezackere wegzukriegen.
Allerdings habe ich mich mit der FPGA-Thematik noch nicht weiter
auseinandergesetzt, so dass ich mich da erst einarbeiten müßte um zu
wissen wie man das macht und welche Tools man dazu braucht. Wenn Du da
weiter bist gib doch mal eine Kurzanleitung raus.
Hayo
@ Stefan:
Wenn ich's schaffe, werde ich am Wochenende meinen FPGA sichern. Hab ein
2024A, die Firmware war wohl 1.4...
Bin dieses Wochenende leider ausgebucht (heute Hochzeit, morgen Umzug),
wird wohl erst morgen Nacht was. Hatte beim letzten Öffnen vergessen,
den kleinen Widerstand für das JTAG zu brücken :-/
Außerdem wollte ich gerne noch den Lüfter tauschen. Der nervt mich
langsam...
Michel
Hallo,
eine Anleitung über das dumpen/ flashen des FPGA- Config Flash findet
ihr hier:
http://apps.sourceforge.net/trac/welecw2000a/wiki/FPGAConfigFlash
Die Sicherungsdatei eines W2022a EPCS16 findet ihr bei den Google
Groups. Die Datei heißt: EPCS16_W2022A.JIC.rar
gruß, brunowe
@Michael
Super. Mach dir keinen Stress. Bin vor Montag auch nicht mehr zu Hause.
@Bruno
Die Tastkopf-Geschichte habe ich nicht vergessen. Werde ich mal testen.
@ Hayo: Ich bin dann mal soweit mit den 4 C-Funktionen. Habe den
Eindruck, der ADC-Abgleich ist vermurkst, aber vllt. siehst du
das viel schneller als ich. Auch der 5 ns/div Bereich scheint
noch etwas Nacharbeit zu benötigen.
Viel Spaß damit, Guido
Hallo Guido und Hayo,
PREPARE_READADC ist dann überflüssig. Die hat der Entwickler nur
gebraucht, weil die Übergabe von mehr als 8? (bin mir nicht ganz sicher)
Parametern in ASM nicht ganz trivial ist. Da hat er die Übergabe einfach
auf zwei Funktionen aufgeteilt. Einfach löschen,weil du die
Korrekturwerte ja direkt aus dem Array ausliest.
Gruß,
Stefan
Hi,
komme heute nicht mehr dazu, hab mir das aber mal runtergeladen. guck
ich mir morgen mal an. Wenn ich soweit komme bastel ich das in die
Wochend-Beta mit rein.
Gruß Hayo
Hallo Hayo,
keine Hektik, da sind bestimmt noch genügend Fehler drin. Bei
hohen Frequenzen sieht es ganz schlimm aus.
Was anderes: wo finde ich floatstr_t.h?
Gruß, Guido
Moin, moin,
danke Kurt, werd ich mal ausprobieren. Inzwischen habe ich ausgiebig mit
diversen Config-Files die ich noch rumliegen hatte experimentiert, alles
am W2022A, mit folgendem Ergebnis:
- Erstmal muß ich Stefan Recht geben - die Hardwareversion wird
offensichtlich über Umwege doch aus dem Flash gelesen. Bei mir wechselte
die Hardwareversion mit jedem Config-Dump den ich eingespielt hab.
- 8C7.0L Flanke vermurkst (1.2.BF.0.70)
- 8C7.00 Flanke vermurkst (1.2.BF.0.70)
- 8C7.0G Flanke ok!! (1.2.BF.0.70) (stammte von einem Gerät das
ebenfalls wie meins etwa 10.2008
ausgeliefert wurde)
- 8C7.00 Flanke vermurkst (aus einem W2014A als Komplettdump mit FW1.3)
Was mir dabei völlig unklar ist: Wie kann der Config-Bereich das
Auslesen des ADC beeinflussen??? Greift die Flashkonfiguration in den
FPGA-Ablauf mit ein?? Ist das evtl. auch der Schlüssel für die
Beseitigung der Schwingungen und Störungen die ja im anderen VHDL-Design
nicht auftreten?
Fragen über Fragen...
Hayo
Hallo,
Wir haben hier ja schon eine Aufstellung der Flanken-integrität und der
EPCS16-Checksum einiger Geräte gesammelt:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
Da sich die Checksum der dort aufgeführten W2022a und W2012a nicht
unterscheidet, ist es eigentl. auch nicht möglich das dort irgendwelche
gerätespezifische Daten (Seriennr., HW-Version usw.) abgespeichert ist.
Es wäre hilfreich wenn noch mehr Leute ihre Checksum dort eintragen,
vielleicht hilft uns das die Zusammenhänge besser zu verstehen.
Der FPGA liest auch Daten aus dem Config Flash des AM29LV. Ohne den VHDL
Code wird es allerdings sehr schwierig werden das genau zu ergründen.
gruß, brunowe
Hallo Roberto,
Die Checksum wird von Quartus bzw. dem standalone programmer automatisch
beim erstellen des EPCS16 Backup erzeugt.
Wie dieses dumping funktioniert ist unter:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
ausführlich beschrieben.
Man benötigt dazu aber etwas Vorarbeit, man muss im Prinzip erst einmal
die Toolchain für VHDL installieren. Also Quartus bzw. den standalone
programmer, den USB Blaster driver für Cypress FX1 oder man benötigt den
Altera USB Blaster. wie das genau geht ist ebenfalls unter SF
beschrieben.
Um die Checksum eintragen zu können benötigt man einen SF- Account.
Dann einfach bei dieser Seite:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
unten links auf editieren und eigene Werte eintragen.
Wer keinen SF-Account hat darf seine Checksum natürlich auch gern hier
posten.
Gruß, brunowe
Hi,
wo bekomme ich denn den originalen USB-Treiber für das Scope her? Bei
mir findet Windows (XP SP3) den Treiber nicht ('Unbekanntes Gerät'). Ich
dachte, der ist in der Winpows Anwendung integriert - war aber leider
nix. Oder läuft die nur mit dem Seriellen Port (nicht der Updater)?
Auch ein Einbinden des USB-Blaster Treibers funktionierte nicht :-(
Nu' hab' ich extra die Brücke am JTAG-Interface gelötet und kann da sgar
nicht nutzen... :-(
Michel
Ach ja, noch 'ne Frage zum Triggermode:
Zum Messen der Anstiegsflanke für das Userinstruments - Form habe ich
gemerkt. dass der Trigger im Auto-Modus nur funktioniert, wenn
mindestens 1,5 Perioden auf den Schirm passen (ca.). Im Normal-Modus
ließ sich die Flanke dann korrekt messen. Allerdings blieb die Anzeige
stehen (eingefroren!), wenn ich das Signal vom Probe genommen hatte. Das
ist doch sicherlich nicht gewollt, oder?
...und zur Firmware:
Wenn ich die gesamten Abgleiche gespeichert habe, bleiben die beim
Firmwareupdate erhalten oder muß ich die jedesmal wieder neu
durchführen? vom Gefühl her bleiben sie aber ich lass' mich gerne
belehren.
Ansonsten habe ich das Gefühl, dass man mit dem Teil mittlerweile
richtig arbeiten kann. War schon kurz davor es wieder zu verkaufen und
ein Rigol oder so zu ordern.
Mit dem Max038 wollte ich mir einen simplen Funktionsgenerator aufbauen
und ein wenig rumspielen. In einem Youtube Video hatte ich gesehen, dass
die Amplitude des gemessenen Signals bei steigender Frequenz immer
kleiner dargestellt wurde (verglichen mit einem Tek). Ist das wirklich
so?
Michel
Dass die Flanke im Normal-Mode stehen bleibt, ist normal. Dabei wird der
Schirm nur dann neu geschrieben, wenn das Triggerereignis auch wirklich
eingetritt.
Im Auto-Mode dagegen wird zuneaechst aktualisiert, wenn das
Triggerereignis eintritt. Allerdings auch dann, wenn es NICHT
eingetreten ist, aber eine gewisse Zeit vergangen ist (ca 0.3s).
Den Eindruck, dass Auto ein bissl spinnt, hab ich auch :).
Gruessle
Michael schrieb:
In einem Youtube Video hatte ich gesehen, dass
die Amplitude des gemessenen Signals bei steigender Frequenz immer
kleiner dargestellt wurde (verglichen mit einem Tek). Ist das wirklich
so?
Nein, das Video habe ich gefaked, weil ich Langeweile hatte... :D
Selbstverständlich ist das so, ansonsten hätten wir das nicht
eingestellt. Wobei man sagen muss, dass der Tastkopf auf 1:1 stand und
nicht auf 10:1.
@ Hayo
Ich habe nach wie vor ein gewaltiges Problem mit meinem Kanal 3. Bei
Zeitbasen >5µs hab ich gewaltige Spikes auf dem Kanal. Bei Zeitbasen
kleiner gleich 5µs sind diese wie von Geisterhand verschwunden.
Ich glaube weniger, dass das auf ein Problem der Hardware zurückzuführen
ist, als vielmehr auf ein Problem in der VHDL oder FW. Möglicherweise
ist es die besagte Assembler Routine?
Was ich mir sehr wünschen würde ist, wenn unter dem Menü-Punkt "Utility"
einer der frei gewordenen Softbuttons die Funktion bekommen würde das
Probe-Signal an- bzw. abzuschalten. Die Frage ist, wie tiefgreifend die
Abschaltung machbar ist. Eigentlich müsste man einen direkten Zugriff
auf die Signalerzeugung im FPGA haben. Hintergrund ist es
herauszufinden, inwieweit dieses Probesignal Störungen auf den Kanälen
produziert.
Lässt sich hier etwas derartiges realisieren?
Beste Grüße, branadic
branadic schrieb:
> Nein, das Video habe ich gefaked, weil ich Langeweile hatte... :D>Wobei man sagen muss, dass der Tastkopf auf 1:1 stand und> nicht auf 10:1.
Also doch gefaked ;-)
Hallo Hayo,
ich bin gerade noch ein wenig am Testen mit der aktuellen FW. Dabei sind
mir noch ein paar Dinge aufgefallen.
Mein Messaufbau besteht aus einem DDS-10 Board. Auf Kanal 1 hab ich ein
50-Ohm-Kabel mit 50-Ohm Abschlusswiderstand. Auf Kanal 2 einen Tastkopf
eingestellt auf 1:1 und auf Kanal 4 einen Tastkopf 10:1.
Alle drei Signale hängen an der gleichen Signalquelle. Wenn man jetzt
auf einen der Kanäle triggert sollte man meinen, dass die Flanken
halbwegs sauber übereinander liegen. Dem ist aber nicht so.
Durch den Spannungsteiler im Tastkopf von 10:1 sind mir wieder diese
Schwingungen aufgefallen. Diese liegen in der Tat nicht auf dem internen
Probesignal, sondern werden irgendwo nach dem Tastkopf erzeugt.
Im konkreten Fall mit einem Testsignal von 1kHZ Rechteck kann ich einen
Sinus-Anteil auf meinem Rechtecksignlal von etwa 100MHz feststellen, der
zusätzlich noch einmal mit einem Sinus von etwa 6,66MHz
amplituden-moduliert ist.
Weiterhin ist mir aufgefallen, dass der Trigger bei der
Spannungsbereichumstellung nicht nachgeführt wird. Soll heißen, trigger
ich bei 200mV/div auf dem Wert 100mV, dann sollte das auch noch so sein,
wenn ich den Bereich auf eine höhere oder niedrigere Spannungsbasis
umstellen. Tatsächlich bleibt der Triggercursor aber auf dem Bildschirm
an exakt der gleichen Stelle stehen. Das wiederum heißt, stelle ich den
Spannungsbereich um, Trigger ich plötzlich auf ein anderes Event. Das
ist natürlich nicht korrekt.
Der manuelle Trigger funktioniert nur bis zur Spannungsbasis 10ns/div,
bei 5ns/div leider nicht mehr.
Weiterhin habe ich mit einem 1kHz-Dreiecksignal getestet. Mir ist
aufgefallen, dass das Gerät zum Teil echten Quark anzeigt, wenn ich die
Zeitbasis verstelle. Erst wenn ich dann die Triggerquelle abziehe und
erneut anklemme wird das Signal auf der neuen Zeitbasis wieder richtig
angezeigt. Auch funktioniert hier der Trigger irgendwie nicht richtig??
Mit Dreiecksignalen überfordert?
Vielleicht aber nicht nur Negatives. Ganz gut finde ich, dass der
Trigger-Level für jeden Kanal einzeln einstellbar ist.
Gruß, branadic
Auch auf die Gefahr hin das das hier ein Monolog wird. Mir ist noch
etwas grundsätzlich bei der Menu-Darstellung aufgefallen.
Bei Kanal 3 passiert es mir regelmäßig, dass die Kanalzahl in der oberen
Menuleiste nicht mehr zu lesen ist, sonder schwarz ist. Drücke ich dann
Default Setup, passt die Darstellung wieder und Kanal 3 ist als Zahl
auch wieder lesbar. Weiterhin ist mir aufgefallen, dass die Zahlen im
oberen Menu zum Teil ein blaues Shining haben. Kann das jemand
bestätigen? Irgendwie scheinen die Planes da auch nicht korrekt zu sein.
Gruß, branadic
Hallo branadic,
dann störe ich mal deinen Monolog etwas. Vermutlich muss sich Hayo erst
erholen, von meinen C-Funktionen. Wenn er aus dem Lachen wieder raus
ist, wird er sich melden.
Mit den Planes gibt es in der Tat größere Probleme, die könnten auch
vom FPGA-Design kommen (Adresslinien vertauscht?). Wenn ich etwas
mehr Zeit habe schau ich mir das noch mal an.
In dem Bereich um 5 µV/div passieren noch mehr Merkwürdigkeiten.
Z.B. zeigt der Browsebalken hier nur noch etwas mehr als ein Fenster
an und weiter kann auch nicht gescrollt werden (es werden aber
immer noch 16 kB pro Kanal verarbeitet). Vllt. finden wir das mit
den C-Routinen, da kann man mal schnell was ausprobieren.
Die Probleme mit dem Dreiecksignal kann ich nicht nachvollziehen.
Ich habe zwar nur 2 Kanäle aber mit denen klappts (Triggerung o.k.,
keine Mist wird dargestellt). Das mit den Schwingungen muss ich
mal probieren. Ist das überlagerte 6,88 MHz-Signal nicht etwa ein
Alias?
Gruß, Guido
@ branadic
Das mit den falsch dargestellten Kanalzeilen in der Titelzeile kann ich
bestätigen, speziell bei Kanal 3.
Da ich noch relativ wenig Messequipment habe, sind die Tests, die Ihr so
durchführt für mich schwierig nachstellbar.
@ Kurt
Ich dachte, dass in der PC-Anwendung von Wittig ein USB-Treiber
enthalten ist. Als ich das Gerät angeschlossen hatte, zeigte mir Windows
erst ein neues Gerät an und sogar die Meldung, dass ich es jetzt
benutzen könnte.
Nach ein paar Sekunden kam aber die Meldung, dass das Gerät nicht
korrekt funktioniert und jetzt ein Treiber von Nöten sei. Das alles noch
VOR der Installation des USB Blaster.
Teufel auch: gerade habe ich's nochmal getestet und jetzt zeigt der
Rechner keine Probleme an und die Anwendung scheint das Teil auch
steuern zu können, nur ein Signal sehe ich nicht auf dem Schirm (der
Anwendung). Ich hab' nix gemacht, war nur mit'm Hund zwischendurch
spazieren ;-)
Ok, jetzt werde ich mich weiterhangeln bis zu den FPGAs...
Michel
Hi,
war heute unterwegs - daher keine Rückmeldung von mir. Dafür aber schon
eine Ankündigung: Es gibt gleich das nächste Wochenendrelease u.a. mit
Guidos C-Routinen.
@Branadic
> Ich habe nach wie vor ein gewaltiges Problem mit meinem Kanal 3. Bei> Zeitbasen >5µs hab ich gewaltige Spikes auf dem Kanal. Bei Zeitbasen> kleiner gleich 5µs sind diese wie von Geisterhand verschwunden.
Konnte ich bei mir nicht nachvollziehen. Bei mir ist auf allen Kanälen
das ganz normale Rauschen zu sehen. Nur auf Kanal 4 habe ich bei
warmgelaufenem Gerät starke Störungen.
> Was ich mir sehr wünschen würde ist, wenn unter dem Menü-Punkt "Utility"> einer der frei gewordenen Softbuttons die Funktion bekommen würde das> Probe-Signal an- bzw. abzuschalten.
Ich weiß leider nicht ob eine Abschaltung via Software möglich ist, oder
ob der Signalgenerator einfach in Hardware realisiert ist. Wenn es dazu
nähere Infos gibt baue ich das gerne mit ein.
> Alle drei Signale hängen an der gleichen Signalquelle. Wenn man jetzt> auf einen der Kanäle triggert sollte man meinen, dass die Flanken> halbwegs sauber übereinander liegen. Dem ist aber nicht so.
Muß ich mal prüfen. Einen derartigen Testaufbau hatte ich bislang noch
nicht - interessant!
> Weiterhin ist mir aufgefallen, dass der Trigger bei der> Spannungsbereichumstellung nicht nachgeführt wird.
Da gebe ich Dir recht. Das ist ein weiterer Punkt der
verbesserungswürdig ist. Evtl. ein Fall für die Wishlist.
> Auch funktioniert hier der Trigger irgendwie nicht richtig??> Mit Dreiecksignalen überfordert?
Hab bislang nur mit Sinus und Rechteck getestet - muß ich mal prüfen
> Bei Kanal 3 passiert es mir regelmäßig, dass die Kanalzahl in der oberen> Menuleiste nicht mehr zu lesen ist, sonder schwarz ist.
Ja das ist bei mir auch so, allerdings auch bei der FW1.4 - da scheint
ein Fehler zu sein der sich durch alle FW-Versionen zieht. Da mir das
aber nicht so tragisch erschien hab ich das erstmal in der Prioliste
weiter hinten einsortiert.
> Weiterhin ist mir aufgefallen, dass die Zahlen im> oberen Menu zum Teil ein blaues Shining haben.
Bei mir nicht
@Guido
> Z.B. zeigt der Browsebalken hier nur noch etwas mehr als ein Fenster> an und weiter kann auch nicht gescrollt werden (es werden aber> immer noch 16 kB pro Kanal verarbeitet).
Ein Blick in die Timebasetabelle meiner Programming Maps bringt die
Lösung: Die Zeitbasen 1µS/2µS/5µS werden nicht über eine entsprechende
reale Abtastrate erzeugt, sondern (warum auch immer) durch einen
entsprechenden Faktor von 20 bzw. 25. Da bleiben dann nur noch 819 bzw.
655 Werte von den 16K übrig - da ist dann nicht mehr viel mit browsen.
@Michael
Die USB-Übertragung zum PC sollte ohne Treiber funktionieren, ist aber
in der Beta FW völlig ungetestet - heißt ich hab es noch nie
ausprobiert.
Hayo
Bevor ich in die Wanne steige hier die 0.71 beta.
Wesentliche Änderungen:
- Der USTB-Bereich fängt jetzt ab 1S/Div an, darunter ist kein stabiles
Timing machbar
- Guidos C-Routinen sind implementiert und können per Testschalter 1
(shift + S) an bzw. ausgeschaltet werden. Defaultmäßig sind die
Assemblerroutinen aktiv. Leider sind die C-Routinen noch deutlich
langsamer als die Assemblerroutinen und haben auch noch kleinere
Abweichungen in der Null-Lage.
Hayo
Oje was ist denn da geschehen?
Neue 0.71 Version -mit bzw. auch ohne C-Routine.
Diese hässlichen Spikes kommen mir doch irgendwie bekannt vor.
Es gibt übrigens gravierende Unterschiede in der Darstellung mit und
ohne C-Routinen bei höheren Freq. ... aber richtig gut sieht keine aus-
nicht nur wegen der Spikes.
Gruß, brunowe
P.S.: morgen teste ich ausführlich
Hallo Bruno We,
in den C-Routinen sind ganz offensichtlich noch Fehler. Mit
höheren Frequenzen sehe ich nur noch Murks. Keine Ahnung was
schuld ist, aber das werden wir schon noch rauskriegen. Z.B.
stimmt bei mir der ADC-Abgleich nicht mehr ...
Gruß, Guido
Uuups,
nach einem kurzen Test habe ich die .69 Version wieder eingespielt. Die
Rauschpegel der Kanäle 2 und 3 waren erheblich höher als bei den letzten
Versionen. Die 5er Bereiche waren ja schon fast glatt, jetzt ist bei
Kanal 2 der Rauschteppich ca. doppelt so hoch wie bei 1 und bei Kanal 3
nochmal höher (etwa 4x wie bei Kanal 1). In den 1er und 2er Bereichen
ist das Rauschen allgemein höher geworden (mein Empfinden), die 2er
Bereiche fast nicht nutzbar... :-/ Schade
Michel
Nachtrag:
also mit der 0.69 Version sind diese Spikes definitiv nicht da.
Das mit dem Rauschpegel kann ich so eigentlich nicht bestätigen- der
sieht bei mir nur deshalb höher aus weil ich definitiv den einen
Ausreißer ADC habe (auf beiden Ch).
Aber irgendwo ist da noch grob der Hund drin...
Was aber interessant ist- die C-Routine hat massiven Einfluß auf das
festgestellte oszillieren bei höheren Frequenzen. Vielleicht geht ja
doch was?
Ich seh schon... das Projekt wird immer umfangreicher... und
interessanter.
Gruß, brunowe
Als Anhang noch ein kurzer, 500kB großer Videoclip, der das Rauschen mit
Hayo 0.71 und Abschirmung wie im HW Thread beschrieben, zeigt.
>Was aber interessant ist- die C-Routine hat massiven Einfluß auf das>festgestellte oszillieren bei höheren Frequenzen. Vielleicht geht ja>doch was?
Genau meine Meinung. Ich habe versucht die Assembler-Routinen
1:1 in C zu übersetzen. Gut möglich, dass ich dabei Fehler
produziert habe. Das müssen wir noch prüfen, ich brauche dazu erst
etwas Abstand.
Falls aber logische Fehler im Programm stecken, lassen sich die
dann halt in C viel leichter erkennen.
Gruß, Guido
Hi,
kann mir vielleicht jemand mit dem ByteBlaster helfen? Ich bekomme immer
das USB HID angezeigt. Einmal kurz hatte ich ein NIOS mit Fragezeichen
im Gerätemanager aber das bekomme ich nicht mehr hin. Als Nicht PNP wir
der Altera ByteBlaster aufgelistet (versteckte/nicht sichtbare
Komponenten).
Installiert habe ich den Quartus II 9.0sp1 Programmer und der findet
logischerweise keine Programmierhardware...
Kann ich alles wieder in den Urzustand versetzen und von vorne beginnen?
Mit der Sourceforge-Anleitung bin ich nicht weitergekommen... :-/
Michel
Moin, moin,
die Störungen auf den Signalen im Assemblerbetrieb werden indirekt durch
die C-Routinen verusacht. Ich habe diese einfach per Fallunterscheidung
mit in die gleiche Subroutine gepackt. Die Assemblerroutinen arbeiten
mit dem PFX-Befehl, der allerdings je nach Ausgangszustand einiger
Register unterschiedliche Auswirkungen hat. Durch das zusätzliche Coding
in der Subroutine wird der Ablauf hier offensichtlich gestört. Das läßt
sich nur durch getrennte Routinen entkoppeln. Ich werde mal sehen, dass
ich heute oder morgen eine neue Version zur Verfügung stelle.
Hayo
Hallo,
>Die Assemblerroutinen arbeiten>mit dem PFX-Befehl, der allerdings je nach Ausgangszustand einiger>Register unterschiedliche Auswirkungen hat.
unwahrscheinlich.PFX als Immediate-Befehl ist unabhängig von
Registerinhalten. In manchen Funktionen wird C-switch mit asm
kombiniert, das könnte dann auch nicht funktionieren.
>die Störungen auf den Signalen im Assemblerbetrieb werden indirekt durch>die C-Routinen verusacht.
Durch eine leicht verändertes Timing? Ich kann mir langsam alles
vorstellen.
Gruß, Guido
Hallo,
Guido wrote:
>Ich kann mir langsam alles vorstellen.
Prima, dann sind wir ja schon zu Zweit.
Sind alle aktuellen Assembler -> C Umsetzungen in readadc.cpp enthalten?
So umfangreich sind diese Funktionen gar nicht (hätte ich mir schlimmer
vorgestellt) Will damit sagen- so auf die Schnelle sehe ich keinen Grund
wieso der C-Code solche massiven Änderungen hervorruft- ADC Fehlabgleich
etc...
Bin gespannt was die nächsten Tage diesbezüglich zum Vorschein bringen.
Gruß, brunowe
@Guido
wie ich schon sagte - alle Assemblerroutinen arbeiten mit dem PFX-Befehl
und dieser ist, wie Du ja auch schon sagtest, registerabhängig.
Daher werde ich das in separate Routinen verpacken, dann kann ich auch
gleich sinnvollere Namen vergeben.
Hayo
@ Hayo,
PFX ist wie ich schon sagte unabhängig von Registerwerten. ;-)
@ Bruno We: Ja, schön kompakt ist es in C schon, das war der
Grund für die Mühe. Fehler können leicht entstehen, wenn ich
den Assemblercode falsch interpretiert habe. So war ich mir
z.B. ganz sicher, dass für Timebase >= 7 nur 1024 Longwords
bearbeitet werden. Dann wurde dort nur ein Viertel des
Schirms aktualisiert und ich habe nicht mehr gefunden, wie
ich auf die Idee gekommen bin.
Die Verzögerungen sind zum Teil leicht zu erklären: Schleifen
statt aneinandergehängten Code. Wenn es soweit ist, kann das
leicht optimiert oder sogar wieder in Assembler umgesetzt
werden.
Gruß, Guido
@ Hayo. Was mir gerade noch einfällt: Wir könnten doch die
Variablen in meinen Funktionen alle als static deklarieren.
Das könnte schon etwas beschleunigen.
Gruß, Guido
@Guido
Hab nochmal die PFX Sache nachgeschlagen, da hatte ich wohl was in den
falschen Hals bekommen. Aber irgendwie beeinflußt das C-Coding den
Assemblerablauf.
Und zwar kann man die Auswirkungen des C-Codings ganz gut sehen wenn man
in READADC_ALL2() (Zeile 18880) die Reihenfolge von C-Coding und
Assembler ändert. Ich habe nämlich das C-Coding hinter die
Assemblerroutine gepackt weil sonst der Nullpunkt des Signals komplett
um die halbe Gridhöhe verschoben wird.
Kannst ja mal ausprobieren. Evtl. kann man das Ganze auch dadurch
stabilisieren, dass man in den anderen Funktionen ebenfalls die
Reihenfolge ändert.
Gruß Hayo
@ Hayo: Tja, wenn wir verstehen, was da passiert, sind wir wohl
schon ein gutes Stück weiter. Ev. werden in READADC_ALL globale
Register verwendet, das werde ich mal anschauen.
Ich habe mal alle C-Variablen static deklariert und auch stat.
Kopien von DataArray1 verwendet. Das scheint etwas schneller zu
gehen, aber immer noch deutlich langsamer als der Assemblercode
(hoffentlich bilde ich mir das nicht nur ein).
Gruß, Guido
>Warum hast Du eigentlich die Funktion EXTRACTADCVAL() umgesetzt?
Fingerübungen, erstmal mit einer kurzen Funktion anfangen.
Gute Nachrichten: Die Störungen bei hohen Frequenzen stammen
aus READADC_ALL2. Das sollte die Fehlersuche erleichtern.
Gruß, Guido
So liebe Leute, nach dem Aufschrei der Empörung jetzt die überarbeitete
Version mit gekapselten C-Routinen, die Euch hoffentlich wieder milde
stimmt.
Die Umschaltung zur C-Routine geht wie gehabt via shift + S - allerdings
nur für Kanal 1.
Hayo
Hallo,
habe heute probiert den FPGA zu updaten. Leider ohne Erfolg,da das
Backup von Kurt von einem 4-Kanal-Gerät ist ich aber nur 2 habe :-( Muss
also noch warten, bis mir jemand ein passendes Backup schickt.
@Bruno
Das mit den Unterschieden der Tastköpfe kann ich nicht bestätigen.
Ich warte sehnsüchtig auf deine Abschirmanleitung ;-)
Momentan versuche ich die ganze ZPU-Geschichte bei mir zum laufen zu
bekommen. Das klingt interessant.
Gruß,
Stefan
Hi,
bei mir sind in der .72 FW die Kanäle 2 und 3 wieder besser geworden.
Danke Hayo ;-)
So'n Schönheitsfehler hab ich noch beim Grid gesehen:
Wenn man unter Display -> Grid das Grid auf 100% dreht (nur zur besseren
Sichtbarkeit), sieht man im unteren Rahmen so im mittleren Drittel ein
paar Unterbrechungen/schwarze Pixel. Hier scheint es auch noch Probleme
mit den verschiedenen Panes zu geben. Mit der Zeit füllen sich die
Löscher im Rahmen (die Unterbrechungen schließen sich)... Strange, Stört
allerdings nicht großartig, nur Kosmetik.
Dann werde ich jetzt mal weiter versuchen den ByteBlaster zum Laufen zu
bringen.
Gerade habe ich am PC den USB-Blaster installiert bekommen. Vielleicht
schaff' ich's ja gleich endlich auf meinem T41... :-/
Michel
Hallo,
anbei ein paar Fotos mit der aktuellen FW 0.72. Die Assembler- Routinen
laufen jetzt wieder so wie vor 0.71er Zeiten, die C-Routinen sind so
noch nicht zu gebrauchen- irgendwie überschreiben diese C-Routinen sogar
meine ADC- Kalibrierung so dass ich auch nach Umschalten auf Assembler
erstmal wieder kalibrieren muss. Noch sehr seltsam was da abgeht...
Hoffe meine Fotos helfen etwas bei der Klärung des Mysterium.
@Stefan: du versuchst gerade den FPGA zu updaten? was soll ich mir
darunter bitte vorstellen? Was für ein Backup brauchst du denn?
Abschirmanleitung- ich hab mir heute nochmal ein Stückchen Alu- Blech
besorgt, werde das morgen? mal ordentlich hinbiegen und dokumentieren-
es kann zumindest nix schaden.
Und... das mit den Tastköpfen sieht bei dir also nicht so aus?
du meinst diese (eins- zwei) zusätzlichen Schwingungen?
Du versuchst die ZPU- Geschichte zum Laufen zu bringen? Wo hängt's denn
genau? Du kannst dann auch gern von mir noch so 5-15 unveröffentlichte
(Test-) Versionen habe.
Gruß, brunowe
... irgendwie bin ich zu blöd für den ByteBlaster...
Wenn ich das Scope vom Rechner nehme (USB) und dann wieder verbinde,
meldet der Gerätemanager wieder ein unbekanntes Gerät :-/ Sehr
unbefriedigend diese USB-Geschichte :-(
Michel
Hallo,
dass mit den C-Routinen die ADC-Kalibrierung nicht mehr stimmt ist
klar, habe ich auch schon geschrieben. Dass sie aber diese
überschreiben? Ich muss mir die Speichermap nochmal anschauen. Die
Fehler zu finden wird durch die Grafik fast unmöglich gemacht. Wenn
ich auf 5 ns/div schalte erwarte ich ohne Vektoren 5 Pixel/div.
Angezeigt werden aber ca 25. Kommen die Fehler vllt. einfach daher?
Gruß, Guido
@Stefan:
was genau benötigst du für ein Backup?
Ich habe ein 2 Kanal 200 MHz Welec Oszi,
gekauft ca. 07/2008, original FW 1.3.
Leider bin ich erst jetz hier hinzugestoßen.
Wenn Du mir sagst, was Du genau brauchst, wär ich gerne bereit Dir
weiter zu helfen.
Gruß,
Michael
@Michael
>was genau benötigst du für ein Backup?
Ich bräuchte zum Testen ein Backup des FPGAs von einem 2-Kanal-Gerät mit
Original-Firmware 1.4. Aber trotzdem Danke für das Angebot.
@BrunoWe
>@Stefan: du versuchst gerade den FPGA zu updaten? was soll ich mir>darunter bitte vorstellen? Was für ein Backup brauchst du denn?
Ich würde ausprobieren, ob sich die Software des FPGAs von einem neueren
Gerät in ein älteres übertragen lässt. Evtl. sind ja Verbesserungen im
FPGA durchgeführt worden. Das es Unterschiede gibt, zeigt ja das Problem
mit dem nicht passenden Config-Bereich.
>Und... das mit den Tastköpfen sieht bei dir also nicht so aus?>du meinst diese (eins- zwei) zusätzlichen Schwingungen?
Nein, keine zusätzlichen Schwingungen im 10x-Bereich. Sind die beiden
zusätzlichen Einstellschrauben in den dicken Gästen auch zur Anpassung
des 10x-Bereichs an das Oszi? Hab ich sonst noch nirgens gesehen.
Vielleicht ist ja da was verdreht.
>Du versuchst die ZPU- Geschichte zum Laufen zu bringen? Wo hängt's denn>genau? Du kannst dann auch gern von mir noch so 5-15 unveröffentlichte>(Test-) Versionen habe.
Genau die Geschichte: Ich fass mal zusammen, wie ich es versuche:
- Kompilieren
- Mit dem Programmer den Ram updaten
- Oskar startet mit schwarzem Bildschirm
- Mit dem "In-Memory-..."-Tool die gerade erstellte "zpu" mit einem
Programm laden.
Bin ich soweit richtig?
Für die Zpu-Software brauche ich noch die Zpu-Toolchain. Da habe ich
gestern aufgehört. Gibts da keine einfache Zip-Datei oder so? Ich finde
die Dateien nur in einem Repository auf opencores.org
Verwendet zum Kompilieren habe ich die Dateien aus SourceForge.
Gruß,
Stefan
Hallo,
@Guido: Die von mir auf den Fotos
(http://www.mikrocontroller.net/attachment/52204/Hayo072.pdf) gezeigten
Fehler lassen sich selbstverständlich auch im 50ns- Bereich und auch mit
Vektordarstellung "off" nachvollziehen. Ein Fehler in der Interpolation
schließe ich deshalb eigentlich aus.
@Stefan: Das in den letzten 12 Monaten Verbesserungen im FPGA Design
durchgeführt wurden, halte ich eher für unwahrscheinlich. Deshalb denke
ich auch nicht, das du durch so ein Update viel gewinnst, aber man kann
es versuchen, da hast du natürlich recht.
Ehrlich gesagt ist mir nicht so ganz klar, wo es im Moment bei dir hängt
(bzgl. ZPU- Design).
1.) Schaffst du es ein vorkompiliertes SOF- File zu programmieren (via
Quartus Programmer)? Zu Testzwecken kannst du z.B. von den Google-Groups
das Hello_W2000_v0_1_4.zip ausprobieren.
2.) Kannst du das in SF abgelegte ZPU- Design erfolgreich kompilieren?
http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/fpga/zpu/quartus.tar.gz?view=tar
3.) Gehst du nach folgender Beschreibung vor:
http://apps.sourceforge.net/trac/welecw2000a/wiki/InSystemMemoryContentEditor
Derzeit ist das unter SF abgelegte Design nicht sonderlich interessant.
Viel besser ist es, wenn du dich aktiv am FPGA- Neuaufbau beteiligen
willst, dich mit der aktuellen, inoffiziellen Testversion zu
beschäftigen.
(Z.B. das, welches ich für das Youtupe Video:
http://www.youtube.com/watch?v=Ma7Yoz7AHhI verwendet habe.)
Wenn du Frage 1.) mit Ja beantworten konntest, dann sollten auch unsere
Testversionen laufen. Schreib mich einfach an, wenn du diese Version
haben willst, offiziell ins SF wollen wir es erst stellen, wenn noch ein
paar Fehler ausgemerzt sind.
Gruß, brunowe
Hallo BrunoWe,
also das HelloW2000... von slog läuft bei mir. Außerdem kann ich den
Code aus SF kompilieren. Also zweimal ja bei 1 und 2.
Danach ist mir nicht ganz klar, was ich machen muss. Ich laden die
kompilierte W2000.sof mit dem Programmer in den Ram. Das klappt auch.
Danach bleibt der Bildschirm schwarz.
Jetzt gehe ich in den In-Content-Manager (wie in dem Link unter 3.
beschrieben), sehe als einzige Instanz die ZPU.
An dem Punkt hänge ich jetzt. Welchen Code muss ich da hochladen? Ich
dachte, ich muss eine Art Firmware hochladen, die dann in dem im
FPGA-erstellten ZPU-Core läuft.
Ich glaube, es wäre hilfreich, wenn du mir eure Testversion mal
schickst.
Ich bin absoluter Neuling in VHDL. Interessiert mich aber brennend.
Deshalb möchte ich halt einfach mal damit ein bisschen rumspielen und
den Einstieg damit schaffen.
Gruß,
Stefan
@stefan: du musst während des uploads des programms die ZPU im reset
halten. dazu hälst du die linken beiden softbuttons (f1/f2) gedrückt,
während du im mem editor auf hochladen drückst. Siehe auch hier:
http://apps.sourceforge.net/trac/welecw2000a/wiki/InSystemMemoryContentEditor
solche kurzfristigen dinge können wir am besten per skype klären. mein
skype name: crazor01
@hayo: ich habe jetzt zwar gerade noch 0.63 drauf und werde sicher auch
nochmal mit der aktuellen testen, sobald das flashen wieder klappt, aber
mir ist aufgefallen dass die samples scheinbar immer ein pixel links von
der jeweiligen gridline dargestellt werden, sowohl mit als auch ohne
aktivierter vektordarstellung...
...und noch zwei Fragen an die Programmkundigen:
1.) Was macht eigentlich der Button- "Vektor off" bei Timebase <50ns?
Eigentlich sollte man erwarten das keine interpolierten Werte
dargestellt werden, dem ist aber offensichtlich nicht so. Es scheint so
als ob nur die schrägen Verbindungen fehlen.
Gerade für Testzwecke wäre es gut, wenn wirklich nur die gemessenen ADC
Werte dargestellt werden.
2.) Was macht der Button- "Switch Drawing" am Oszilloskop? Irgendwie
kann ich da leider keinen Unterschied in der Darstellung erkennen. Eine
optische Rückmeldung via via Display wäre natürlich gut, damit man auch
weiß was man denn eingestellt hat, sofern die Fkt mal geht.
Lässt sich die Anzeige "unmöglicher Werte" im Quick Measure Menü nicht
unterbinden? Ich wundere/ ärgere mich jedes mal über eine
Frequenzanzeige über 250MHz.
Gruß, brunowe
Ich hab ein Problem mit dem aktuellen GERMSloader. Und zwar ist ja wie
bereits erwähnt mein serieller Port etwas flaky, ab und an wird ein
Zeichen verloren oder doppelt übertragen. Nun seh ich ab und zu mal
einen Punkt in die Statusanzeige reinhüpfen und wieder verschwinden.
Soweit läuft dann alles weiter. Irgendwann bekomme ich aber:
Writing line 004277 of 023377: .X............0 sec / 134 sec left
Error: Timeout while reading response from DSO!
Response was: 'S219815B3D34<#33><#13>
'
Firmware update was NOT successful!
Please fix the connection issue and retry!
Momentan funzt aber auch der von mir neulich gepatchte
flashloader-with-retries nicht, das Problem scheint zu sein dass bei
einem Retry keine Antwort vom Gerät mehr kommt.
Hilfe!
Bruno We schrieb:
> ...und noch zwei Fragen an die Programmkundigen:> 1.) Was macht eigentlich der Button- "Vektor off" bei Timebase <50ns?> Eigentlich sollte man erwarten das keine interpolierten Werte> dargestellt werden, dem ist aber offensichtlich nicht so.
Ich gebe zu, dass das vieleicht ganz hilfreich wäre, allerdings ist es
nicht im Sinne der eigentlichen Funktion und auch nicht ganz einfach zu
realisieren.
Der Sinn der Funktion ist es keine Vektoren (Verbindungslinien)
darzustellen sondern nur die einzelnen Punkte. Im Falle der TB < 50nS
sind das die Werte die bei der Interpolation errechnet werden.
Die Interpolation ist nicht Bestandteil der Grafikroutine sondern findet
separat statt. Die Grafikroutine "weiß" also nicht einmal ob sie jetzt
gerade interpoliert darstellt oder nicht.
> 2.) Was macht der Button- "Switch Drawing" am Oszilloskop? Irgendwie> kann ich da leider keinen Unterschied in der Darstellung erkennen.
Na er schaltet halt den Zeichenmodus um (im Vektormodus) zwischen
Ausgabe via Line() Funktion und Connect_Pixels() Funktion. Die Line()
Funktion verbindet zwei aufeinander folgende Meßwerte miteinander, also
ein echter Vektor. Connect_Pixels() ist eine der alten Funktionen der
orig. FW und zeichnet (um Zeit zu sparen) im Prinzip nur nebeneinander
liegende senkrechte Linien. Dadurch ist die Darstellung etwas grober,
besonders in den Spitzen (man schon etwas genauer hinsehen).
Der Geschwindigkeitsvorteil der Connect_Pixels() Funktion ist
mittlerweile nicht mehr vorhanden seit ich die Line() Funktion mit dem
Bresenham Algorithmus ordentlich aufgebürstet habe. Daher ist die Line()
Funktion auch die Default-Einstellung.
> Lässt sich die Anzeige "unmöglicher Werte" im Quick Measure Menü nicht> unterbinden? Ich wundere/ ärgere mich jedes mal über eine> Frequenzanzeige über 250MHz.
Die Funktion benutze ich zur Zeit nicht, da ich an anderen Baustellen
zugange bin -> ich implementiere gerade die neue FFT. Das neue Grid ist
schon fertig. Daher hoffe ich dass es sich verschmerzen läßt wenn das
erstmal so bleibt.
Gruß Hayo
@all
Ich bin übrigens auf eine interessante Routine beim Trigger gestoßen.
Das Triggerweitenregister wird mit dem - jetzt haltet Euch fest -
Farbwert des Grids geladen!?!?
Fragt mich nicht was das soll, das kann nicht im Sinne der Funktion
sein, daher werde ich das mal ändern. Ihr könnt das ja mal testen,
theoretisch müßte sich die Triggerung ändern je nach Gridintensität.
Sachen gibts...
Hayo
Hallo Hayo,
Zusammenfassend kann man als Antwort auf meine Fragen also sagen:
1.) Für TB<50ns ist die Fkt "Vektor off" praktisch sinnlos- und das wird
auch so bleiben.
2.) Die Fkt "Switch Drawing" bleibt so wie sie ist, auch wenn (nicht nur
ich) da keinen Unterschied erkennen kann und man nie weiß in welcher
Stellung man sich gerade befindet.
3.) Wird im Rahmen der neuen FFT bereinigt.
trotzdem noch frohes Schaffen,
brunowe
Bruno We schrieb:
> Hallo Hayo,> Zusammenfassend kann man als Antwort auf meine Fragen also sagen:> 1.) Für TB<50ns ist die Fkt "Vektor off" praktisch sinnlos- und das> wird auch so bleiben.
Sinnlos finde ich das nicht. Wenn aber die Mehrheit der Meinung ist dass
es Sinnvoller ist nur die realen Stützwerte darzustellen ändere ich das
natürlich. Wäre dann ein Punkt für die Wishlist.
> 2.) Die Fkt "Switch Drawing" bleibt so wie sie ist, auch wenn (nicht> nur ich) da keinen Unterschied erkennen kann und man nie weiß in> welcher Stellung man sich gerade befindet.
Also ich kann da schon einen deutlichen Unterschied sehen wenn ich etwas
dichter rangehe. Was soll es denn sein? Eine dauerhafte Zustansanzeige
oder ein Popup beim Umschalten?
> 3.) Wird im Rahmen der neuen FFT bereinigt.
Nein, komme ich nicht zu. Vielleicht legt einer der Anderen in der
Zwischenzeit Hand an, dann baue ich das mit ein.
Hayo
Bruno We schrieb:
> Hallo Hayo,> Zusammenfassend kann man als Antwort auf meine Fragen also sagen:> 1.) Für TB<50ns ist die Fkt "Vektor off" praktisch sinnlos- und das> wird auch so bleiben.
Sinnlos finde ich das nicht. Wenn aber die Mehrheit der Meinung ist dass
es sinnvoller ist nur die realen Stützwerte darzustellen ändere ich das
natürlich. Wäre dann ein Punkt für die Wishlist.
> 2.) Die Fkt "Switch Drawing" bleibt so wie sie ist, auch wenn (nicht> nur ich) da keinen Unterschied erkennen kann und man nie weiß in> welcher Stellung man sich gerade befindet.
Also ich kann da schon einen deutlichen Unterschied sehen wenn ich etwas
dichter rangehe. Was soll es denn sein? Eine dauerhafte Zustansanzeige
oder ein Popup beim Umschalten?
> 3.) Wird im Rahmen der neuen FFT bereinigt.
Nein, komme ich nicht zu. Vielleicht legt einer der Anderen in der
Zwischenzeit Hand an, dann baue ich das mit ein.
Hayo
Hallo miteinander,
ich möchte an dieser Stelle erst einmal allen danken, die sich bisher an
unserer Umfrage zum Gerät beteiligt haben.
Ich würde es begrüßen, wenn noch weitere ihre Gerätedaten schicken
würden, unabhängig davon, ob der Flankentest durchgeführt wurde oder
nicht.
Gern sind auch Leute gesehen, die ein W20xx ohne "A" haben. Diese sind
scheinbar ganz in der Versenkung verschwunden, weil man von ihnen gar
nichts mehr hört.
Um so mehr würde ich mich auch darüber freuen, wenn gerade diese Leute
mal versuchen würden das veröffentlichte Slog-Design aufzuspielen und
Aussagen darüber zu treffen, ob ihr Oszi damit läuft oder nicht.
Beste Grüße, branadic
Kurt Bohnen schrieb:
> Hallo Hayo,> in ramloader.bat und flashloader.bat fehlt das -w
Ups, da ist mir wohl eine alte Version reingerutscht - sorry
Hayo
So, ich glaube das lag an der Temperatur. War 2 Stunden weg, nun hat's
Flashen auf Anhieb geklappt. Zwar mit meinem alten Skript, aber bei der
nächsten FW teste ich mal das neue ;)
Hab aber mal ne Frage zum neuen DAC-Abgleich. Gibt es nur drei Werte, je
einen für den 1er, 2er und 5er-Bereich? oder muss man tatsächlich auch
durch alle 1V/100mV/10mV-Bereiche durchgehen? Zumindest kommen bei mir
für die verschiedenen Größenordnungen die gleichen Kalibrierwerte
heraus. Oder sind das nicht die Werte, die beim Kanalwechsel als
CH*_DAC_Offset angezeigt werden?
Crazor schrieb:
> Hab aber mal ne Frage zum neuen DAC-Abgleich. Gibt es nur drei Werte, je> einen für den 1er, 2er und 5er-Bereich?
Genau, und das jeweils für jeden Kanal
Hayo
Crazor schrieb:
> Writing line 004277 of 023377: .X............0 sec / 134 sec left> Error: Timeout while reading response from DSO!> Response was: 'S219815B3D34<#33><#13>> '
Da muss mir mal ein GERMS-Kundiger weiterhelfen. Was bedeutet es, wenn
der Monitor mit '!' antwortet? Darauf muss ich sicher nur korrekt
reagieren und dann ginge es weiter.
/Hannes
Hallo zusammen,
zwar besitze ich derzeit (noch) kein Welec- Scope, verfolge eure
Entwicklungen aber bereits eine Weile. Leider bin ich beruflich im
Moment ziemlich im Stress, als kleine "Entspannungsübung" habe ich aber
mal einen Blick auf eure Veränderungen, genauer gesagt auf die neuen C-
Routinen von Guido geworfen.
Vielleicht hilft euch ja folgender Denkanstoß weiter:
In ADC_ReadData() wird ein Puffer 4096 * 4 Byte gefüllt. In
ADC_ProcessData() sollte dieser - wie ich vermute - in der inneren
Schleife byteweise ausgelesen werden. Der Code dazu sieht folgendermaßen
aus:
byte_data = *(chan_addr + i); //load one byte
Mal abgesehen davon, daß hier ein (sinnvoller) cast fehlt (wie an
anderen Stellen in der Funktion auch), könnte euch in dem Fall die
Endianess einen Strich durch die Rechnung machen. Falls die Werte little
endian im Speicher liegen, wird statt 0, 1, 2, 3, 4, 5, 6, 7, 8, ...
die Reihenfolge 3, 2, 1, 0, 7, 6, 5, 4, ... ausgelesen.
Beste Grüße,
odic
Hallo odic,
auf die Idee mit der Endianess bin ich auch schon gekommen und
habe das vorhin probiert.
Aber der Tip mit dem cast ist richtig gut, da werde ich nochmal
mit beiden Änderungen probieren müssen.
Gruß, Guido
Was je nach µC (oder Softcore) auch noch problematisch ein könnte wäre
das alignment. Vielleicht schaffst du es überhaupt nicht, mit einem
ULONG-pointer auf die gewünschten Werte zuzugreifen...
Falls du statt dessen einen UBYTE-pointer verwendest und zudem noch eine
andere Lösung für die Fallunterscheidung bzgl. highspeed findest,
könntest du dir diese Problem und zudem auch die geschachtelten for()-
Schleifen sparen...
Viele Erfolg noch,
odic
@Hannes
Ich habe mir mal den Assembler des GERMS angeschaut (vom nios forum),
das '!' scheint ein checksum error zu sein. Ich glaube es sollte reichen
die zeile wo das '!' auftrat noch einmal zu senden.
Martin
So, zur Mitte der Woche (Mittag quasi) hier die 0.73 als
Zwischenversion. Wesentliche Änderungen:
- Ich habe, was eigentlich schon lange mal fällig war, einen
Testsignalgenerator eingebaut den Ihr im Utility-Menü findet. Auf allen
vier Kanälen werden unterschiedliche Signale generiert. Damit kann man
z.B. die Cursor prüfen und Ähnliches (und nicht ganz zuletzt auch die
bald verfügbare FFT).
- Für die FFT habe ich schon einiges vorbereitet. Es gibt ein neues Grid
mit einer Breite von 512 Pix und eine neue FFT-Graphikroutine. beides
kann man sich schon ansehen, nur das noch kein echtes Spektrum
ausgegeben wird. Als Demo ist es aber schon ganz ok denke ich.
Übrigens die Sache mit dem Triggerweitenregister geht noch weiter.
Nachdem ich mich ja schon gewundert hatte, dass dieses Register mit der
Gridintensität geladen wird (in SetupADC()), habe ich jetzt
rausgefunden, dass über dieses Register tatsächlich die Gridhelligkeit
(Gridfarbe) gesteuert wird. Schon etwas obskur oder?
Gruß Hayo
Hallo Odic X.,
danke für die Tips, die laufen ja schon auf Optimierung hinaus.
Eine Änderung von "chan_addr" auf "unsigned char" hat den erhofften
Erfolg gebracht. Probleme mit der Endianess gibt es wohl nicht,
ich bin aber nicht sicher, ob die ADC-Korrekturwerte richtig
zugeordnet werden. Das teste ich weiter, es ist aber recht schwer
zu erkennen.
Die doppelte Schleifenstruktur lasse ich vorerst, sie ist zwar
ganz sicher nicht optimal für die Geschwindigkeit, aber ich kann
damit sehr schnell kleine Tests durchführen. Zu diesem Zweck
mache ich mir ja die ganze Arbeit.
Gruß, Guido
Hallo Guido,
wußte gar nicht, daß mein Nick irgendeine Bedeutung hat...
Wieder was gelernt...
Ein paar Fragen noch zu der Funktion:
1.) Das Thema Averaging handelst du in folgenden Zeilen ab:
temp_int = temp_byte + ((byte_data - temp_byte) >> averageval);
if (temp_int < 0) temp_int = 0; //limit to byte ???
else if (temp_int > 255) temp_int = 255;
byte_data = temp_int;
Funktioniert das korrekt? Wenn ich es richtig verstehe, dürfte
"byte_data - temp_byte" nur in jedem zweiten Fall das gewünschte
Ergebnis bringen. Da averageval maximal 1 ist (soweit ich gesehen habe),
sollte folgendes genügen:
byte_data = (unsigned char)(((unsigned short)byte_data + (unsigned
short)temp_byte) >> 1);
2.) Die Zeile "temp_int = (zero << 1) - byte_data;" erschließt sich mir
nicht ganz, kannst du mir da auf die Sprünge helfen?
3.) Was ist der Hintergrund der unterschiedlichen Ablage im Zielpuffer
in Abhängigkeit von highspeed?
4.) Wie groß ist int in eurem core eigentlich?
5.) Nutzt ihr noch irgendeine andere Kommunikationsplattform für solche
Entwicklungsdetails? Dann müßte ich hier nicht den Thread zumüllen...
Fragen über Fragen.... ;-)
Beste Grüße und einen schönen Abend,
Odic
Martin H. schrieb:
> das '!' scheint ein checksum error zu sein. Ich glaube es sollte reichen> die zeile wo das '!' auftrat noch einmal zu senden.
Alles klar, danke. Das werd ich mal schnell reinbauen.
/Hannes
Odic X. schrieb:
> Hallo Guido,> 4.) Wie groß ist int in eurem core eigentlich?
4 byte (d.h int = long int)
> 5.) Nutzt ihr noch irgendeine andere Kommunikationsplattform für solche> Entwicklungsdetails? Dann müßte ich hier nicht den Thread zumüllen...
Das ist hier der Thread für genau diese Themen, Du bist hier schon ganz
richtig. Für Hardwarelastige Angelegenheiten gibt es extra den
Hardware-Thread.
Hayo
Hallo Odic X.,
1.) Da habe ich mich noch garnicht drum gekümmert, es passiert nichts
katastrophales wenn ich den Button drücke. ;-)
So wie ich das sehe, ist es Geschmacksache: deine Version wichtet den
alten Wert ebenso stark wie den neuen, die Originalversion wichtet
den neuen Wert nur halb so stark wie den alten Mittelwert.
2.) Zur Invertierung wird die Differenz zwischen Zerolevel und
Signal zum Zerolevel addiert. Ergibt insgesamt
2 * Zerolevel - Signal.
3.) Großes Rätsel. Mir scheint, dass abhängig von der Timebase
die Daten im FIFO unterschiedlich angeordnet sind. Von
READADC_ALL2 werden sie noch 1:1 übertragen und in READADC_ALL
werden sie dann so sortiert, dass sie für die Grafik immer in
gleicher Reihenfolge stehen.
4.) Größer als ein Byte, das reicht. ;-) (Hayo weiß das besser,
s.o.)
5.) Nö, das sind wir zu altmodisch zu. Es sollen ja auch alle
mitlesen und, so wie du auch, ihre Meinung äußern können. Je
mehr Leute sich das anschauen, umso leichter werden die Fehler
entdeckt.
Gruß, Guido
Guido schrieb:
> 3.) Großes Rätsel. Mir scheint, dass abhängig von der Timebase> die Daten im FIFO unterschiedlich angeordnet sind. Von> READADC_ALL2 werden sie noch 1:1 übertragen und in READADC_ALL> werden sie dann so sortiert, dass sie für die Grafik immer in> gleicher Reihenfolge stehen.
Ohne mir das Coding angesehen zu haben: Mit scheint es ganz logisch,
dass abhängig von der Timebase die Reihenfolge variiert. Denn es kann
gut sein dass je nach gewünschter Abtastrate 1, 2 oder 4 ADC verwendet
werden. Entsprechend müssen die Daten dann in der richtigen Reihenfolge
zusammengestellt werden.
Gruß Hayo
Hallo Guido,
1.) So ich die bisherige Implementierung verstehe, wird die Differenz
zwischen altem und neuem Wert halbiert und zum alten Wert hinzuaddiert.
Dabei sind beide Werte gleich gewichtet. Am Ergebnis sollte sich also
durch die andere Implementierung nichts ändern, nur an der Performance.
Wenn es bei byte_data < temp_byte tatsächlich nicht zu extremen Fehlern
aufgrund des Überlaufs kommt, könnte ich mir höchstens vorstellen, dass
die Differenz bereits in einem signed int gebildet wird und das shiften
des Vorzeichens in diesem Fall ja kein Problem darstellt. Das
funktioniert dann aber nur "zufällig" problemlos. ;-)
4.) Für die Funktion reichts, für die Performance heißt unnötig groß
eben oft auch unnötig langsam. Außerdem möchte ich ja nicht, dass sich
short diskriminiert fühlt... ;-)
Beste Grüße,
odic
Das würde bedeuten, daß man sich die Weiterverarbeitung der Daten, die
keine sind, sparen könnte. Das war auch der Hintergrund meiner Frage.
Wenn man an der Stelle eine pauschale Fallunterscheidung machen könnte,
wären evtl. die vielen relativen Speicherzugriffe unnötig, die 16384 Mal
ausgeführt werden...
Hallo odic,
1.) Du hast Recht, die Gewichtung ist in beiden Fällen gleich.
Manchmal hilft es doch, wenn man es sich arithmetisch hinschreibt.
Dann kann ich die Rechnung ja gleich im Byte machen und spare den
cast (data_byte = (data_byte >> 1) + (temp_byte >> 1);)
4.) Das ist völlig richtig und das habe ich auch vor, sobald ich
kapiere welche Werte tatsächlich zur Anzeige kommen. Ich vermute
grundsätzlich die ersten 4096, tatsächlich werden in dem Bereich
(Timebase = 7) aber nur wenige hundert Pixel angezeigt. Das muss
ich mal mit Hayo klären, der weiß das wahrscheinlich auswendig.
Gruß, Guido
Guido schrieb:
> tatsächlich werden in dem Bereich> (Timebase = 7) aber nur wenige hundert Pixel angezeigt. Das muss> ich mal mit Hayo klären, der weiß das wahrscheinlich auswendig.
In den Programing Maps in der Timebasetabelle findest Du die benötigten
Werte. Ich werde mal eine aktualisierte TB-Tabelle mit den neuen
Rollmode-Werten rausgeben.
Hayo
> Dann kann ich die Rechnung ja gleich im Byte machen und spare den> cast (data_byte = (data_byte >> 1) + (temp_byte >> 1);)
Wäre natürlich besonders elegant, geht aber leider nicht. So verlierst
du den Übertrag, wenn die untersten beiden Bits 1 sind...
Hallo Hayo,
freue mich schon auf die FFT. Meinst du es ist möglich in allen
Zeitbereichen die "Zoom"-Möglichkeit bereitzustellen? Z.B. im
2us-Bereich ist es schon dürftig.
@Guido,
vielleicht läuft die ADC_readdata schneller, wenn du unten den
Feldzugriff durch einen Byte-Zeiger austauscht?
Nur so eine Idee.
Gruß,
Stefan
Hallo odic,
>Wäre natürlich besonders elegant, geht aber leider nicht. So verlierst>du den Übertrag, wenn die untersten beiden Bits 1 sind...
Da hast du natürlich auch wieder recht. Naja, im Moment komme ich
sowieso nicht dazu viel zu ändern (das wird ja da Einfachste, weil
ich es von oben kopieren kann. :-) ).
@ Stefan: das erledigt sich von selbst, wenn ich nach odics
Vorschlag die Fallunterscheidung "richtig" mache. Besteht denn
Interesse an einer optimierten C-Funktion?
@ Hayo: Mit der Timebase-Table komme ich nicht gut klar, da mir
die Spaltenüberschriften zum Teil nichts sagen. Auch die Werte
in der Klammer bleiben mir schleierhaft.
Gruß, Guido
Hallo Guido,
bevor du weiter Zeit investierst wäre es vielleicht mal interessant zu
sehen, wie die Darstellung hochfrequenter Signale jetzt aussieht. Soweit
ich verstanden habe war ja einer der Gründe für deine Mühe ein
vermuteter Fehler in den ASM- Routinen....
Grüße,
odic
Hallo Hayo,
in Zeile 19362, hardware_t.cpp habe ich in der if-Abfrage das erste
Argument (timebase<7) entfernt. Gibt es einen Grund, warum das da
drinnen steht? Solange das da drinnen steht, trifft bei mir der Trigger
nicht sauber bei größeren Zeitbasen. Und ohne klappts einwandfrei.
Bemerke keinen Unterschied.
Gruß,
Stefan
Hi Stefan,
wie so einiges in diesem Coding ist dieses Statement anscheinend
ziemlich sinnbefreit. Wenn Du sagst dass es ohne besser läuft werde ich
das mal einfach übernehmen. Falls es da Probleme geben sollte werden
wohl schon entsprechende Rückmeldungen kommen. Ich hatte das bislang
unverändert gelassen, da sich mir der Sinn nicht direkt erschlossen hat
(zumal die Timebase 7 selbst überhaupt nicht verwendet wird).
Gruß Hayo
So hier die aktualisierten Programming Maps.
Unter die Timebasetabelle hab ich für die bessere Verständlichkeit eine
Legende geschrieben. In Kürze hier nochmal:
- Ta = Abtastrate
- Factor = Schrittweite in der for() Schleife über die 16384 Werte,
also der wievielte Wert tatsächlich verwendet wird.
Bei den interpolierten TB ist dieser Wert zwar 1, aber
da hier zusätzliche Werte eingefügt werden gibt es einen
Pseudofaktor in Klammern
- Sample Depth = Anzahl der tatsächlich verwendeten Werte, ergibt sich
aus 16384 / Factor. Bei den interpolierten TB stehen
die vollen 16384 Werte zur Verfügung, allerdings auf
dem Bildschirm immer nur Gridbreite * Pseudofaktor
d.h. bei TB 5ns - 600 * 1/10 = 60 reale Werte
- TB-Idx = der Index mit dem die Registerwerte aus dem Array gelesen
werden. Das entspricht dem Wert der Variablen
Selected_Timebase.
- TB-Register = das sind die Werte die aus dem Array gelesen
werden und ins TB-Register geschrieben werden.
Übrigens habe ich festgestellt, dass in Open Office die schraffierten
Flächen (interpolierte TB) nicht dargestellt werden.
Gruß Hayo
Ich habe jetzt ein W2024A abzugeben.
Hardware 8C7.0H
Firmware 1.4
Das Gerät hatte einen Kurzschluss zwischen Main/Delayed und
Mode/Coupling Taste den ich beseitigt habe. Außerdem wurde der JTAG
0-Ohm Widerstand eingelötet.
Das Zubehör ist Orginalverpackt. Preis 350,50€ + 5,90€ Versand.
Bezahlung per Überweisung, PayPal möglich. Wenn der Käufer verspricht
sich an der FPGA Entwicklung zu beteiligen, entfallen die Versandkosten!
Hi Kurt,
was willst Du mit so vielen Oszis? Einen Laden aufmachen ? ;-)
Im Ernst:
Ich hab einige Probleme den FPGA auszulesen (s.o.). Kannst Du mir einen
Tipp geben? Für einen Moment bekomme ich die Treiber für den USB-Blaster
installiert und wenn ich das Gerät vom USB nehme und wieder verbinde,
geht nix mehr. Im Gerätemanager steht immer: Unbekanntes Gerät und ich
bekomme keine Verbindung mehr hin, die Altera-Software findet dann
natürlich keinen Programmer. Normalerweise habe ich keine Probleme
solcher Art aber diesmal sind sie wirklich hartnäckig.
Irgendwas fehlt noch und ich krieg's nicht raus...
Meine Config: Windows XP SP3, Thinkpad T41 Laptop
Michel
Hallo Michael,
hast du schon ein anderes USB Kabel probiert?
Wieso viele Oszis? Ein 2022A und ein 2024A. Das zweite 2024A stammt aus
einem Deal mit Wittig und wird jetzt verkauft. ;-)
@Kurt
Ein faires Angebot, davon kosten ja allein schon die 200 MHz Tastköpfe
80 Euronen. Wenn ich das eher gewußt hätte, wären wir ins Geschäft
gekommen. Jetzt hab ich ja das 2014A schon seit ein paar Wochen und kann
es nicht mehr zurückschicken.
By the way, hatte nicht vor einiger Zeit ein netter WELEC-Besitzer
angeboten praktische Taschen herzustellen? Da hab ich seit dem nichts
mehr von gehört.
Hayo
@ Hayo
Wegen der Taschen:
Ich such' immer noch ein Muster im Netz. Wenn Ihr Vorschläge habt: Immer
raus damit. Ich wollte eigentlich nur eine oder zwei Versionen nähen und
nicht soviel rumexperimentieren.
Daher jetzt konkret die Frage: Was soll denn alles dran sein? Hauptfach
für das Scope, oben mit Reißverschluß und an einer Längsseite zwei
aufgenähte Taschen mit Klettverschluß für die Kabellage. Über die
Schmalseite Verbindungen/Ösen für einen Schultergurt?
Michel
Michael W. schrieb:
> Daher jetzt konkret die Frage: Was soll denn alles dran sein? Hauptfach> für das Scope, oben mit Reißverschluß und an einer Längsseite zwei> aufgenähte Taschen mit Klettverschluß für die Kabellage. Über die> Schmalseite Verbindungen/Ösen für einen Schultergurt?
Das wäre ja schon mehr als ich zu hoffen wagte - echter Luxus quasi. Das
würde mir schon gefallen!
Wenn ich da nicht jemandem eine Tasche "wegschnappe" würde ich sogar
zwei nehmen.
Hayo
Hallo Hayo,
danke für die Legende. Bei mir sieht es unter OpenOffice
eigentlich ganz gut aus. Jetzt verstehe ich das besser und
kann schon erste Schlüsse ziehen. Ganz offensichtlich kann
die Zeitbasis auf alle benötigten Teilfaktoren eingestellt
werden. Dies wird aber nicht immer so gemacht und stattdessen
z.T. auf Samplingtiefe verzichtet. D.h., es muss bei der
Entwicklung schon klar gewesen sein. dass es Probleme mit
der Kombination der ADCs gibt. Diese wurde nur dort eingesetzt,
wo es wg. Geschwindigkeit unausweichlich war.
@ odic: Klar will ich die Fehler finden. Ich habe auch schon
einiges probiert (das geht gut nebenher ;-) )aber bisher ohne
Erfolg. Ich werde jetzt erstmal die innere for-Schleife
auflösen, dann kann ich gezielt ADCs ausblenden. Mal sehen.
Gruß, Guido
Hi Folks,
für die HF-Freaks hier schon mal ein kleiner Vorgeschmack auf die
morgige Wochenend-beta 0.74.
Was Ihr seht ist ein 64 MHz Signal von einem Quarzoszillator an einem
10:1 Tastkopf. Achtet mal auf die Zeitbasis :-)
Zur Zeit arbeite ich noch an einer besseren Interpolation, die nicht so
stufig ist.
Guats Nächtle
Hayo
Hallo Hayo,
macht es ernsthaft Sinn 24 Werte mit Interpolation auf dem Bildschirm
anzuzeigen? Was man da sehen kann ist doch kaum noch aussagekräftig
oder? Ich würd es verstehen, wenn man mit 5GS/s daherkommen würde, dann
kann man auch in den ps-Bereich vorstoßen. Verstehen würd ich es auch,
wenn man nicht real-time, sondern equivalent-time darstellt.
(http://www2.tek.com/cmswpt/tidetails.lotr?ct=TI&cs=Application+Note&ci=14295&lc=EN)
Wie schaut es eigentlich mit der Interpolation aus? Momentan wird doch
noch linear interpoliert, wenn ich das richtig sehe. Sollte nicht die
Sin(x)/x eines der nächsten Ziele sein?
Möglicherweise auch die Wahl zwischen keiner, linear und Sin(x)/x im
Display-Menu. Nur so als Vorschlag.
Beste Grüße, branadic
Also 24 Werte zu interpolieren ist noch im völlig normalen Bereich und
wird von anderen DSO-Herstellern auch angeboten. Zur Zeit verwende ich
eine sehr einfache an die lineare angenäherte Interpolation, die jedoch
bei größeren deltas schlechter wird und Stufen erzeugt. Daher habe ich
sie jetzt durch eine echte Linearinterpolation (nach Bresenham - hatten
wir ja schon in der Line() Funktion) ersetzt - sieht erheblich besser
aus jetzt.
Die Sin(x)/x macht erst Sinn bei erheblich weniger Abtastwerten, da dann
ein natürlicherer Verlauf ohne Ecken interpoliert wird - mit einem
erheblichen Nachteil:
Die Sin(x)/x Berechnung ist sehr Zeitaufwändig, d.h. die Signalausgabe
würde extrem verlangsamt.
Du siehst ich hab mir da auch schon Gedanken in diese Richtung gemacht,
aber die Linearinterpolation ist für diese kleinen Deltas der beste
Kompromiss zwischen akkurater Darstellung und Bildwiederholrate.
Ich stelle gleich mal ein Bild mit dem Signal von Gestern ein allerdings
mit neuer Interpolation, dann hat man den direkten Vergleich.
Hayo
Also ich finde Interpolation in jedem Fall legitim, da es dem Auge dann
in jedem Fall erleichtert wird, den Signalverlauf schnell zu erfassen.
Punktwolken sind da viel schwieriger ;)
Natürlich sollte jeder wissen, was das Gerät gerade macht und wie viel
von den Daten denn nun echt und was interpoliert ist, aber evtl. wäre es
sinnvoll, die tatsächlichen Messwerte z.B. heller darzustellen als die
interpolierten.
Bzgl. der sinc-Interpolation (und auch für den Bresenham) suche ich noch
eine anständige Beschreibung der Mathematik dahinter, habe bisher
zumindest im Netz immer nur Beispielimplementierungen gefunden. Infos
über günstige Hardware-Realisierungen wären natürlich auch toll, aber
die kann ich notfalls auch selbst ersinnen ;) Ich glaube ich muss mal
wieder in die Uni-Bib gehen...
Hallo Hayo,
Crazor schrieb:
> aber evtl. wäre es sinnvoll, die tatsächlichen Messwerte z.B. heller> darzustellen als die interpolierten.
Na also... da haben wir's wieder! Hatte ich das nicht schon vor 4-5
Monaten angeregt? Vielleicht findet sich ja doch noch eine Möglichkeit
der Umsetzung?
Doch noch was Anderes: Hans und Crazor konnten das Problem in unserem
Softcore endlich lösen. Das bedeutet das die Weiterentwicklung des neuen
FPGA Design jetzt in großen Schritten vorwärts gehen kann....FREUDE...
Gruß, brunowe
Hallo,
uih, dann muss ich mich irgendwann auch noch mit dem Altera-Kram
auseinandersetzen.
@ Hayo: der 2-ns-Bereich ist natürlich immer sinnvoll. Auch wenn
er ev. keine weitere Information bietet, erlechtert er unter
Umständen das Kästchen-Zählen. Lass dich nicht beirren.
Gruß, Guido
Nicht falsch verstehen, wollt den Hayo weder bekehren noch beirren. Als
Wissenschaftler liegt es in meiner Natur erst einmal alles in Frage zu
stellen, that's it.
Gruß, branadic
Ist auch völlig korrekt. Man muß nicht alles was machbar ist auch
umsetzen. Die Fragen nach Sinn und Unsinn ist durchaus gerechtfertigt
und stehe dazu auch gerne Rede und Antwort. Es wäre auch nicht das erste
Mal das man sich da in etwas verrennt, das keinen Sinn macht. In diesem
Fall muß ich aber sagen, das es wirklich gut aussieht und hilfreich ist.
Auch die anderen interpolierten Bereiche profitieren von der neuen
Interpolationsroutine, sieht schon deutlich besser aus.
Foto kommt gleich.
Hayo
...für Guido das Ganze bei 100mV an 1/10 Tastkopf.
Man kann deutlich den zusätzlichen Schwinger erkennen der anscheinend
von der Eingangsstufe erzeugt wird.
Hayo
Bruno We schrieb:
> Doch noch was Anderes: Hans und Crazor konnten das Problem in unserem> Softcore endlich lösen. Das bedeutet das die Weiterentwicklung des neuen> FPGA Design jetzt in großen Schritten vorwärts gehen kann....FREUDE...
Ok, eigentlich wollte ich die Ankündigung zusammen mit der Herausgabe
eines neuen Testdesigns machen, aber wenn's nun schonmal soweit ist,
vielleicht noch ein paar Informationen:
Das Problem war ja, dass die ZPU, die wir als Softcore einsetzen,
partout nicht aus dem SRAM heraus booten wollte. Lesen/Schreiben bei
Programmausführung aus dem FPGA-internen Blockram war allerdings OK.
Letztlich hat Hans durch viel Simulation einen Bug in der ZPU entdeckt,
der bei Back-To-Back-Writes auf langsamere Speicher zum Überspringen von
Instruktionen führte. Der Bug ist mittlerweile behoben.
Aktuell gibts also das altbekannte Slog-Design mit einem Open Source
Softcore (statt des NIOS, den wir ja nicht ohne weiteres nutzen dürfen),
der die Benutzerschnittstelle implementiert. Die Signalerfassung und
-darstellung erfolgt also nach wie vor ausschließlich in Hardware, der
Softcore legt quasi die Benutzerschnittstelle mittels eines
Zeichengenerators oben drüber. Der Prozessor führt anfangs einen
Bootloader ähnlich dem GERMSmonitor aus, der es erlaubt, die Software
aktuell per serieller Schnittstelle zu übertragen (später wird die
Software dann aus dem Flash geladen werden können, aber den rühren wir
bisher noch nicht an).
Da die Softwareentwicklung bis zur Behebung des Bugs nicht wirklich
voranschreiten konnte (so ein FPGA hat verdammt wenig Blockram), habe
ich in der Zwischenzeit große Teile der Signalerfassung neu geschrieben,
da Slogs Code doch etwas schwer nachvollziehbar war (hauptsächlich die
Signalbenennung war sehr unintuitiv, was ich mal auf die Sprachbarriere
schiebe, außerdem keine Hinweise über Unzulänglichkeiten der aktuellen
Implementierung usw.). Die Signaldarstellung liefert nun
nachvollziehbare Time Bases, der Downsampler ist neu geschrieben und ein
neuer Trigger ist im Ansatz vorhanden.
Ich hoffe, in den nächsten Tagen eine Programmierdatei zum "Spielen"
veröffentlichen zu können, damit man sich ein Bild vom aktuellen Zustand
machen kann.
Viele Grüße
Daniel
Ok, hier ist sie die Wochenend Beta.
Diesmal habe ich viele kleine Baustellen beackert. Gleich vorweg, die
FFT ist noch nicht dabei, ich wollte erstmal weiter aufräumen.
Dafür sind für Bruno gleich zwei Sachen dabei ;-)
- bei der Umschaltung des Zeichenmodus wird jetzt ein Popup angezeigt
- bei interpolierten TB werden im Pixelmodus die interpolierten Werte
unterdrückt und nur die echten Werte angezeigt
Weiterhin gibt es Folgendes:
- die neue TB 2ns (wie angekündigt)
- ich habe die Steuertabellen für den Triggeroffset korrigiert. Für TB
5nS und 2nS wird jetzt korrekt getriggert
- geändertes Scrollverhalten für Pretrigger und Memorybrowsing für
komfortableres Bedienung (sonst kurbelt man sich ja nen Wolf)
Spaßeshalber hatte ich bei der Interpolation mal die alte
FIR-Interpolation von vorher eingebaut - gruselig. Könnt Ihr ja mal mit
der originalen FW vergleichen :-)))
Viel Spass
Hayo
Oh, ich sehe gerade es ist mir noch ein kleiner Bug im
Testsignalgenerator auf Kanal 3+4 durchgerutscht. Kommt weil ich auf dem
2022A getestet habe. Ich reiche morgen ein Update nach.
Hayo
Noch eine kurze Meldung Hayo...
Die ADC werden aktuell offensichtlich sequentiell ausgelesen, weswegen
es eine zeitliche Verschiebung zwischen den Kanälen gibt, legt man an
alle Kanäle das gleiche Signal. Hier wäre eine zeitliche Kompensation
notwendig. Angenommen man schaut sich verschiedene Signale einer
Testbench an, dann sollte allen der gleiche zeitliche Nullpunkt zugrunde
liegen, um eine Aussage treffen zu können. Ließe sich das in einer
zukünftigen FW hinzufügen?
Hier hat das neue FPGA-Design klare Vorteile, da gibt es "keine"
zeitliche Verschiebung zwischen den Kanälen, da die ADC der einzelnen
Kanäle parallel ausgelesen werden.
Beste Grüße und guten Morgen ;)
branadic
Oh
und ich dachte schon, ich bin der Einzige, dem sich der Nutzen der
Testsignale nicht schließt. Kann man ja auch gleich ein paar Animationen
zeigen. Praktischer fände ich eine Selbstdiagnose oder einen
automatischen Nullinien/ADC/DAC Abgleich durch alle Bereiche...
Heute habe ich endlich auch meinen USB-Seriell Adapter zum Flaschen zum
Laufen gebracht: Ich hatte das serielle Kabel dazwischen immer
weggelassen. So kann's kommen ;-)
Die Signale sehen jetzt wirklich deutlich besser aus, gerade in den
starken Vergrößerungen ... Die Firmware macht wirklich große
Fortschritte.
Jetzt muss ich nur noch in den FPGA kommen...
Michel
Zum Testsignal:
Ich hatte ja schon mal geschrieben wofür man das gebrauchen kann. Es
handelt sich nicht nur um bunte Bildchen, sondern an der Stelle wo sonst
die Signale aus dem ADC-Register gelesen werden, generiert der
Testsignalgenerator Ersatzwerte. Für den Rest der Firmware ist es also
genauso als wäre das Signal aus dem ADC ausgelesen worden. Man kann
damit z.B die Cursorfunktion testen, die QM-Funktion, die
Autoscalefunktion, die Übertragung zum PC und so weiter. Unter Anderem
hatte ich den Generator auch geschrieben um die FFT zu Testen, da ein
sauberes Testsignal die Möglichkeit gibt genau zu kontrollieren ob die
FFT korrekt arbeitet. Beim direkten Vergleich zwischen Testsignal und
realem Signal kann man z.B. sehen ob man am ADC ein Interleaving-Problem
hat.
Zum Auslesen der ADC:
Das die ADC zeitlich versetzt ausgelesen werden ist völlig egal. Wichtig
ist nur, dass sie parallel die Signale abtasten. Wenn dann der AQU_READY
Interupt ausgelöst wird ist das quasi wie ein Schnappschuß dieses
Zeitpunkts der in den ADC-Puffern liegt. Ob die dann gleichzeitig
ausgelesen werden oder nicht ist dann unerheblich, ein gemeinsames
Signal liegt dann auf jeden Fall im gleichen Nullpunkt.
Hayo
Hallo Hayo,
danke für deine Erklärung zu beiden Themen. Wie aber erklärst du dir
dann den zeitlichen Versatz zwischen den Kanälen, der ja nicht ganz
unerheblich ist? Oder bin ich der einzige bei dem das so ist?
Gruß, branadic
Also der zeitliche Versatz ist mir noch nicht aufgefallen. Müßte ich mir
mal genauer ansehen, gebe aber zu dass ich da außer bei der
XY-Darstellung noch kein so großes Augenmerk drauf gelegt habe.
Sollte es tatsächlich einen zeitlichen Versatz geben, so ist das jedoch
nicht auf das zeitlich versetzte Auslesen zurückzuführen, vielmehr gibt
es hier zwei andere Erklärungen:
- die Signalwerte werden in der falschen Reihenfolge aus dem Buffer
gelesen
- die Hardwareansteuerung der ADC ist falsch ausgelegt. Theoretisch
sollten jeweils die korrespondierenden ADC auf einer Taktflanke liegen
-> (Channel.ADC) 1.1/2.1/3.1/4.1 und 1.2/2.2/3.2/4.2 usw.
Wenn das nicht richtig umgesetzt wurde hat man natürlich einen
zeitlichen Versatz - das wäre allerdings ziemlich übel.
Gruß Hayo
Hayo W. schrieb:
> - die Hardwareansteuerung der ADC ist falsch ausgelegt. Theoretisch> sollten jeweils die korrespondierenden ADC auf einer Taktflanke liegen> -> (Channel.ADC) 1.1/2.1/3.1/4.1 und 1.2/2.2/3.2/4.2 usw.> Wenn das nicht richtig umgesetzt wurde hat man natürlich einen> zeitlichen Versatz - das wäre allerdings ziemlich übel.
Das wäre garnicht so übel wie es scheint. Von nichtdeterministischem
Verhalten mal abgesehen wäre so der Fehler ein für alle Mal bestimmbar
und aus der Welt schaffbar. Wenn es am Auslesecode-Timing läge, dann
müsste man den Versatz nach jeder Änderung der Ausleseroutinen erneut
anpassen.
Hallo,
also Hayo es gibt definitiv einen zeitl. Versatz. Bei meinem Scope
beträgt dieser delay ziemlich genau 7ns. Ch2 ist immer um diesen Versatz
"später dran", unabhängig von der gewählten TB und vom Signal. Man kann
diesen Versatz sogar mit dem internen 1kHz Rechteck entdecken, wobei da
evtl. unterschiedl. Probes zu Verfälschungen führen (untersch.
Flankensteilheit).
Bei höherfrequenten Signalen ist dieser delay natürl. noch
augenfälliger.
wäre interessant ob dieser delay bei jedem 7ns beträgt, oder ob's da
Unterschiede gibt. Evtl. können wir da auch einen SW- Abgleich dafür
basteln, bzw. diesen delay von vornherein rausrechnen.
Im neuen VHDL Design tritt dieser delay nicht auf. Also liegt es wohl
entweder am Welec VHDL, oder doch an der SW.
Gruß, brunowe
No sorry,
so genau kann ich nicht messen. Schon 1 m Kabel bedeutet ja
ca. 6 ns Verzögerung.
@ Hayo: Was ganz interessantes: die Grafik bremst garnicht so
stark wie befürchtet. Bei meinen Spielereien habe ich durch
Programmierfehler schon knapp Screens/s geschafft. Ich glaube
ich werde mal timebase in READADC_ALL genauer auswerten.
Gruß, Guido
@Guido
Na wenigstens sind die ausgelieferten Tastkopfkabel gleich lang! ;-)
@Hayo
Hatte gestern irgendwie Probleme mit dem Ch3 und der
Vertikalauflösung/Verstärkungsumschaltung. Habe deshalb in der SW
gesucht und in der Funktion "Hardware::SetSwitches(..)" eine
Unregelmäßigkeit gefunden: Entweder stimmen die Adressen oder die
KOmmentare? Ch3 tanzt aus der Reihe! Vielleicht hast Du dort schon
"tiefer gebohrt". Scheint aber trotzdem zu funktionieren?!
Gruß,Jürgen
Hallo,
ich habe mal die Kanäle meines W2014A mit den mitgelieferten Tastköpfen
und den Signalen eines 10 MHz und eines 25 MHz Quarzoszillators
vergliechen. Bei mir ist Kanal 2 8ns hinter Kanal 1, Kanal 2 4 ns hinter
Kanal 3 und Kanal 4 3 ns hinter Kanal 3.
Auch das Vertauschen der Tastköpfe hat nichts geändert.
Gruß Kristian
Hallo,
> Na wenigstens sind die ausgelieferten Tastkopfkabel gleich lang! ;-)
DANKE Jürgen - das war Guido offensichtlich nicht bewusst ,-)
Man kann also auf jeden Fall nen Trend erkennen. Scheint also überall
so, das Ch2 ca. 6- 10ns hinter Ch1 liegt. (und ggf. Ch4 hinter Ch 3)
Mal sehen was wir diesbzgl. noch für Erkenntnisse gewinnen (VHDL oder
SW- Problem)
Gruß, brunowe
Hallo,
ich fürchte, ich muss noch deutlicher werden: Bei einem
Eingangswiderstand des Tastkopfes von 1 MOhm diskutiert ihr
über eine Kapazität von ca. 10 fF. Macht das wirklich Sinn?
Gruß, Guido
Hmm,
wenn ich das hier so lese (ohne selbst nachgemessen zu haben - muß ich
mal nachholen) dann scheint es ja tatsächlich ein Timingproblem bei der
ADC-Ansteuerung zu geben, oder unser WELEC-Programmierer hat einen
kapitalen Bock beim Sortieren der ADC-Werte geschossen (also einer von
den Jungs hat sich da jedenfalls nicht mit Ruhm bekleckert).
Eigentlich müßte das ja im XY-Modus zu sehen sein, denn der
Laufzeitunterschied verursacht ja eine Phasenverschiebung die sich dann
als Oval (bei Sinus) zeigen müßte wenn man auf beide Eingänge das
gleiche Signal legt - schon ausprobiert?
Zur Zeit kämpfe ich selbst mit einem Stack-Overflow oder einem
Buffer-Overflow in der FFT und bin deswegen nicht so richtig in Stimmung
das ADC-Timing zu prüfen, aber interessieren würde es mich ja schon.
Übrigens wenn die FFT durchläuft sieht es schon richtig gut aus, war
zwischendurch schon mal am überlegen ob ich einen Screenshot einwerfe -
mußte dann aber zugunsten eines Besuches beim Griechen verzichten.
Gruß
Hayo
Hallo,
nein Guido, wir sprechen nicht von 10fF. Wir sprechen von einem delay
von 7ns welche uns ein tiefer gehendes Problem (wo auch immer das
steckt) offenbart. Da es keinen technologischen Grund für so eine
Verschiebung gibt (unser VHDL zeigt das es auch ohne delay geht),
sollten wir doch versuchen dieses Problem auszumerzen. Evtl. erledigt
sich damit auch noch das Ein oder Andere? Die Oszillation bei höheren
Frequenzen z.B.- das konnte ich ja im VHDL auch nicht nachweisen.
Gruß, brunowe
Hallo,
Auch ich kann den Versatz von ca. 8..10ns mit der SW von hayo
nachvollziehen (Tastkopf unabhängig). Wenn ich zu der FW 1.3 zurück gehe
ist der Versatz weg! Scheint also ein SW problem zu sein.
Martin
> Auch ich kann den Versatz von ca. 8..10ns mit der SW von hayo> nachvollziehen (Tastkopf unabhängig). Wenn ich zu der FW 1.3 zurück gehe> ist der Versatz weg! Scheint also ein SW problem zu sein.
Ich meine mich auch zu erinnern, dass ich mal (Google Sprachtools sei
dank) im russischen Forum eine Diskussion über Phasenverschiebungen
zwischen den Kanälen gesehen habe. Die Quintessenz damals war dass es
zwischen 1+2 und 3+4 keine gibt, aber zwischen 2+3 ein kleiner
"Restoffset" vorhanden war. Vermutlich ist also in der Originalfirmware
wirklich schon eine Kompensation der Verzögerungen drin gewesen und
(möglicherweise im Zuge der Umstellung auf die in C geschriebenen
ADC-Routinen?) verloren gegangen.
Da gibt es jetzt wieder mehrere Möglichkeiten:
- Stefan hatte die Assemblerroutinen wegen der Invertierung und der
Averageberechnung geändert. Die Änderungen sind seit der 0.63 aktiv.
Wäre interessant ob bei den davor liegenden FW-Versionen auch dieser
Versatz auftritt.
- Eine weitere Möglichkeit ist die Grafikroutine. Ich hatte ja die
Graphikroutinen komplett neu geschrieben, weil das Ganze ein so kruder
Haufen unüberschaubarer Codeaneinanderreihungen war, dass eine Wartung
völlig unmöglich war. Es ist durchaus möglich, dass da versteckt hart
codiert eine Korrektur drin war die den zeitlichen Versatz wieder
geradegebogen hat (von hinten durch die Brust ins Auge quasi).
Auch das läßt sich prüfen indem man eine Uraltversion testet. Ich hab
mal die 0.17 angehängt, da sind noch die alten Routinen aktiv.
Ich bin z.Zt. in der Firma und komme nicht zum Testen, aber vielleicht
hat ja einer von Euch die Gelegenheit.
Hayo
Ich glaube nicht, dass es mit den Assemblerroutinen zu tun hat. Außerdem
ist dort auch nichts versteckt, was einen Delay erzeugt oder ausgleicht.
Ich tippe auf einen Bugfix, der ab der 1.3er FW das Delay ausgleicht. Da
wir ja von der 1.2er ausgehen wird er da wohl noch nicht enthalten sein.
Ist eigentlich gerade jemand dabei die "Quick Measurment"-Funktionen zu
überarbeiten? Sonst schau ich da mal drüber.
Stefan
In der 0.48 sind auch schon die neuen Grafikroutinen aktiv. Zwischen
0.28 und 0.33 habe ich die wesentlichen Routinen umgestellt.
Anbei die Ausgangsversion 1.2.AF von Andreas Fellnhofer. Damit könnte
man nochmal testen.
Gruß Hayo
Grundsätzlich besteht natürlich die Möglichkeit eine solche Korrektur in
unsere Open Source FW mit einzubauen. Dazu müßte man das aber genauer
untersuchen und folgendes klären:
- welche Kanäle sind betroffen?
- ist es immer der gleiche Laufzeitunterschied oder variiert das von
Gerät zu Gerät?
- gibt es Unterschiede zwischen den 2 Kanalgeräten und den 4
Kanalgeräten?
@Stefan
Also ich komme erstmal noch nicht dazu die QM und Cursorroutinen zu
korrigieren, da ich erstmal die FFT fertigmachen möchte bevor ich mich
an die Bugliste mache.
Außerdem wollte ich dann die Cursor gleich für die FFT erweitern.
Wenn Du da weiterkommst ist das doch schon mal ein großer Fortschritt.
Hayo
Jürgen schrieb:
> Hatte gestern irgendwie Probleme mit dem Ch3 und der> Vertikalauflösung/Verstärkungsumschaltung. Habe deshalb in der SW> gesucht und in der Funktion "Hardware::SetSwitches(..)" eine> Unregelmäßigkeit gefunden: Entweder stimmen die Adressen oder die> KOmmentare?
Ja solche Unregelmäßigkeiten finden sich in der originalen Source zu
Hauf. Da scheint an etlichen Stellen einfach mit verschiedenen Werten
experimentiert worden zu sein und dann wurde das einfach vergessen.
> Ch3 tanzt aus der Reihe! Vielleicht hast Du dort schon> "tiefer gebohrt". Scheint aber trotzdem zu funktionieren?!
Nein, da war ich noch nicht dran, wenn Du da Hinweise findest immer her
damit.
Hayo
@hayo
Ok die Version geht (kein Vergleich zu den fortschritten die du gemacht
hast!)
In dieser Version ist bei mir der Versatz besser (Kanal 2 ca. 2ns
voraus, vorher war Kanal 2 ca. 8..10ns hinterher!)
Vermutlich wurde da wirklich was in den Grafik-Routinen korrigiert.
Martin
Eine Korrektur würde sich dann ja als Ergänzung für Guidos C-Routinen
anbieten. Hier müßte dann abhängig von der Time-base der Array-Index des
betroffenen Kanals mit einem Offset versehen werden.
Bei 8nS wäre das in den 1GSa/S Bereichen ein Index-Offset von 8, in den
500MSa/S Bereichen ein Index-Offset von 4 usw.
Gruß Hayo
Hallo liebe Gemeinde,
auch wenn es ein kurzer Themenbruch ist, so denk ich doch, dass er hier
am besten platziert ist.
Ich hatte heute ein sehr informativess Gespräch mit einem Mitarbeiter
von Altera. Die "NIOS-Lizenzfrage" ist geklärt. Demnach gibt es seitens
Altera keinen Grund dafür, dass Wittig/Welec seine FPGA-Sourcen nicht
veröffentlicht. Der Embedded Softcore liegt nicht in Form von Sourcen,
sondern einer Netlist vor und ist damit für uns quasi nicht brauchbar.
Einziger Grund die Sourcen nicht zu veröffentlichen besteht also seitens
Welec selbst, dass sie ihren Sourcecode schlichtweg nicht hergeben
möchten.
Weitere Einzelheiten des Gespräches kläre ich dann in den nächsten Tagen
mit Bruno und Daniel.
Beste Grüße,
branadic
Wenn wir das FPGA-Design von WELEC bekämen hätte das natürlich den
Vorteil, das wir das vorhandene Design in kleinen Schritten verändern
könnten und dann auch gleich FW-Seitig nachziehen könnten. Dann hätten
wir nicht so einen abrupten Übergang und es gäbe für die geänderten
FPGA-Designs auch immer eine passende FW.
Das könnte interessant werden, aus zwei Richtungen parallel zu
entwickeln.
Gruß Hayo
Hier nochmal schnell vor dem Schlafen gehen ein kurzer Blick auf den
Zwischenstand:
Was Ihr seht ist das Spektrum eines 500Hz Rechtecksignals bei einer
Abtastung von 25 MSa/S. Die Gridbreite entspricht der halben Abtastrate
- d.h. ganz links ist der Gleichanteil 0 Hz (DC-Offset) und ganz Rechts
die Frequenz 12,5 MHz.
Das ganze bei Vollaussteuerung im Zeitbereich und einer 512 Punkte FFT.
Im nächsten Bild...
...seht Ihr die gleiche Situation mit einer 1024er FFT. Man sieht schon
die etwas feinere Auflösung.
Die Routine habe ich damals für ein System mit mathematischem
Coprozessor geschrieben. Die vielen Fließkommaberechnungen waren da kein
Problem. Auf unserem NIOS liegt die Wiederholrate z.Zt. bei 2 - 4 S pro
FFT.
Da muß ich mal die Berechnungen auf Integer umstellen, das dürfte
einiges bringen.
Gruß Hayo
Hallo Hayo,
aus dem Bauch raus würde ich sagen das ist sogar schon
gefenstert? Ob die vertikale Skalierung linear oder
Logarithmisch ist, erkenne ich so schnell nicht.
Auf alle Fälle ist es schön anzusehen.
Gruß, Guido
Das Fenster hatte ich für diese Bilder abgeschaltet, da das von WELEC in
der tc_vars.cpp definierte Fenster Störlinien verürsacht. Ich werde da
meine eigenen Fensterdefinitionen einbauen (habe da noch von meinem
damaligen Projekt etliche 1024er Fensterdefinitionen).
Die Darstellung ist linear, die logarithmische Darstellung erkennt man
daran dass die Linien nicht so schmal sind, sondern eher bauchige
Buckel.
Es gibt allerdings noch viele Details die ich noch programmieren muß
bevor das Ganze rund genug für die nächste Beta ist. Ich halte Euch auf
dem Laufenden.
Wie sieht es denn an den anderen Fronten aus?
@Guido
Was machen die C-Routinen? Es sieht so aus, dass wir eine Korrektur für
die Signalverschiebung einbauen müssen, da böte es sich an das mit in
die C-Routinen einfließen zu lassen.
@Jürgen
Hast Du da mit der Umschaltung was rausgefunden?
@Stefan
Wie sieht es an der QM-Front aus?
Gruß Hayo
Zum Thema Signal-Delay zwischen den Kanälen:
Ich habe mal bei meinen Geräten nachgemessen und war doch ziemlich
erstaunt. Es gibt da erhebliche Delays zwischen den Kanälen. Und wie
einige von Euch auch schon festgestellt haben scheint in der original
WELEC FW eine Korrektur eingebaut zu sein (vermutlich in der alten
Graphikroutine).
Damit wir eine einigermaßen gemeingültige Korrektur durchführen können
bräuchten wir möglichst viele Daten von Euren Geräten. Ich habe mal eine
Excelliste erstellt und angehängt in der ich mal meine Werte eingetragen
habe. Tragt einfach Eure Werte dazu und stellt die Liste dann wieder
hier ein. Ich trage dann die Ergebnisse zusammen in eine Gesamtliste.
Gruß Hayo
Hallo,
erstmal Danke fuer eure tolle Arbeit an der Firmware,
bin seit einem halben Jahr Besitzer eines W2024A und
beobachte schon eine Weile die Entwicklung.
Waere es moeglich, den Bildschirminhalt als einfache
Bitmap ueber RS232 (oder USB) auszugeben, damit das
Abfotographieren des Bildschirms entfallen kann?
(Entsprechendes Programm auf PC-Seite zum Auslesen
kann ich selbst schreiben.)
Das waere nicht nur fuers Debugging interessant sondern
auch bei der normalen Benutzung und wesentlich einfacher
als ueber die Originalsoftware von Wittig/Welec.
Gruss,
Niklas
@Martin
Ja genauso wars gedacht. Danke.
@Niklas
Willkommen in der Gemeinde ;-)
Tja, grundsätzlich gibt es ja ein entsprechendes Programm von WELEC, mit
dem die Bildschirminhalte angezeigt werden können. Allerdings habe ich
noch nicht ausprobiert ob das auch mit der Beta FW funktioniert. Es
kursierten mal Gerüchte, dass bei der FW 1.2 die ja der Beta FW zugrunde
liegt genau diese Übertragung buggy war.
Das wäre also ein Punkt an dem z.Zt. jegliche Erkenntnisse fehlen und
wenn sich da jemand (Du??) berufen fühlt Hand anzulegen, dann haben wir
wieder eine Ecke abgedeckt (zumindest könnte man das mal testen). Man
kann sich da natürlich auch zu zweit zusammentun - einer auf PC-Seite
und einer
auf DSO-Seite.
Mir selbst fehlen Windows Programmierkenntnisse, also wäre es eine
willkommene Hilfe.
Mein eigenes Fernziel war es eigentlich mal nach schon vorhandenen
PC-Programmen von renomierten Herstellern zu suchen, und dann das
WELEC-Protokoll so anzupassen, dass man diese Programme nutzen kann
(z.B. von Agilent/HP/Tektronix etc.).
Gruß Hayo
@Martin
wenn ich mir Deine und meine Werte so ansehe, scheint mir, dass WELEC da
eine feste Korrektur von 10 nS zwischen Kanal 1 + 2 in der originalen FW
eingebaut hat.
Hayo
Hallo,
also ich bin immer noch völlig ratlos, wie ich die Verschiebung
messen soll. Dazu bräuchte ich ja zwei Signale mit 50-Ohm ohne
kleinste Phasenverschiebung und mit einer Anstiegszeit von ca.
1 V/ns. Das aber kann das Welec doch garnicht darstellen?
Naja, ich hatte doch gelesen dass die Zweikanaler nicht davon
betroffen sind, dann bleibt mir das erspart.
Korrigieren könnte ich das im Prinzip schon, warten wir mal ab,
ob es da eine Einheilichkeit gibt.
@ Hayo: Steht in "timebase" der in den Programmingmaps angegebene
TB-Idx? Das müsste ich dann ja berücksichtigen. Ich räume die
C-Routine mal etwas auf und poste dann den aktuellen Stand.
Was den PC anbetrifft: Es müsste doch ohne riesigen Aufwand
möglich sein, nach Druck auf den Button "Quick-Print" die
Kanaleinstellungen und Messdaten über RS232 rauszuhauen. Dann
würde man ja sehen, was der eine oder andere damit anfängt.
Gruß, Guido
Hallo,
im Anhang noch die Delays von Ch zu Ch bei meinem Geraet.
@Hayo:
Das Programm von Welec importiert soweit ich das sehe
die Rohdaten vom Oszi und bastelt sich dann (wenn
man die Scope Ansicht aufmacht) wieder nen Oszillogram
daraus.
Direkt aus dem Utility-Menue heraus "Save to..." passiert
auch nicht wirklich das, was man (ich) erwarten
wuerde, naemlich dass die Bildschirmausgabe, inkl.
gesetzter Cursor, gemessener Werte usw., genau wie
angezeigt gesichert wird. Da wird auch nur wieder ein
Dump der Rohdaten gezogen.
Das Protokoll so anzupassen, dass es mit gaengigen Programmen
funktioniert waere wie Du schon sagst ein gutes Fernziel,
fuer meine Belange waere eine reine 1:1 Screenshot Funktion
und einfacher Datenexport schon ausreichend.
Ich habe auch gerade mal das Welec-Programm mit Deiner Firmware
getestet (die 0.75), es erkennt dass das Oszi am USB haengt und
verbindet sich, der Datenimport dauert aber ewwwwig (noch viel
laenger als mit der Originalfirmware) und am Schluss scheint
das Programm zu haengen, jeweils werden die Daten nicht angezigt,
das Oszi ist jedoch wieder "verfuegbar" (waehrenddessen lahmgelegt).
D.h., wie Du schon vermutest hast, funktioniert so nicht.
Ich habe schon gesehen das auf RS232 Testroutinen verfuegbar sind,
die die ADC Werte ausgeben, zudem hat Jochen Schaeuble mal das
USB-Protokoll reverse-engineered und auch eine LabVIEW Bibliothek
angelegt, mit der schonmal Importe funktionieren sollen:
http://schaeuble.info/de/category/jochen/w2000a
Auch liegt ja bei der Google Groups Gruppe ein C-File was
mit libusb unter Linux die Daten dumpt, was ich bei mir
allerdings noch nicht zum Funktionieren gebracht habe (ich muss
auch gestehen das ich mit USB noch nicht gearbeitet habe).
Ich denke, den Export der Kurven ueber RS232 und darstellen
mit Hilfe von evtl. gnuplot und die 1:1 Screenshot-Funktion
sind gute Erstziele. Zu letzerem weiszt Du sicher mehr.
BTW: Komme nicht wirklich aus der Windows-Ecke, bin eher
im Unix-Bereich zu Hause.
Guido schrieb:
> also ich bin immer noch völlig ratlos, wie ich die Verschiebung> messen soll. Dazu bräuchte ich ja zwei Signale mit 50-Ohm ohne> kleinste Phasenverschiebung und mit einer Anstiegszeit von ca.> 1 V/ns. Das aber kann das Welec doch garnicht darstellen?
Nein es geht viel einfacher. Man nehme eine Signalquelle mit
BNC-Ausgang, dann ein Stückchen BNC-Kabel und am Ende ein T-Stück drauf.
Dann zwei Tastköpfe hergenommen und auf die Enden die mitgelieferten
BNC-Adapter aufstecken. Jetzt die Tasstköpfe in das T-Stück einführen
und man hat exakt gleichlange Signalwege. (die Tastköpfe sollten nat.
abgegl. sein)
Verwendet habe ich ein 5 MHz Rechtecksignal.
Bei der Messung kann man dann auch gleich die Vorzüge der interpolierten
Zeitbasen der Beta FW nutzen. Im Vergleich dazu läßt sich das mit der
originalen FW relativ schlecht ablesen.
> Naja, ich hatte doch gelesen dass die Zweikanaler nicht davon> betroffen sind, dann bleibt mir das erspart.
Falsch! Ein Blick ins Excelfile und Du bist schlauer.
> Korrigieren könnte ich das im Prinzip schon, warten wir mal ab,> ob es da eine Einheilichkeit gibt.
Eher einen Mettelwert denke ich.
> @ Hayo: Steht in "timebase" der in den Programmingmaps angegebene> TB-Idx? Das müsste ich dann ja berücksichtigen. Ich räume die> C-Routine mal etwas auf und poste dann den aktuellen Stand.
Steht in "Selected_Timebase".
> Was den PC anbetrifft: Es müsste doch ohne riesigen Aufwand> möglich sein, nach Druck auf den Button "Quick-Print" die> Kanaleinstellungen und Messdaten über RS232 rauszuhauen. Dann> würde man ja sehen, was der eine oder andere damit anfängt.
Könnte man machen, ist nur eine Frage der Prioritäten.
Hayo
Hallo,
Hayo W. schrieb:
> @Martin> wenn ich mir Deine und meine Werte so ansehe, scheint mir, dass WELEC da> eine feste Korrektur von 10 nS zwischen Kanal 1 + 2 in der originalen FW> eingebaut hat.
Das wuerde auch den Bug bestaetigen, den ich mit der originalen 1.4 FW
hab', wenn ich bei nem Snapshot (unerlaubterweise vmtl.) die
Zeitbasis aendere. Dann verschiebt sich Ch2 zu Ch1 nochmal um ~10nS.
Schalte ich wieder auf die Zeitbasis, mit der ich den Snapshot gemacht
habe, ist der zusaetzliche Versatz im Snapshot wieder weg.
Halllo Hayo,
ließe sich das nicht "dynamischer" gestalten? Ich könnte mir dazu einen
"Routine" im Utility-Menu namens "Zeitversatz" vorstellen, mit einer Art
Untermenu, in der man den zu korrigierenden Kanal wählt.
Kanal 1 dient als Referenz, nun wählt man einen der anderen Kanäle (2
bis 4) und gleicht über Drehen des Menu-Encoders solange, bis der
gewählte Kanal zeitlich mit Kanal 1 übereinstimmt.
Das hätte den Vorteil, dass jeder den Zeitversatz an seinem Gerät
individuell einstellen kann.
Beste Grüße, branadic
Hallo,
@branadic:
Bravo, ganz meine Meinung. So viel Flexibilität wie möglich,
Beschränkungen nur wo nötig.
Gruß, brunowe
P.S.: Natürlich hab ich heute wieder niemanden telefonisch bei Welec
erreicht. Es ist einfach ein Trauerspiel!
Sag ich ja - sind in Italien!
@branadic
Das mit dem Individuellen Delay-Abgleich können wir natürlich machen,
das wäre sicherlich die eleganteste Lösung
@Niklas
Wenn Du was zum Entwickeln haben möchtest, kann ich Dir über die RS232
Daten schicken, die kannst Du dann auf der PC-Seite verwursten. Das
wären zuerst einmal nur die Signaldaten und einige Parameter, da ich zur
Zeit an einer anderen Baustelle zu tun habe. Ich könnte das auf Quick
Print Button legen. Wäre Dir das recht?
Hayo
Hallo Hayo,
an der QM-Front hat sich die Erkenntnis ergeben, dass es möglich eine
einzigen Funktion über 2423 Programmzeilen zu erstrecken, ohne einen
einzigen Kommentar zu hinterlassen. g
Die FFT wird wohl früher fertig ;-)
Gruß,
Stefan
Hallo,
Hayo W. schrieb:
> @Niklas> Wenn Du was zum Entwickeln haben möchtest, kann ich Dir über die RS232> Daten schicken, die kannst Du dann auf der PC-Seite verwursten. Das> wären zuerst einmal nur die Signaldaten und einige Parameter, da ich zur> Zeit an einer anderen Baustelle zu tun habe. Ich könnte das auf Quick> Print Button legen. Wäre Dir das recht?
Jau, das passt. Ich werd' auch am WE mal schauen, dass ich
CDK4Nios bei mir zum Laufen bekomme, dann kann ich evtl.
auch selbst Hand anlegen.
@Stefan
Dann weißt Du ja auch warum ich da bislang noch nicht rangegangen bin.
Das mit den nicht vorhandenen Kommentaren zieht sich durch die Ganze
Software. Ungefähr 95% der Kommentare die Du jetzt in der Software
findest sind von mir nachträglich eingefügt für besseres Verständnis.
@Kristian
Hm, die Werte weichen ja ziemlich ab. Na mal abwarten was noch so kommt.
Gruß Hayo
Hallo Hayo,
hier mal die aktuelle Version. Die Geschwindigkeit ist jetzt
ganz akzeptabel, bisschen was geht wahrscheinlich noch.
Es wäre jetzt interessant für den Rollmode nur noch die
benötigte Bytezahl zu lesen, da dieses insgesamt schon recht
lange dauert.
Gruß, Guido
Hier meine Delayzeiten.
By the way: mit hohen Frequenzen (50 & 60 MHz Oszillatoren) hatte ich
einige Probleme mit dem Triggern. Das Signal steht dann nicht still und
springt hin und her.
Michel
Ich hatte gestern mal Verucht Wittig per Mail zu ereichen. Heute kam
folgende Antwort:
Lieber Kurt,
vielen Dank auch nochmal für Ihre Anfrage zur Veröffentlichung
des Chip-Designs. Wir haben kein Problem von seitens Altera.
Unser Problem besteht bei einer Veröffentlichung, dass wir
eine Gemeinsamentwicklung mit einem namhaften Oszilloskophersteller
hatten, die auch einiges an IP zugesteuert hat. Deshalb konnten
wir keine Unterstützung in diesem Fall beibringen.
Bitte haben Sie Verständnis, dass wir nicht weiterhelfen können.
Wir selbst hätten auch keine Probleme die Veröffentlichung vorzunehmen.
Es sind also rechte an Dritten, die wir verletzen würden...
Das können Sie auch so an Ihre Gemeinschaft weiterleiten, so dass
bekannt wird, dass wir deshalb nicht weiterhelfen können.
Viele Grüße
Thomas
Zwei Doofe ein Gedanke...
Ich hatte gestern ebenfalls eine Mail an Wittig geschrieben. Hab exakt
die gleiche Mail als Antwort bekommen. Man hat sich noch nicht einmal
die Mühe gemacht die Anrede auf meinen Namen hin anzupassen. Ab heute
heiße ich also Kurt.
Beste Grüße, branadic alias Kurt
Dann gibts da draußen noch weitere Oszilloskope mit dem Design? Oh je
Oder sollten wir uns lieber freuen, dass es im FPGA nicht so schlimm
sein kann, wie allgemein angenommen?
So würde ich das nicht unbedingt formulieren, zumindest noch nicht.
Anscheinend ist man da aber an einer neuen Sache dran. Zumindest die
Website und ein Blick auf die Bildchen über dem Site Menu lassen darauf
spekulieren:
http://www.wittig-technologies.com.br/company.php
Beste Grüße, branadic
Genau, siehe auch Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
@Stefan,
Es ging ja auch nicht nur darum den FPGA zu debuggen, sondern auch Teile
der Hardwareansteuerung einzubauen, damit diese den Softcore nicht mehr
belasten.
Die Delays scheinen aber auch vom Tastkopf abzuhängen. In die Lösung des
Problems sollte man meiner Meinung nach jetzt nicht viel Energie stecken
weil es für langsamere Signale keine Rolle spielt und das Oszi für HF
zur Zeit noch nicht zu gebrauchen ist.
Hallo Kurt,
man kann auch richtig schnelle Signale messen, solange man nicht über
einen best. Signalpegel (am ADC) kommt.
In der Anlage siehst du einen 140MHz_Sinus von meinem selbstgebauten DDS
Signalgenerator. Wenn ich den Signalpegel aber nur etwas erhöhe, bzw. in
den 1V/Div Messbereich runter schalte, fängt das Oszillieren an und
macht eine sinnvolle Darstellung absolut unmöglich.
Eine Schwebung oder Aliasing konnte ich auch nicht feststellen.
Gerade weil die Delays etwas von den Tastköpfen abhängen, halte ich eine
individuelle, einstellbare Anpassung für so wichtig!
Gruß, brunowe
Hallo Bruno,
so gesehen hast du natürlich Recht. Da brauchen wir aber bald schon
Untermenüs weil die Softkeys knapp werden. ;-)
Gibt es irgendwo eine Beschreibung von deinem DDS?
Mfg,
Kurt
Kurt Bohnen schrieb:
> Die Delays scheinen aber auch vom Tastkopf abzuhängen.
Nein bei mir nicht. Ich habe extra die Tastköpfe bei jeder Messung
getauscht - mit dem gleichen Ergebnis
> In die Lösung des Problems sollte man meiner Meinung nach> jetzt nicht viel Energie stecken> weil es für langsamere Signale keine Rolle spielt und das Oszi für HF> zur Zeit noch nicht zu gebrauchen ist.
Meine Messungen habe ich mit einem 5MHz Rechteck durchgeführt. Selbst
bei dieser Frequenz fand ich das schon recht störend. Der Aufwand für
eine Mittelwertkompensation (wie in der originalen FW) ist recht gering
und reduziert das Problem schon ziemlich. Nur für den manuellen Abgleich
müßte man einen etwas höheren Aufwand betreiben.
Gruß Hayo
An die GERMSloader-Bastler:
Es wäre schön, wenn beim Dumping des Flashes auch die Prüfsummen
berechnet und vergleichen würden. Im Falle eines Fehlers kann dann die
Zeile einfach nochmals angefordert werden. Einerseits würde ich damit
die Funktion überhaupt erst nutzen können (mein toller Port),
andererseits ist somit für alle sichergestellt, dass der Dump 100%
korrekt erfolgt ist.
Kurzer Zwischenstand:
Ich habe die letzten Tage damit zugebracht die FFT komplett auf Integer
umzustellen und das letzte an Performance herauszukitzeln. Ich denke es
kann sich sehen lassen. Der Geschwindigkeitsgewinn liegt bei etwa Faktor
8 bis 10. Das ist schon recht anständig wenn man bedenkt dass die
Routine an sich ja eigentlich schon auf Geschwindigkeit optimiert war.
Die Geschwindigkeit liegt jetzt bei 2 bis 3 FFTs pro Sekunde gegenüber 2
bis 4 Sekunden pro FFT vorher.
Jetzt werde ich mal das Drumherum programmieren, damit man das auch
anständig benutzen kann.
Gruß Hayo
Hallo liebe Gemeinde,
dieses Wochenende wird es mal kein neues Release geben, die Menüführung
und Einstellmöglichkeiten für die FFT im Menü sind noch zu unausgereift.
Ich denke da ist es besser erst einen etwas runderen Zwischenstand
abzuwarten. Vielleicht kann ich bis dahin ja auch außer den Neuerungen
von Guido auch noch weitere Verbesserungen von Euch mit einbauen.
Gruß Hayo
Hallo Hayo,
bin momentan etwas knapp mit der Zeit. Weiß noch nicht, obs deshalb von
mir was neues gibt. Aber ich habe gerade deinen "Shift Mode" im Einsatz.
Ist gerade echt nützlich.
Gruß,
Stefan
Hi Stefan,
das höre ich gerne. Ja bei mit wird es auch etwas dauern, ich habe
gerade mal eine To Do Liste gemacht was ich so für eine komfortable
Bedienung alles noch einbauen muß, da gibt es ordentlich was zu tun.
Guten Start in die neue Woche
Hayo
Hallo Hayo,
>Jürgen schrieb:>>> Hatte gestern irgendwie Probleme mit dem Ch3 und der>> Vertikalauflösung/Verstärkungsumschaltung. Habe deshalb in der SW>> gesucht und in der Funktion "Hardware::SetSwitches(..)" eine>> Unregelmäßigkeit gefunden: Entweder stimmen die Adressen oder die>> KOmmentare?>> Ch3 tanzt aus der Reihe! Vielleicht hast Du dort schon>> "tiefer gebohrt". Scheint aber trotzdem zu funktionieren?!>>Nein, da war ich noch nicht dran, wenn Du da Hinweise findest immer her>damit.>>Hayo
habe mal versucht die Sache anhand der Sourcen und des Stromlaufplanes
nachzuvollziehen. In der o.g. Funktion ist also nur der Kommentar bei
Ch3 bezüglich der Adresse falsch! Für die Ch-Switches ergeben sich
folgende Adressen:
Ch1 = adr 7, Ch2 = adr 5, Ch3 = adr 1, Ch4 = adr 3, ext.Trig = adr 2,
DAC1+2 = adr 6, DAC 3+4 = adr 4. Diese Belegung sieht man auch im
Stromlaufplan IC U25( 74HC238). Die dort unbezeichneten Ausgänge Y0-Y7
entsprechen diesen Adressen und Bezeichnungen können ergänzt werden.
Noch eine Eränzung der Bugliste ist mir dabei mit dem Probe-Ausgang
aufgefallen: Bei ext.Triggerung und Trig.Modus Normal wird auf Ch3 und
Ch4 nur jeder zweite Screen korrekt dargestellt. Dazwischen wird für
CH3+4 immer eine gerade Linie gezeigt. Ch1+2 werden richtig
dargestellt.Die Triggerung wird aber nicht ordentlich ausgeführt (bleibt
immer Auto Mode?).
Beste Grüße,
Jürgen
Hi Jürgen,
> In der o.g. Funktion ist also nur der Kommentar bei Ch3 bezüglich> der Adresse falsch!
Immerhin haben wir jetzt wieder weitere Details geklärt und können davon
ausgehen, dass zumindest hier alles funktioniert wie es soll. Ich werde
mal die Kommentare in der Funktion überarbeiten (immerhin sind überhaupt
irgendwelche Kommentare drin!).
> Bei ext.Triggerung und Trig.Modus Normal wird auf Ch3 und> Ch4 nur jeder zweite Screen korrekt dargestellt.
Danke für den Hinweis das werde ich mal näher untersuchen. Interessant
wäre, ob das ein Bug ist den ich eingebaut habe, oder ob der bei der
originalen FW auch auftritt.
Gruß Hayo
Ach so ja, der Bug ist auch in der Version 1.4 so enthalten. Ausserdem
fällt mir jetzt noch ein, daß die Drehrichtung für die externe
Triggerschwelle ev. entgegengesetzt der übrigen Einsteller ist (Soll: im
Uhrzeigersinn drehen = erhöhen ? )
Gruß Jürgen
Ok, gut zu wissen, dass das auch in der orig. FW auftritt.
Die Drehrichtungen sind zum Teil etwas durcheinander, und waren mir auch
schon immer ein Dorn im Auge. Das wollte ich evtl. mal umstellen auf
eine durchgängige Drehrichtung
- im Uhrzeigersinn erhöhen
- gegen den Uhrzeigersinn verkleinern
Gruß Hayo
Hallo,
ich hab' heute mal CDK4Nios eingerichtet und kann schon einzelne
Planes in S/W als Stream rausschreiben, ins PPM-Format wandeln
und darstellen.
Soweit ich den Aufbau bis jetzt verstehe besteht die GUI
aus etlichen Planes, die uebereinander gelagert schlieszlich
die sichtbare Ausgabe ergeben.
Um einen 1:1 Screenshot ueber "Quick Print->Save to BMP" usw.
rauszuschreiben muesste man also alle Planes in der richtigen
Reihenfolge aufeinander legen und kombinieren, d.h., Pixel
sichtbar/set oder nicht sichtbar/!set.
Dazu nun folgende Fragen an die Leute die schon laenger mit
der Firmware zutun haben:
* Ist mein Verstaendnis soweit richtig?
* Ist die Darstellreihenfolge der Planes bekannt?
Zudem noch die Frage, inwieweit der ganze Akt in der Firmware oder
einem PC-Programm erledigt werden soll, d.h., wieviel Flashspeicher
geopfert werden soll/kann.
Gruss,
Niklas
Hi Niklas,
ich denke dass der Aufwand einen direkten Screenshot zu machen recht
hoch ist. Da ist es doch wesentlich einfacher nur die Signaldaten und
Parameter zu übertragen und dann das Signal zu rekonstruieren.
Ja Du hast das schon richtig gesehen mit den Planes. Es gibt eigentlich
für Alles und jede Ausgabe eine eigene Plane. Von der Plane abhängig ist
auch die Farbe, da die Farben immer pro Plane eingestellt werden. Welche
Planes da so auf den Schirm übertragen werden und in welcher Folge
kannst
Du in TransferPlanes() sehen (in Hardware_t.cpp Zeile 21245).
Flashspeicher ist knapp, da dort die ganzen Signale gespeichert werden,
siehe die von mir hier schon mehrfach veröffentlichten Memory Maps
(gibts
auch in Google Groups). Ich habe jetzt schon Probleme die
trigonometrischen Tabellen für die FFT dort abzulegen.
D.h. dafür müßte man dann Signalspeicher hergeben.
Gruß Hayo
Hallo Hayo,
ich habe gerade fix mal meinen Code erweitert um "alle" Planes
zu beruecksichtigen und einen Proof-of-Concept S/W Screenshot
erstellt. Dabei habe ich noch nicht die Reihenfolge in
TransferPlanes() beruecksichtigt, daher fehlen offensichtlich
einige Texte.
Bzgl. der Farben ist mir aufgefallen, dass da einige Altlasten
im Code zurueck liegen, die clFarbe Konstanten sind definiert
und anscheinend nirgendwo referenziert. Auch stoeren mich
bei dem bissl Code was ich bisher sah viele doppelte oder nicht
durchgehend benutzte Konstanten, wie auch fuer die Planes.
Da muesste mal aufgeraeumt werden. Wie sieht da die Planung aus?
Ich waere natuerlich bereit da mit anzupacken. Ich sehe, dass
ihr wohl bisher eher vorsichtig auskommentiert und teilweise
neu implementiert habt, um nicht gleich alles zu brechen.
Anbei der PoC-Screenshot.
Um das ganze darstellbar zu machen hab' ich einen PPM-Header
hinzugefuegt und 0/1 fuer Pixel gesetzt/ungesetzt in erfundene
Farbwerte gewandelt. PPM habe ich nur gewaehlt, weil ich mich
da schon auskannte ;)
Natuerlich fehlen da noch die Original-Farben und eine platzsparende
Ausgabe (sind ja so 307200+480 Bytes die geschrieben werden auf RS232),
aber es ist m.E. mit geringerem Aufwand als erwartet machbar.
Gruss,
Niklas
Hallo,
@ Niklas O. (nevm): Soweit ich das verstanden habe, wird nicht
alles in die Planes gezeichnet. Die sind ja nur ein Puffer, der
dann in den Videospeicher transferiert wird. Ich meine, dass z.B.
Pixelp direkt in den Videospeicher schreibt, weil da ganz andere
Adressen verwendet werden. Das solltest du vllt. mal anschauen.
Gruß, Guido
Niklas O. schrieb:
> ich habe gerade fix mal meinen Code erweitert um "alle" Planes> zu beruecksichtigen und einen Proof-of-Concept S/W Screenshot> erstellt. Dabei habe ich noch nicht die Reihenfolge in
Super! Genau sowas will ich schon immer haben, das ewige Abfotografieren
des Bildschirms geht mir gewaltig auf den Zeiger. Nun das ganze einmal
für Linux bitte. :D
/Hannes
Hallo,
ich hab' noch fix RLE Kompression fuer die Datenuebertragung(*)
eingebaut und blende ein paar Planes(**) aus damit man bei der
S/W Version die Beschriftungen lesen kann.
Damit kann man nun schonmal ein wenig anfangen.
Das Ganze samt Ausleseprogramm in C und kurzer Beschreibung
im Anhang.
Falls ich heute Abend Zeit habe geht's dann weiter an die
farbige Ausgabe. Dazu werde ich wahrscheinlich die Planes
einzeln exportieren und ausserhalb des DSOs wieder eingefaerbt
zusammensetzen. Haette auch den Nebennutzen einzelne unwichtige
Sachen, etwa fuer Dokumentationszwecke, wieder ausblenden zu koennen.
@Guido:
Soweit ich sehe wird PIXELP() mit den selben Speicherstellen
aufgerufen die ich auch verwende. Genau angeschaut habe ich
mir das allerdings noch nicht.
Gruss,
Niklas
(*) Etwa 10-15kB Daten pro Screenshot.
(**) Jene Planes die die Softbutton-Beschriftungen
einrahmen/untermauern.
Hallo Zusammen,
für alle die es noch nicht mitbekommen haben, weil sie im
Hardware-Thread zu selten vorbei schauen, ergeht hier noch einmal der
Hinweis. Ab sofort könnt ihr euch für Schirmbleche vormerken. Wie und wo
erfahrt ihr im entsprechenden Beitrag:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
Ich hoffe auf zahlreiche Meldungen.
Beste Grüße, branadic
Hallo Niklas,
Du gehst ja mächtig zur Sache. Das sieht schon wirklich prima aus. Ich
hätte nicht erwartet, dass da so schnell solche Ergebnisse zu erzielen
sind. Echt super.
> Bzgl. der Farben ist mir aufgefallen, dass da einige Altlasten> im Code zurueck liegen, die clFarbe Konstanten sind definiert> und anscheinend nirgendwo referenziert. Auch stoeren mich> bei dem bissl Code was ich bisher sah viele doppelte oder nicht> durchgehend benutzte Konstanten, wie auch fuer die Planes.
Oh ja, wenn wir von etwas ausreichend haben, dann sind es Altlasten. Es
sind leider so viele, dass wir nur Stück für Stück vorankommen.
> Da muesste mal aufgeraeumt werden.
Allerdings!
> Wie sieht da die Planung aus?
Zur Zeit gibt es im Wesentlichen folgende Hotspots:
- die Hardwareecke versucht Designfehler auf der Platine
aufzuspüren und zu verbessern.
- ebenfalls der Hardwareecke zugeordnet sind die Kollegen
die an anderen FPGA-Designs arbeiten.
- in der Softwareecke versuchen wir das Assemblercoding
möglichst ohne Performanceverluste nach C zu portieren (Guido)
- an der Überarbeitung der Quick Measure Funktion ist Stefan dran
- einige der Forumsbesucher testen und schreiben Fehlerberichte
- einige sind auch einfach nur so im Coding unterwegs geben
hier und da gute Hinweise auf mögliche Fehler.
- ich bin zur Zeit an der FFT-Implementierung dran
Du siehst es sind noch eine Menge Themen offen.
> Ich waere natuerlich bereit da mit anzupacken.
Das ist prima. Seit sich hier die Anzahl der Hilfswilligen so erhöht hat
geht es deutlich schneller voran und wir können fast jede Woche ein
neues Release mit zig Verbesserungen rausbringen.
> Ich sehe, dass ihr wohl bisher eher vorsichtig auskommentiert> und teilweise neu implementiert habt, um nicht gleich alles> zu brechen.
Ja, wir wollen das möglichst so machen, dass wir immer ein einigermaßen
stabiles Release haben mit dem man auch richtig arbeiten kann. Bislang
haben wir das so gehandhabt, dass ich die neuen Release rausgegeben habe
und die Änderungen der anderen Entwickler mit eingebaut habe. Das läuft
auch ganz gut und verhindert, das es zig Versionen mit unterschiedlichem
Stand gibt. So können immer alle auf den gleichen neuen Stand wieder
aufsetzen mit Ihrem nächsten Entwicklungsschritt. Auch bei den Tests ist
das wegen der Vergleichbarkeit der Ergebnisse sehr Hilfreich.
Gruß Hayo
Kurt Bohnen schrieb:
> Evtl. wäre später auch ein USB Host mit dem Vinculum sinnvoll, damit man> die Screenshots direkt auf den Stick speichern kann.
Hallo Kurt,
da muss ich dich leider enttäuschen. Im Gerät steckt ein Cypress EZ-USB
FX1, der nicht als Hostcontroller taugt. Da müsste also eine
Zusatzplatine entwickelt werden...
Wenn wir gerade schon dabei sind: Ich habe am Wochenende nach dem
JTAG-Zugang zum 2. FPGA der 20x4er gesucht. Leider kam heraus, dass
vergessen wurde, TCK an den 2. FPGA zu routen, aber das kennen wir ja
nicht anders von den Wittigs.
Nichts desto trotz habe ich eine interessante Entdeckung dabei gemacht.
Direkt oberhalb des 2. FPGA, neben dem Steckverbinder zum Frontpanel,
sind 8 ungenutzte Pins des 2. FPGA auf Pads geführt. Hier könnte evtl.
eine Art Erweiterungsschnittstelle realisiert werden für Nutzer der
20x4-Geräte (die 20x2-Eigentümer müssten dazu leider schon direkt an die
BGA-Bälle der Pins, die vom 1. FPGA kommen, ran. Haare spalten (der
Länge nach) ist glaube ich einfacher).
Mindestens aber könnte dort z.B. ein SD-Cardreader angebracht werden.
Soviel zur Hardware, denn das ist hier der Softwarethread!
P.S. das nächste FPGA-Design zum "Spielen" lässt leider noch auf sich
warten, da noch einige grundlegende Umstrukturierungen ausstehen, da ich
mich mit einigen Fiesigkeiten lange aufgehalten habe. Sorry! Aber
Downsampling und Timebases funktionieren, mittlerweile auch korrekt.
Hallo Daniel,
das mit dem EZ-USB ist schon klar.
Für den VNC1L-1A (Vinculum) USB-Controller gibt es eine fertige Firmware
(VDAP) die alle Aufgaben der Ansteuerung eines USB Sticks inkl FAT
realisiert.
Man muss nur einige Parameter über SPI oder UART übergeben, und der
Vinculum schiebt die Daten auf den Stick.
Siehe auch Beitrag "USB-Stick am Mikrocontroller VNC1L"
Ich selbst habe sowas noch nicht gemacht und hoffe es trotzdem richtig
verstanden zu haben.
Der Hinweis im Firmware-Thread weil es vieleicht sinnvoll ist, einen
kompletten Screendump inkl. Dateiheader im Oszi zusammenzusetzen. Aber
darüber muss mann weiter nachdenken...
Meine Wunschvorstellungen für den Screenshot:
-Farbe (ok, ist in Arbeit)
-Auslösen durch Tastenkombination(nen z.B. 1 x RAW (durch ext. Programm
manipulierbar) 1x als BMP o.ä. (also gleich verwendbar)
-Ausgabe seriell als Z-Modem (also so, das gleich der "Abspeichern"
Dialog aufpeppt
So ist ein Screenshot imho in der Praxis am schnellsten gemacht.
Was in den Flash passt, müssen nat. die Programmierer entscheiden.....
elgodil
Auch wenn Abfotografieren bald nicht mehr State of the Art ist ;-)
(wenn Niklas da so weitermacht) hier ein Screenshot einer
Logarithmierten FFT.
Ich freue mich, dass ich es geschafft habe die Logarithmierung zu
implementieren, ohne spürbaren Performanceverlust gegenüber der
liniearen Darstellung.
Das war nicht von Anfang an so! Erste Versuche mit der originalen
Bibliotheksfunktion log10() haben massive Performanceverluste nach sich
gezogen und die Wiederholrate auf 5 S pro FFT runtergedrückt - trotz der
optmierten FFT-Routinen.
Das sieht schon alles soweit ganz gut aus, so dass ich hoffe zum
nächsten Wochenende die nächste Beta rausgeben zu können.
Gruß Hayo
Bei mir gibts noch nix neues. ;-) Hab gerade wieder ne Stunde damit
verbracht, denn Code zu verstehen. Aber der übersteigt mein
Denkvermögen. Hundert Variablen, die irgendwie miteinander verknüpfts
sind, Variablen die scheinbar nie gesetzt werden, hunderte
Fallunterscheidungen,...
Ich glaube, es ist leichter den Code neu zu schreiben, als da
rumzufrickeln.
Gruß,
Stefan
Hallo,
so, ich bin dann noch dazu gekommen die Screenshot-Funktion
auf farbige Ausgabe zu erweitern. Wie angekuendigt exportiere
ich die Planes einzeln. Das Programm speichert diese auch
einzeln ab, was vllt. auch fuer die Entwicklung interessant ist.
Was mir schon auffiel: Die Plane fuer den Ch 4 wird "missbraucht"
um die roten Pfeile und das Stop(p)-Schild zu malen.
Diff, fertig kompilierte TomCat.ram und C-Programm wie beim
letzten Mal schon im angehaengten .tgz. Alles weitere und
Changelog in der README-Datei.
Dem C-Programm steht btw. nichts entgegen, nicht auch mit Cygwin
oder MinGW fuer Windows kompiliert zu werden. In der kurzen
Zeit hab' ich (auch mangels Windows mit installiertem Cygwin
oder anderem Environment) mich noch nicht darum gekuemmert.
Falls fuer Windows-User die PGM/PPM Bildformate ein Problem
darstellen laesst sich das sicher auch zu BMP umstricken, wie
schon gesagt, wird nur verwendet da ich mich damit schon
auskannte.
@elgodil:
> -Auslösen durch Tastenkombination(nen z.B. 1 x RAW> (durch ext. Programm manipulierbar) 1x als BMP o.ä.> (also gleich verwendbar)
Tastenkombination waere ' bzw. # derzeit. BMP weisz
ich nicht was es da fuer Platzeinsparungsmoeglichkeiten
mit RLE und Paletten gibt und wie hoch da der jeweilige
Aufwand in der Firmware waere.
Generell bin ich auch fuer die Option der Ausgabe in einem
wohldefinierten und universellen Format.
Bei USB sehe das vmtl. schon anders aus da dort offensichtlich
die Uebertragungsgeschwindigkeit nicht so ins Gewicht faellt.
> -Ausgabe seriell als Z-Modem (also so, das gleich> der "Abspeichern" Dialog aufpeppt
Die Idee finde ich gut und es waere ein Schritt dahin,
das DSO mit "Boardmitteln" wie HypterTerm oder
Minicom ueber RS232 ansprechen zu koennen, auch
hinsichtlich der Ausgabe und Speicherung von
Messwerten direkt in eine (CSV-)Datei.
Ich werde dann aber wahrscheinlich X-Modem-1K-(CRC16) benutzen.
Gruss,
Niklas
...und hier noch ein Beispielscreenshot mit der Ausgabe
von Hayos Test-Signal-Funktion.
Hinweis: Auf dem Oszi uebermalt der lila Math-Channel
die Browse-Scroll-Leiste (wie heiszt die korrekt? ;)),
im Ausleseprogramm habe ich die Reihenfolge veraendert
damit die Ausgabe im Screenshot "korrekter" ist.
Hi Niklas,
Du bist ja mächtig fix! Ich bin noch nicht zum Ausprobieren gekommen,
aber ich denke ich werde das mal mit in die nächste Beta einbauen. Da
bietet es sich ja an das ins Print-Menü zu integrieren, damit man nicht
immer über das Terminal triggern muß.
Super!
Gruß Hayo
Könnte man bei der Gelegenheit gleich einen Pabst oder Verax reinhängen
und (da weniger Saugleistung benötigt wird) gleich noch die Drehzahl
runtersetzen (oder regeln)....
mal schauen
Hallo Hayo,
tolle Beschreibung! Ich hab mir erlaubt das ganze in SF einzufügen.
http://sourceforge.net/apps/trac/welecw2000a/wiki/Modifications
Noch etwas aus meiner Wishlist:
Bei meinen Tests ist es mir schon häufiger aufgefallen, das mein
HF-Signal von einer NF-Schwingung überlagert ist. Sehr schwer
gleichzeitig darzustellen- Man muss die Zeitbasis entsprechend verändern
und verliert dadurch zwangsläufig die andere Schwingung aus dem Auge.
Deshalb mein Wunsch nach einer zweiten Zeitbasis. D.h. es wäre doch
wunderbar wenn ich z.B. den Ch1 mit 50ns/Div und den CH2 mit z.b.
1ms/Div darstellen könnte. Gute, teure Oszis haben da ja eine echte
zweite Zeitbasis, aber eine entsprechende Darstellung zweier Kanäle mit
unterschiedlicher Zeitbasis sollte doch auch bei uns zu verwirklichen
sein? Im neuen VHDL Design werden wir eine entsprechende Verwirklichung
dieses Features auf jeden Fall anstreben.
Gruß, brunowe
P.S.: Meine Wunsch nach einer variablen Verstärkung (vertikales zooming)
ist auch noch in der ToDo list? Nicht das das verloren geht...
Hi Bruno,
wie soll denn die zweite Zeitbasis einzustellen sein? Der Einsteller für
die eigentliche Zeitbasis ist ja schon vergeben.
Eine Möglichkeit wäre ein Umschalter oder sowas in der Art. Wie ist das
denn an den besagten teuren DSOs realisiert?
Gruß Hayo
p.s. Hier geht nix verloren - letztlich werden alle Wünsche erfüllt
(hoffe ich)
Hallo,
also ich kenne jetzt konkret das HAMEG 1508-2 (Mixed Signal combi
scope), das HM 2005-2 (analog scope) und das Philips PM3092 mit 2
Zeitbasen. Wie die Umsetzung bei den analogen Oszis funktioniert ist
relativ einfach erklärt. Es gibt eine Haupt- Zeitbasis (die langsamere),
mit dieser wird das Signal getriggert und dargestellt. Innerhalb dieser
dargestellten Zeitspanne wird jetzt mit einem bestimmten, einstellbaren
delay, dieses Signal mit einer schnelleren Zeitbasis dargestellt. Es
kann damit also eine Ausschnittsvergrößerung dargestellt werden.
In unserem Fall müsste man das interessierende Signal auf zwei Kanälen
sampeln um eine entsprechende Vergrößerung darstellen zu können. Ich
würde auf jeden Fall den Kanal 1 fix mit der Hauptzeitbasis koppeln. Den
Ch2 dann, mit einer über das Menü (neuer Menüpkt. neben Probe), zu
aktivierenden zweiten Zeitbasis belegen. Zugegeben ist das
wahrscheinlich etwas komplexer zu verwirklichen (Trigger und delay
Problematik...) und bestimmt gibt es noch einen ganzen Stapel anderer,
wichtigerer Baustellen... Dennoch wollte ich dieses Feature einfach mal
erwähnen.
gruß, brunowe
Hallo,
könnte man nicht den Delayed-Mode so aufbohren, dass er zweimal
hintereinader sampled: Erstes Sample langsame Timebase, oberes
Bild zeichen. Zweites Sample schnelle Timebase unteres Bild
zeichnen, Und wieder von vorne.
Gruß, Guido
Den verstehe ich nicht so ganz.
Wo ist da der Unterschied zum jetzigen Delayed Modus, wenn man mal davon
absieht das es nicht mit zweimal sampeln realisiert ist sondern einfach
mit unterschiedlichen Zoomfaktoren.
Oder hab ich da was falsch verstanden?
Hayo
Der Vorteil liegt einfach in den beliebig vielen Zoomstufen.
In den meisten Bereichen haben wir bisher ja nur eine.
Der Nachteil ist halt die halbierte Aktualisierungsrate.
Vllt. ginge es auch eleganter, ich würde gerne mal mit den
Werten des TimeBaseRegisters spielen. Die nächsten 3/4 Wochen
werde ich aber nicht dazu kommen.
Gruß, Guido
Hallo,
ich hab hier als Beispiel die Darstellung von einem Fernseh-BAS Signal
angefügt. Mit unseren Mittel ist es derzeit nicht möglich, gleichzeitig
das komplette BAS Signal für eine Bild-Zeile und das
Trägerfrequenzsignal darzustellen... um solche und ähnlich komplexe
Signaldarstellung geht es im Prinzip.
Vielleicht noch ein wichtiger Punkt zur Anmerkung. Die Nutzung des
Delayed Modus hat natürlich den gravierenden Nachteil, das man für die
zeitl. gezoomte Darstellung die Spannungsauflösung nicht unabhängig von
der Hauptdarstellung einstellen kann. Ein echtes Manko meiner Meinung.
gruß, brunowe
Hallo werte Gemeinde,
leider bin ich heute nicht mehr ganz fertig geworden, so dass es die
neue Beta erst morgen geben wird. Schon mal soviel vorweg, das Warten
hat sich gelohnt. In das neue Release sind zahlreiche Bugfixes und
Korrekturen eingeflossen (Mathfunktion, Statusbar Kanalanzeige,
Menü-Updatelogik etc.). Desweiteren habe ich die C-Routinen von Guido
eingebaut und die neue Screenshot-Funktion von Niklas ins Quickprint
Menü integriert. Und als Highlight verfügt das W20xxA jetzt über eine
Spektralanalyse (FFT) die sich nicht vor der teurerer Geräte verstecken
muß.
Bis morgen
Hayo
Hallo,
ich hab' heute Nachmittag damit angefangen, eine minimale
ZModem-Implementation (derzeit ca. 290 Zeilen) fuer das DSO zu bauen.
Eigentlich wollte ich ja, weil wesentlich einfacher, XModem, aber dann
haette man den Dateiempfang per Hand anstoszen muessen.
Das ganze laeuft schonmal "im Trockenen", ich muss allerdings
noch eine zusaetzliche ISR Routine fuer den UART schreiben, der
die empfangenen Bytes zwischenbuffert bis diese weiterverarbeitet
werden.
(Derzeit mache ich ungefaehr:
Was, im Schneckentempo ;), zum ersten Testen okay ist.)
Screenshots (und Messdaten) sollen dann wahlweise "roh" wie
gehabt oder per ZModem direkt in eine Datei uebertragen werden
koennen.
Nun stellt sich aber noch ein Problem: Bei ZModem muss
ich dem Empfaenger den Dateinamen mitteilen. Wenn der
Dateiname bereits existiert wird je nach Implementation
des Empfaengers unterschiedlich verfahren: HyperTerminal
ueberschreibt wohl ungefragt, lrzsz ueberspringt die Datei.
Immer den gleichen Dateinamen benutzen scheidet also aus.
Optimal waere es natuerlich, wenn wir einen Dateinamen
mit Uhrzeit und Datum generieren koennten, aber das scheidet
wohl auch aus. Daher wuerde ich vorschlagen, eine mehrstellige,
aufsteigende Zahl anzuhaengen (also z.B. screen-nnnn.dat und
meas-nnnn.dat) aehnlich dem wie es Digitalkameras machen.
Dabei wuerde der letztverwendete Wert fest im Flash
gespeichert und so einen Reboot ueberdauern.
Vllt. hat jemand auch eine andere Idee?
Gruss,
Niklas
Hi Folks, new 0.80 Beta out now!
Wie versprochen die neue Version vollgepackt mit Neuerungen.
Die FFT ist noch nicht ganz durchgetestet und die Menüführung noch nicht
ganz perfekt, aber schon ganz ordentlich.
Ich bitte explizit um kritische Rückmeldungen.
@Niklas
Zu Deinem ZMODEM/XMODEM Problem kann ich leider nichts beitragen, aber
vielleicht kannst Du mir helfen. Ich habe Deine Routinen ins Quick Print
Menu eingehängt, aber das Programm scheint keine Verbindung zum DSO zu
kriegen.
Ich starte das Programm in einem Shellfenster und es signalisiert, dass
es wartet. Wenn ich dann den Screenshot starte friert der DSO-Bildschirm
kurz ein - und das war's. Das Programm reagiert aber nicht.
Stell ich mich da zu dusselig an oder hab ich was falsch verstanden?
Gruß Hayo
Ach ja,
nicht vergessen erstmal Default Setup zu drücken und dann die Timebase
zu drehen, damit die neuen Flashwerte für die FFT initialisiert werden.
Gruß Hayo
Lässt sich das nicht irgendwie automatisieren? Man kann doch bestimmt
die Firmwareversion irgendwo unter den Einstellungen ablegen, so dass
sie bei einem Flash nicht überschrieben wird, und dann beim Boot die
aktuelle gegen die Version im Configbereich prüfen und die ganze
Initialisierung dann bei Bedarf starten.
Ok, wirr ausgedrückt, aber sicher kommt rüber, was ich meine?
/Hannes
Hallo Hayo,
ich vermute mal, dass Du vergessen hast dem Programm
stdin auf das serielle USB-Device umzuleiten, ansonsten
liest das Programm nur die Tastatureingaben auf der
Konsole und wartet ewig.
Wichtig ist auch, dass das tty richtig konfiguriert ist,
wichtig ist der raw-Modus, da ich ohne Ruecksicht auf
Verluste (etwa Software-Handshake mit XON/XOFF) 8bit binaer
rausschreibe.
Bei mir mit USB<->RS232 Wandler sieht das z.B. dann so aus:
@Niklas O.
>ZModem-Implementation....XModem, aber dann haette man den Dateiempfang per Hand >anstoszen muessen.
Sach ich doch.... (sonst hättest du ja auch Kermit implementieren
können...)
>also z.B. screen-nnnn.dat und meas-nnnn.dat
Finde ich super, das Datum + Uhrzeit kriegt die Datei doch eh vom BS...
@alle Entwickler
tolle Sache - so wird aus dem Fehlkauf doch noch ein Schnäppchen
Frohes Schaffen!!
Niklas O. schrieb:
> Ich hoffe es klappt dann bei Dir auch.
Bei mir klappt es so auf jeden Fall, allerdings sind eine (bzw. mehrere)
Planes verschoben und es werden Planes mit ins Endbild reinkombiniert,
die gar nicht auf dem DSO angezeigt werden.
Auf dem angehängten Bild sieht man das verschobene Grid, das Signal
dagegen ist nicht verschoben (hab es vorher mit dem Testsignal
ausprobiert, nicht dass du denkst, ich hätte das Rauschen da im Anhang
mit dem DSO verglichen :D). Und die Plane mit dem Quickmeasusre-Display
war auf dem Scope selbst nicht sichtbar. Ich hatte vorher mal irgendwo
Quickmeas kurz ein- und wieder ausgeschaltet, vllt liegt es daran?
/Hannes
Hallo Hannes,
das sollte so natuerlich nicht sein, ich vermute mal, dass da
aus irgendwelchen Gruenden da andere, falsche, Speicheradressen fuer
die Pixeldaten ausgelesen werden -- oder es ist ein Fehler im
Ausleseprogramm. Offene Menues usw. sind egal.
Ich schaue mir das morgen in Ruhe an, welche Firmwareversion hast
Du denn verwendet?
Niklas
So der Reihe nach:
@Hannes
Das ist eine nette Idee, aber das funktioniert leider nur rückwärts wenn
überhaupt. Denn wenn ich neuen Speicherplatz für neue Variablen im Flash
belege, dann steht da erstmal nur irgendein Zufallswert drin. Durch das
Default Setup und das Verändern der Zeitbasis werden dann definierte
Werte ins Flash geschrieben und in Zukunft ist alles ok. Normalerweise
verwende ich jedesmal neue Adressen, so dass bei Verwendung älterer
Versionen keine Probleme auftreten. Nur in Ausnahmefällen ändere ich
bestehende Belegungen (z.B. bei vorherigen Inkonsistenzen).
@Niklas
Ok, dann hab ich mich wohl dusselig angestellt. Ich gebe zu, dass ich
nicht so der erfahrene Linux Kommandozeilenfreak bin. Zwar habe ich mich
langsam mit meiner Suse Distribution angefreundet, aber eigentlich bin
ich eher Windowsbenutzer und durch die FW-Programmierung auf die Vorzüge
von Linux aufmerksam geworden.
Danke für den Hinweis, ich werde das mal ausprobieren. Grundsätzlich
scheint es ja zu funktionieren wie ich dem Beitrag von Hannes entnehme.
@Elgodil
Wieso Fehlkauf? Ich hab mir die Teile gekauft weil ich wußte dass es da
was dran zu optmieren gibt. Und bevor einer fragt: Ja ich habe auch eine
Frau und Freunde und auch noch andere Interessen ;-)
@all
Wer nicht so richtig was mit der FFT-Funktion anzufangen weiß - nicht
verzweifeln, ich arbeite gerade an einer Anleitung mit
Hintergrundinformationen, die hab ich aber heute nicht mehr
fertiggekriegt, kommt aber in Kürze.
Gruß Hayo
Hayo W. schrieb:
> Hi Folks, new 0.80 Beta out now!>> Wie versprochen die neue Version vollgepackt mit Neuerungen.>> Die FFT ist noch nicht ganz durchgetestet und die Menüführung noch nicht> ganz perfekt, aber schon ganz ordentlich.>> Ich bitte explizit um kritische Rückmeldungen.
Hallo Hayo,
super Arbeit, die FFT funktioniert tatsächlich schon ziemlich gut. Was
mir noch fehlt ist eine Beschriftung der Frequenzachse. Rein statisch
mit Anfangsfrequenz + Delta/div würden schon ausreichen.
Ich hatte noch ein Problem beim Einstieg bzw. bei der Rückkehr aus der
FFT. Dabei haben sich immer mal wieder Kanal 3 und 4 (WL 2024)
eingeschaltet und zwar so, dass auf dem Monitor sichtbar die blaue und
rote Linie kommt, aber die blaue und rote LED aus blieben. Ausschalten
der beiden Kanäle ging über zunächst einschalten (LED an) und dann
wiederum ausschalten - dann waren sowohl die LED aus als auch die
Anzeige des Kanals auf dem Monitor aus.
Dass bei den QuickMeasurements noch (so gut wie) nichts funktioniert
liegt an der fehlenden Anpassung an das neue Grid - oder?
Bei den Quickmeasurements ist noch ein kleiner Schreibfehler drin
(vermutlich noch von der Welec-FW her): "Frequency" heißt dort
"Freqency" (also ohne "u"). Sicherlich eines der allerkleinsten Probleme
- dafür aber auch in wenigen Sekunden gefixt :-)
Super Arbeit - ist schön zu sehen, wie immer mehr geht!
Gruß,
Bernd
Hallo,
(siehe UPDATE unten)
ich hab' mal die Screenshot-Funktion in der aktuellen 0.80
bei mir getestet, im Verdacht, dass das von Hannes beobachtete
Problem etwas mit Aenderungen in der Firmware zutun hat.
Funktioniert allerdings weiter wie gehabt bei mir. Ich tappe
auch ziemlich im Dunkeln, woran es bei Hannes liegen kann.
Daher mal frage an alle die es testen koennen: Funktioniert es
bei euch korrekt?
@Hannes/demofreak:
Kannst Du mir ein Log der RS232 Ausgaben vom Oszi zukommen lassen?
(also stty ttyS0 115200 raw, cat /dev/ttyS0 > log,
Quick-Print->Save to PGM, warten bis Oszi wieder reagiert
und CTRL-C zum beenden von cat).
Dann koennte man eine Seite schonmal ausschlieszen.
UPDATE: Ich hab' gerade mal frisch FW in RAM eingespielt,
keine Veraenderungen an Schaltern, keine Drehgeber bewegt
und auch kein Default-Setup vorgenommen und direkt Screenshot,
und das Oszi schreibt wild komische Speicherinhalte raus mit
Textausgaben aus dem Programmcode.
Ergab 180984 Bytes (!) (statt 60-65K).
Das ganze durch das C-Programm gejagt, und siehe da, es
sieht erschreckend aehnlich zu Hannes Ausgabe aus.
D.h.: Bitte Default-Setup durchfuehren, Zeitbasen veraendern
usw. und nochmal Screenshot testen.
Den Effekt verstehe ich nicht so ganz, wo doch egtl. der RAM-Inhalt
ueberschrieben wird. @Hayo oder jemand anderes eine Idee?
Gruss,
Niklas
Mhm, nochmal kurz etwas im Firmware Code rumgeschaut:
In Hardware::Set_Vars_Default() werden zwar die von mir
verwendeten Konstanten mit den Speicheradressen der Planes
nicht gesetzt, aber ganz am Ende folgt ein ClearPlanes(),
was mir doch spontan in Anbetracht der beobachteten
Effekte ziemlich wichtig erscheint nach dem Laden der FW
ins RAM und vor Screenshot ;)
(Installierte FW ist bei mir btw. die Original 1.4)
D.h., Frage an @Hayo damit wohl erledigt.
Mehr bzgl. ZModem und Messdaten vllt. heute Abend.
Niklas
Niklas O. schrieb:
> D.h.: Bitte Default-Setup durchfuehren, Zeitbasen veraendern> usw. und nochmal Screenshot testen.
Hatte ich selbstverfreilich gemacht, direkt nach'm Boot unten rechts den
Knopf "Default Setup" und danach oben einmal hin- und hergedreht. Hab
ich jetzt eben nochmal gemacht, ohne Effekt.
/Hannes
Bernd O. schrieb:
> super Arbeit, die FFT funktioniert tatsächlich schon ziemlich gut. Was> mir noch fehlt ist eine Beschriftung der Frequenzachse. Rein statisch> mit Anfangsfrequenz + Delta/div würden schon ausreichen.
Ja, sowas ging mir auch schon durch den Kopf, allerdings ist das
statisch nicht möglich, da ja die Frequenzachse je nach eingestellter
Zeitbasis vatiiert. da müßte man also einen Refresh mit einbauen
> Ich hatte noch ein Problem beim Einstieg bzw. bei der Rückkehr aus der> FFT. Dabei haben sich immer mal wieder Kanal 3 und 4 (WL 2024)> eingeschaltet und zwar so, dass auf dem Monitor sichtbar die blaue und> rote Linie kommt, aber die blaue und rote LED aus blieben. Ausschalten> der beiden Kanäle ging über zunächst einschalten (LED an) und dann> wiederum ausschalten - dann waren sowohl die LED aus als auch die> Anzeige des Kanals auf dem Monitor aus.
Danke für den Tip, ich habe alle Tests nur auf dem Zweikanalgerät
gemacht weil es den leiseren Lüfter hat. Daher sind mir diese
Eigenheiten noch nicht aufgefallen.
> Dass bei den QuickMeasurements noch (so gut wie) nichts funktioniert> liegt an der fehlenden Anpassung an das neue Grid - oder?
Ja so ist es, da hab ich bis jetzt auch nichts geändert oder getestet.
Stefan hatte sich das mal angesehen und war eher nicht so begeistert...
> Bei den Quickmeasurements ist noch ein kleiner Schreibfehler drin> (vermutlich noch von der Welec-FW her): "Frequency" heißt dort> "Freqency" (also ohne "u"). Sicherlich eines der allerkleinsten Probleme> - dafür aber auch in wenigen Sekunden gefixt :-)
Kann ich ich mal fixen für die nächste Beta.
> Super Arbeit - ist schön zu sehen, wie immer mehr geht!>> Gruß,> Bernd
Danke,
Hayo
Da ist definitiv noch was krumm.
Wollte direkt nach dem Erstellen des obigen Screenshots nochmal ein Log
anfertigen, allerdings hat sich das Oszi nach Drücken von "Save to PGM"
dann aufgehängt. Also rebootet und nochmal versucht, Log zu schreiben.
Dabei wuchs die Logdatei auf über 300kb an, hab das dann ebenfalls
abgebrochen. Sah sowieso seltsam aus, es war nur Kanal 1 sichtbar und
unten links war ein Softbutton "Cancel" zu sehen, als ich den gedrückt
habe, bin ich im Quickmeasure gelandet (Cursor sichtbar und unten die
Einblendung der Messwerte).
Also nochmals rebootet und wieder versucht, Log zu schreiben. Das hab
ich dann ebenfalls bei reichlich 300kb abgebrochen und hier mal
angehängt. Das Oszi reagiert nicht, komischerweise war Triggerung auf
einmal auf PW statt auf Edge, das muss sich im Verlauf des
Datentransfers irgendwie geändert haben. Musste also wieder rebooten.
Hab jetzt dreimal "Save to PGM" gedrückt, ohne auf der Rechnerseite das
cat zum Logschreiben zu starten, dabei hängt sich das Oszi nicht auf.
[...]
Hängt irgendwie mit cat zusammen, hab gerade nochmal bissi rumgespielt.
Offenbar wird das Oszi "fernbedient". Kann mir zwar nicht so recht
denken, wie das gehen soll, weil ich ja die Daten von ttyS0 in eine
Datei schreibe und nicht umgedreht, aber es ist definitiv so. Bin beim
Rumdrücken auf dem Oszi mehrmals plötzlich im Quickmeasure-Menü
gelandet, Math hat sich lustig ein- und wieder ausgeschaltet und auch
die Triggerung war ab und an auf PW. Wenn cat nicht läuft, passiert
sowas (natürlich) nicht.
Hat cat ein Echo?
/Han-"Der Ratlose"-nes
Niklas O. schrieb:
> In Hardware::Set_Vars_Default() werden zwar die von mir> verwendeten Konstanten mit den Speicheradressen der Planes> nicht gesetzt, aber ganz am Ende folgt ein ClearPlanes(),
Hätte ich da irgendwelche Werte setzen müssen? Wenn ja dann kurz
Bescheid sagen damit ich das einbauen kann.
Hayo
@Hannes
Das hört sich für mich definitiv danach an, dass Daten in die Serielle
Schnittstelle (Richtung DSO) geschrieben werden. Denn was Du da
beschreibst ist genau das was man sonst via Terminal und Tastatur
fernsteuern kann.
Ansonsten hat es sich schon des Öfteren bei unerklärlichen
Merkwürdigkeiten bewährt einen frischen Flashdump einzuspielen.
Gruß Hayo
Johannes Studt schrieb:
> Hängt irgendwie mit cat zusammen, hab gerade nochmal bissi rumgespielt.> Offenbar wird das Oszi "fernbedient". Kann mir zwar nicht so recht> denken, wie das gehen soll, weil ich ja die Daten von ttyS0 in eine> Datei schreibe und nicht umgedreht, aber es ist definitiv so. Bin beim
ist da irgentwo noch das Echo eingeschaltet ?
Gruß,
Günter
Dass sich das so anhört, als wenn Daten in die serielle Schnittstelle
geschrieben werden, ist mir klar. :D Und welches Echo soll wo
angeschalten sein? Ich verwende cat, dass das echot, wäre mir neu.
stty -F /dev/ttyUSB0 raw 115200
cat /dev/ttyUSB0 > log
Desterwegen bin ich ja ratlos. ;)
Hab vorhin einen weiteren Logversuch bei ca. 300kb Dateigröße
abgebrochen (das Oszi war noch nicht fertig, sprich: reagierte noch
nicht) und einfach nicht weiter hingeschaut. Ein oder zwei Minuten
später stand das Oszi wieder im Quickmeasure. :D
Es lebt.
/Hannes
Hallo Hannes,
Dein Log sieht so aus als haette das DSO wie in einer
Endlosschleife immer und immer wieder Screenshots auf
RS232 ausgegeben.
Wenn ich hergehe, und den ersten aus der Log-Datei
wegwerfe, erhalte ich einen korrekten Screenshot
(siehe Anhang).
D.h.:
1
$ ./w2000a-screenshot < logalt
2
[..]
3
* Total bytes transferred: 59326
4
[..]
5
$ dd if=logalt of=logalt2 bs=1 skip=59326
6
[..]
7
$ ./w2000a-screenshot < logalt2
8
[..]
9
* Total bytes transferred: 61556
10
[..]
(Und das ist der angehaengte Screenshot als .png.
Genau so kann auch verfahren werden um die weiteren
zu extrahieren.)
Wenn man sich die Logdatei im (Hex)-Editor anschaut,
sieht man auch warum da der erste Screenshot bei
Dir kaputt ist. Nach dem Start-Marker S 0xFF kommen
zwei vmtl. gueltige Bytes und dann die Textausgabe
einer Test-Funktion, gefolgt vom Rest des Screenshots.
Warum die da erscheint/erscheinen kann hab' ich noch
nicht geschaut, vmtl. aus einer ISR heraus.
---
Bzgl. "Oszi aufhaengen" gehe ich daher auch davon aus
das es damit beschaeftigt ist auf RS232 auszugeben.
Da dies nicht passiert wenn kein Programm die Schnittstelle
ausliest deutet tatsaechlich darauf hin, dass da irgendwas
"geschrieben" wird. Aber cat kann es nicht sein, stdout
und stderr waeren ja die Konsole und nicht /dev/ttyS0.
Auch das unmotivierte Rumspringen in den Menues deutet
darauf hin, denn man kann ueber RS232 das Oszi fernsteuern.
(1-6 sind die Soft-Buttons, i,j,k,l sind die Kanaele usw. usf.)
Ich kann nur mutmaszen, wuerde aber auf falsche Konfiguration
des ttys tippen. Schau mal nach ob das bei Dir anders aussieht:
> Sah sowieso seltsam aus, es war nur Kanal 1 sichtbar und> unten links war ein Softbutton "Cancel" zu sehen [..]
Das hab' ich wenn ich ohne im GERMS-Monitor zu sein GERMSLoader.pl
aufrufe.
---
@alle:
Haben noch andere hier Probleme mit der Screenshot-Funktion?
Niklas
Hallo nochmal,
ich hab' leider Eure Nachrichten in der Zwischenzeit
erst jetzt gesehen.
Das echo wie Guenter und Hayo vermuten wird's wohl sein.
@Hayo:
> Hätte ich da irgendwelche Werte setzen müssen? Wenn ja dann kurz> Bescheid sagen damit ich das einbauen kann.
Nein :) Aber fuer die aufsteigende Zahl als Anhang bei den
ZModem-Dateinamen braeuchte ich dann wohl nen festen Speicherplatz
im Flash, vllt. kannst Du mir da nen Hint geben wo und wie ich
das am sinnvollsten anstelle.
Niklas
das ist genau die raw Einstellung und da ist echo noch an,
d.h. der tty-Treiber echo(ed) einkommende Zeichen,
deshalb mein Vorschlag noch ein -echo beim stty Befehl anzuhängen.
Gruß,
Günter
Niklas O. schrieb:
> Das hab' ich wenn ich ohne im GERMS-Monitor zu sein GERMSLoader.pl> aufrufe.
Ah, guter Hinweis. Das könnt ich sicher mit abfangen bzw. zumindestens
versuchen, herauszubekommen, ob ich ins Menü oder wirklich in den
GERMS-Monitor "reingucke".
Irgendwas anderes wollte ich doch letztens eh noch mit reinbauen...?
grübel
Ich werd echt alt.
/Hannes
Hallo Guenter,
Du hast absolut recht.
Ich nehme jetzt stark an, dass der Effekt den ich heute Morgen beim
eiligen Reproduzier-Versuch hatte genau darauf zurueckzufuehren ist,
ich hab' naemlich das ganze samt Dongle auch am Laptop getestet...
Niklas
Niklas O. schrieb:
> Nein :) Aber fuer die aufsteigende Zahl als Anhang bei den> ZModem-Dateinamen braeuchte ich dann wohl nen festen Speicherplatz> im Flash, vllt. kannst Du mir da nen Hint geben wo und wie ich> das am sinnvollsten anstelle.>> Niklas
Jupp, das machst Du in flash_t.cpp:
- Funktion AMDFlash::Write_Config_Flash() Zeile 1408 schreibt Daten in
den Konfigbereich. Da sind noch einige Plätze frei von buf[268] bis
buf[299]. Da könntest Du Dir einen von greifen.
- Funktion AMDFlash::Read_Config_Flash() Zeile 1800 liest die Daten
wieder ein.
Da ich mal annehme, das Du nicht jedesmal den gesamten Konfigbereich
schreiben und lesen willst, könntest Du die Funktionen einfach als
Vorlage für eigene Routinen nehmen mit denen Du dann Deine Daten ins
Flash schreibst und sie wieder ausliest.
Gruß Hayo
Johannes Studt schrieb:
> Irgendwas anderes wollte ich doch letztens eh noch mit reinbauen...?
Ja, bitte beim Dumping des Flashes einen Plausibilitätscheck einbauen:
Falls die Anzahl der Zeichen in einer Zeile nicht stimmt (zu viele oder
zu wenige), die Zeile erneut abfragen.
Ich hatte ja schon festgestellt, dass der GERMSmonitor leider keine
Prüfsumme ausspuckt, aber mein konkretes Problem ist ja nicht die
Verfälschung, sondern nur das Verschlucken oder Verdoppeln von Zeichen.
Schade, dass nichtmal ein Parity-Bit verwendet wird.
> Ich werd echt alt.
Tipp: Todo-Liste führen, fand ich sonst auch albern, hilft aber ungemein
=)
@Hayo und co, bzgl. Flash:
Da wir auch gerade dabei sind, einen Flash-Speichercontroller für das
FPGA-Redesign zu bauen, wollte ich mal fragen, ob denn eigentlich ALLE
Flash-Speicherbereiche mit sinnvollen Werten initialisiert werden, wenn
man auf Default Setup geht oder deine Firmware einspielt oder was auch
immer. Falls das nicht der Fall ist, sollten wir uns bezeiten schonmal
einen Up- und Downgrade-Weg zwischen deiner und unserer Firmware
überlegen.
Daniel H. schrieb:
> Tipp: Todo-Liste führen, fand ich sonst auch albern, hilft aber ungemein
Genau meine Taktik!
> @Hayo und co, bzgl. Flash:>> Da wir auch gerade dabei sind, einen Flash-Speichercontroller für das> FPGA-Redesign zu bauen, wollte ich mal fragen, ob denn eigentlich ALLE> Flash-Speicherbereiche mit sinnvollen Werten initialisiert werden, wenn> man auf Default Setup geht oder deine Firmware einspielt oder was auch> immer.
- wenn eine neue Firmware eingespielt wird, dann wird auch nur der
Progrmmbereich beschrieben. Alle anderen Bereiche bleiben unberührt.
- bei Default Setup wird überhaupt nicht auf den Flashspeicher
zugegriffen, weder lesend noch schreibend, sondern es werden nur
hart codierte Werte geladen.
- Der Flashspeicher wird eigentlich überhaupt nicht initialisiert.
Es werden lediglich einige Konfigwerte hineingeschrieben bzw.
ausgelesen. Desweiteren werden einige Bitmaps beim Start geladen.
Es können Signal im Speicher abgelegt werden, das wars auch schon.
Gruß Hayo
Okay, aber ich gehe eben von dem Fall aus, dass der Flash komplett von
uns verwurstet wurde und jemand nun zurück zu deinem Branch wechseln
will. Wir werden mit Sicherheit nicht die Config-Speicherbereiche
unangefasst lassen (können|wollen), daher meine Anfrage was passiert,
wenn dort "Müll" steht (oder Nullen oder so).
Dann startet das DSO erstmal völlig undefiniert. Im ungünstigsten Fall
hängt es sich auf -aarrgh, ansonsten hilft Default Setup und einmal an
der Timebase drehen, dann ist der Konfigbereich wieder initialisiert.
Das gilt allerdings nicht für den Bereich in dem die Bitmaps abgelegt
sind, die lassen sich nur durch das Einspielen eines Flashdumps wieder
restaurieren.
Gruß Hayo
Hallo,
FFT funktioniert wunderbar. Wenn dann noch die Beschriftung kommt und
evtl. ein Cursor ist es perfekt.
Hab heute was gesehen, was ich auch haben möchte ;-) Der Prof. hat sich
letzten Signalverlauf gespeichert und im Hintergrund zum aktuellen
Signal eingeblendet. Sehr praktisch, wenn man eine Veränderung
visualisieren möchte. Hoffentlich reicht der Speicher dafür noch g
Gruß,
Stefan
@Niklas
Nach Deinem Tip für die stty-Umleitung hat es dann auch bei mir
geklappt. Sehr praktisch. Ich mache damit gerade die FFT-Doku.
Prima Arbeit!
Hayo
Hallo Kurt,
> Hast du brauchbare und verständliche Infos zum ZMODEM?
ich schaetze mal Du spielst auf die IMHO nicht sonderlich
gute Originalbeschreibung von Forsberg an:
http://pauillac.inria.fr/~doligez/zmodem/zmodem.txt
(was anderes habe ich auch nicht gefunden)
Wenn man sich dazu vllt. noch ein paar fertige Implementationen
anschaut (andere als (l)rzsz) blickt man dann schon durch.
Gruss,
Niklas
Hallo
Habe die 0.80 probiert.
Funktioniert sehr gut :-) Auch das FFT :-)-- > Gratuliere!!
(Freue mich schon auf die Doku dazu :-) )
Was mir so beim Testen aufgefallen ist:
Das 1kHz Testsignal schaut mit 200-100ms/Dif fast genau so aus wie bei
1ms/Dif. :-(
Bei einem Analogen Osci würde man bei 100ms/Dif nur einen großen Balken
sehen...
Entsteht die falsche Anzeige durch das abtasten der ADC? Ist das
DSO-bedingt?
Bei anderen DSO auch so?
Könnte man das Rechnerisch irgendwie besser auswerten?
l.G. Roberto ( W2024A)
Hallo,
ich teste gerade mit der 0.75 und auch da ist ein Fehler in der
Zeitbasis, so wie Roberto es beschrieben hat.
Beim Test mit dem 1kHz Testsignal ergibt sich bei mir folgendes Bild:
Mit den Timebases bis 20ms/Div ist alles i.O. - Die Anzahl der
dargestellten Schwingungen stimmt mit Periodendauer des Signals überein.
* Bei 50ms/Div wird mir eine Periodendauer von 250ms suggeriert- eine
Periode geht über 5 Div!
* Bei 100ms/Div eine Periodendauer von 50ms.
* Bei 200ms/Div wieder eine Periodendauer von 250ms.
Bei noch langsameren Timebases zieht sich der Fehler konsequent weiter
durch.
Einmal abgesehen davon, dass eine Darstellung mit TB > 20ms/Div bei
unserer Auflösung nicht möglich ist (weniger Pixel zur Darstellung als
Schwingungen des Signals), so liegt wohl doch irgendwo noch ein
Berechnungsfehler bei den langsamen TB vor.
Gruß, brunowe
@Roberto + Bruno
Danke für den Hinweis. Das muß ich mal ausprobieren. Ich gebe zu, dass
die langsameren Zeitbasen nicht so oft zum Einsatz kommen und daher
Fehler auch nicht so schnell auffallen.
Gruß Hayo
So, dafür hier etwas Lesestoff.
Ich weiß, dass viele von Euch mit dem Thema vertraut sind, aber es gibt
wohl auch noch einige die sich damit noch nicht so beschäftigt haben
oder bei denen es schon länger her ist. So oder so ist es aber wohl für
alle ganz interessant die Theorie mal am eigenen W20xxA
nachzuvollziehen.
Leider ist das Ganze doch etwas umfangreicher geworden, so dass ich
erstmal nur eine deutsche Version fertiggestellt habe.
Sollte ich mich unverständlich ausgedrückt oder was falsches geschrieben
haben - nur keine Hemmungen, immer raus damit.
Viel Spaß beim Lesen und Ausprobieren
Hayo
Oh,
hab schon einen Fehler entdeckt! Auf Seite 8 ist natürlich das Doppelte
von 24,414 nicht 48,414 sondern 48,828. Ich hoffe Ihr könnt damit leben.
Hayo
Hallo,
kleines Update mal von mir: Stellt sich raus, dass meine
schnelle Idee vom Montag mit dem ersetzen der ISR fuer
den UART (Hardware::ISR_UART()) so nicht funktioniert.
Liegt daran wie die Original ISR in der Firmware benutzt
wird: Zeichen holen, Zeichen in Wust von if-Abfragen
in MenuKey Wert umsetzen, dann Buttonhandler() mit
MenuKey aufrufen.
Hardware::Buttonhandler() macht dann wiederum nen
select/switch-case-Konstrukt ueber MenuKey und ruft
evtl. darin noch weitere Funktionen auf.
Falls der Groschen noch nicht gefallen ist: Die ISR
ist zu diesem Zeitpunkt immer noch nicht verlassen!
..und sie wird natuerlich auch so lange sie nicht
fertig ist nicht nochmal aufgerufen.
Das ist, gelinde gesagt, nicht die uebliche Art,
wie man ISRs benutzt. Da ich nicht wirklich Lust
hatte den bestehenden Code weiter als noetig zu
lesen, ist mir das auch erst aufgefallen, als ich
mich wunderte, warum meine ISR nie zum Zuge kam.
Eine Loesung ohne den Original-ISR umzustricken
sehe ich im Moment nicht. Da es, wenn ich das
richtig sehe, in TomCat.cpp eine Main-Loop gibt,
waere es das einfachste, wenn im ISR nur eine
Variable geschrieben wird und dann ein Handler
die Eingabe interpretiert (wie das mit mehreren
zwischenzeitlich eingegangen Eingaben und
Prioritaet aussehen sollte habe ich noch nicht
ueberlegt).
Um das gewohnte alte Verhalten beizubehalten
koennte man alle Interrupts fuer die Laufzeit
der jeweiligen Funktion deaktivieren.
Bevor ich jedoch da einen chirurgischen Eingriff
beginne moechte ich noch Eure Meinung und Ideen
einholen.
@Hayo:
Hab' mal kurz durchgeblaetter, schoene Anleitung!
Gruss,
Niklas
Die nächsten Punkte auf der Roadmap sind:
- FFT Feinschliff - da warte ich mal auf Rückmeldungen
- Cursorfunktion an das neue Grid anpassen
- Cursor für die FFT nachrüsten
- Quick Measure komplett überarbeiten
Hayo
@Niklas
Ich gebe Dir Recht, die Implementierung der ISR ist recht
gewöhnungsbedürftig. Da es so viele andere Baustellen gab hatte ich mich
darauf beschränkt den Buttonhandler (es gab früher nur einen einzigen!)
aufzuteilen in einen Haupt-Buttonhandler und jeweils einen für die
Funktionstasten. Dadurch kann man sich immerhin schon mal besser
orientieren. Technisch gesehen hat das natürlich nichts geändert.
D.h. auch hier besteht noch Optimierungsbedarf, allerdings schien mir
das bislang nicht so dringlich wie die anderen Themen.
Hayo
Ach ja noch einer:
Das mit der ISR hatte der Programmierer auch beim Rollmode so gemacht -
weswegen das wohl auch nicht funktioniert hat. Ich konnte es zuerst gar
nicht glauben als das erste Mal gesehen hab dass die komplette Logik im
ISR des Timers abgefackelt wurde. Bei meiner Implementierung stehen 3
Zeilen im ISR - das war's.
Hayo
Hallo,
als Ergaenzung noch, da das vllt. nicht deutlich
rueber gekommen ist:
ZModem geht aufgrund des Protokolls und der noch
fehlenden Moeglichkeit, (alle) vom Terminalprogramm
ueber RS232 reinkommenden Zeichen zu lesen, erstmal
ohne weiteres nicht.
Messdaten einfach rauswerfen geht natuerlich trotzdem,
analog wie dies beim Screenshot gemacht wird.
Diesbzgl. hatte ich mir schon ueberlegt, die Parameter,
also Kanal, Zeitbasis usw., in Plaintext gefolgt von
den Samples, je als Byte, zu uebertragen und wieder mit
einem Programm fertig interpoliert in CSV oder gnuplot
Script zu wandeln.
Um ein paar zu uebertragende Bytes zu sparen koennte
man vornehmlich Deltas zwischen zwei Samples uebertragen,
z.B. 4 Bit breit. Inwieweit sich das ueberhaupt lohnt
muesste ich mal austesten -- in Anbetracht der maximal
16K*4 Samples die anfallen.
Meine Frage waere dann auch jetzt, was ihr Euch fuer
Ausgabeformate wuenschen wuerdet und ob das
Vorgehen insgesamt so in Ordnung ist.
Mein Plan sieht also dann so aus:
- Messdaten rausschreiben und Ausleseprogramm
- Screenshotprogramm: BMP-Dateien schreiben
(evtl. auch PNG, falls ich eine einfache Moeglichkeit finde)
- Ausleseprogramme auch fuer Windows und fertig kompiliert
- Firmware anpassen damit ZModem geht
(in keiner festen Reihenfolge, vmtl. nun ZModem zuletzt)
Niklas
@Bruno + Roberto
Die langsamen Zeitbasen sind ok. Habe gerade noch mal geprüft. Was Ihr
da gesehen habt ist Aliasing in seiner reinsten Form, d.h.
Scheinfrequenzen pur (siehe meine Veröffentlichung von heute). Wenn Ihr
in den Programming-Maps in der Timebase-Tabelle nachseht werdet Ihr
fündig.
Die kleinste Zeitbasis mit der ein 1 KHz Signal noch dargestellt werden
kann ist 20ms/div. Bei den langsameren Zeitbasen wird das Abtasttheorem
verletzt (insofern hat Roberto schon Recht, dass es sich um eine
DSO-spezifische Sache handelt). Und zwar müßt Ihr im Zeitbereich immer
berücksichtigen das zu der angezeigten Abtastrate noch der
Timebasefaktor kommt um das dass Signal reduziert wird.
Die tatsächliche Abtastrate ist dann also angezeigte Sa/s durch
Timefaktor. Bei 50 ms/div liegt die Abtastrate aber nur noch bei 5KSa/s
durch 5 = 1KSa/s also halb so viel wie eigentlich minimal nötig.
Bei den noch langsameren TB wird das natürlich noch extremer, so dass
täuschend echte Signale mit einer völlig anderen TB angezeigt werden.
Ihr habt ein wirklich schönes Beispiel dafür gefunden ;-)
Das Ganze gilt übrigens nicht für die FFT. Hier bleibt der
Timebasefaktor unberücksichtigt, so dass nur die tatsächlich angezeigte
TB maßgeblich ist.
Gruß Hayo
@Bruno,
nein, das habe ich auf dem Zettel. Allerdings sind nicht allzuviele
Rückmeldungen gekommen verglichen mit den Downloadanzeigen wenn hier was
veröffentlicht wird.
Die Korrektur ist eigentlich auch nicht sonderlich dramatisch, ich
wollte sie nur gleich in die C-Routinen von Guido mit einfließen lassen.
Da weiß ich aber nicht ab wann diese tatsächlich die Assemblerroutinen
ersetzen werden.
Ich könnte das natürlich, wenn starker Bedarf besteht, auch vorher
anders implementieren.
@Bernd
Der Bug mit Kanal 3 + 4 nach der Rückkehr von der FFT ist gefixed, danke
nochmal für den Hinweis
Hayo
Also QuickMeasurment hat gerade in Grundzügen funktioniert. Auch die
Cursor. Average, Pk-to-Pk und Frequenzbestimmung haben funktioniert.
Damit müsste eigentlich auch der Rest gehen. Hat funktioniert, weil ich
das ganze noch in eine Schleife für alle 4 Kanäle packe und dadurch
einige Änderungen nötig sind. Weiß nicht, obs heute noch was wird.
Schaut aber gut aus ;-)
Hallo Hayo,
ja ok, ich hatte die blöden Timebase- Faktoren in meiner geistigen
Rechnung nicht berücksichtigt! Daran sieht man, wie ungünstig die
Sample-Raten in den einzelnen TB's gewählt ist. Der geringe Prozentsatz
mit dem der zur Verfügung stehende Samplespeicher (16384 Samples)
ausgenutzt wird, ist ein anderes Zeichen dafür.
Vor dieser TB- Anpassung standen wir im VHDL Design auch vor Kurzem ;-).
Tja, das Aliasing lässt sich leider nicht vermeiden, ein typisches ADC
Problem.
Die Korrektur des zeitl. Versatz kann aus meiner Sicht noch warten,
sollte halt nicht in Vergessenheit geraten. Schade das es keine To-Do-
und Bug- list mit öffentlicher Möglichkeit von Ergänzungen gibt- sieht
man einmal von der Wishlist unter Sourceforge ab.
Gruß, brunowe
Hier das Windows Konsolenprogramm für die aktuelle 80er Firmware.
Erklärung steht in der liesmich.txt.
Ich bräuchte eine Rückmeldung, ob die Farben korrekt wiedergegeben
werden.
Wie gesagt, meine Ergänzungen sind etwas buggy und enthalten schwere
Designfehler aber das Prog verursacht wenigstens keinen Bluescreen. ;-)
@Kurt
Prima, leider komme ich erst übermorgen zum Testen da ich bis dahin
etwas beruflich eingespannt bin. Hab's mir aber schon mal runtergezogen.
@Bruno
Ja das hatte ich vergessen auf meiner ToDo Liste aufzuschreiben, die
Timebasesteuerung wollte ich mal komplett umstellen. Ich sehe nämlich
keinen vernünftigen Grund, warum die Samlerate nicht besser genutzt
werden sollte. Keine Ahnung was sich der Programmierer dabei gedacht
hat. Zuerst vermutete ich dass da irgendein tieferer Sinn hintersteckt,
den ich nicht durchschaue, aber mittlerweile nach längerem Umgang mit
dem Coding weiß ich dass es wohl eher nicht so ist.
Gruß Hayo
So Hayo,
habe dir unter SF meine aktuellen Änderungen für QuickMeasurment
eingespielt. Viel Spass beim mergen. ;-) War doch sehr umfangreich.
Dafür sind aber auch die 4 Kanäle in EINER Schleife zusammengefasst und
nicht wie vorher jeder einzeln. Ich bin zufrieden ;-)
Bei mir geht derzeit auf beiden Kanälen (theoretisch auf allen 4, ich
hab aber blos zwei, also fleißig Bericht erstatten) das Messen von
Average, Duty Cycle, FallTime, Frequency, Maximum, Minumum, Peak-Peak,
Rise-Time, +Width, -Width. Die Auswertung von einem Summen- oder
Differenzsignal geht noch nicht.
Ich kenn mich mit dem Ändern der Menüsteuerung nicht aus. Aber wäre es
möglich, die 3 Felder einzeln zu löschen?. Außerdem besteht prinzipiell
jetzt die Möglichkeit die Genauigkeit einzustellen. (Auf kosten der
Geschwindigkeit) Könnte man evtl. über das Menü ein und ausschalten.
Gruß,
Stefan
Nochmal @Niklas:
ZMODEM ist ja auch noch komplizierter als XMODEM. Eigentlich reicht auch
ein XON/XOFF oder sogar zwischen Datenblöcken von 128Byte eine kurze
Pause einzulegen.
Zum Zielsystem:
Für mich persönlich müssten die Daten auf einen mobilen Speicher. Die
Screenshots direkt auf den PC zu übertragen ist meistens zu umständlich.
Also müsste das Oszi schon ein fertiges ppm File ausgeben können was von
einem µC auf einen Massenspeicher geschrieben wird. Ist diese direkte
Ausgabe möglich?
Zusätzlich die Möglichkeit der Ausgabe der ganzen Sampledaten mit den
wichtigsten Parametern als txt File welches später mit einem PC Programm
zu einem großen Bild zusammengesetzt werden kann.
PPM ist als Format erstmal ausreichend und kann mit IrfanView betrachtet
werden.
Tipps von einem Ahnungslosen:
BMP verwendet angeblich eine Lauflängenkodierung. Eine begrenzte
Datenreduktion ist vieleicht auch mit Huffman Codierung möglich.
Hayo W. schrieb:
> @Bernd>> Der Bug mit Kanal 3 + 4 nach der Rückkehr von der FFT ist gefixed, danke> nochmal für den Hinweis
Super! Ich hatte gestern Abend noch etwas gespielt und gemerkt, dass der
Fehler nicht immer auftritt und schon überlegt was zuvor anders war...
Beim Trigger bzw. seiner Darstellung habe ich noch ein paar Dinge
bemerkt, die man verbessern könnte:
1) Wenn man im "Aquire"-Menü (*) zwischen Normal und Averaging wechselt
wird der Averaging-Modus wird mit einem Durchmessersymbol dargestellt.
Dieses Symbol verschiebt den Triggerpfeil um ca. 1/2 Symbolbreite nach
unten (ca. 10 % eines Div). Da die numerische Anzeige rechts oben
unverändert bleibt gehe ich davon aus, dass es nur ein
Darstellungsproblem ist.
(*) Richtig wäre "Acquire" - aber den Druck des Bedienpanels wird man
wohl nicht per SW ändern können ;-)
2) Die Pfeilspitze des Triggersymbols ist auch im Normal-Mode um ca.
zwei Pixel zu tief. Bei beispielsweise 1 V/Div liegt der Trigger erst
bei 1.04 V optisch auf der 1 V Linie.
(Ich weiß, ist pedantisch - aber so etwas sticht mir leider direkt ins
Auge).
3) Die numerische Anzeige des Triggerlevels ist bei 2 V/Div manchmal
falsch:
Ausgangssituation: 1 V/Div mit Triggerlevel 500 mV. Beim Umschalten auf
2V/Div wird rechts oben ein Triggerlevel von "1.00 mV" angezeigt.
Optisch per Pfeil dargestellt sind 1 V (also Volt statt Millivolt). Wenn
man auf 5V/Div weiterschaltet wird der Level korrekt mit "2.50 V"
angezeigt. Wenn man nun wieder auf 2 V/Div zurückschaltet, dann wird
auch in diesem Bereich nun korrekterweise "1.0 V" angezeigt.
=> Es macht also für die Anzeige des Triggerlevels einen Unterschied, ob
man von "oben" oder von "unten" in den 2V/Div Bereich kommt. Die
restlichen Bereiche waren soweit ich gesehen habe O.K.
4) Wurde so weit ich weiß schon einmal angemerkt und könnte auch ein
Feature und kein Bug sein ;-):
Intuitiv hätte ich erwartet, dass ein eingestellter Triggerlevel von
beispielsweise 500 mV erhalten bleibt wenn ich den V/Div-Bereich
wechsle. Im Normal-Mode ist es für mich gewöhnungsbedürftig, wenn man
die Y-Auflösung ändert und erst mal "blind" ist bis man am Trigger
gedreht (oder in den Auto-Modus gewechselt) hat.
Freue mich schon auf die nächste FW.
Gruß,
Bernd
Hallo,
da ist ja eine Menge aufgelaufen. das macht Spaß!
@ niklas: Nach meiner Meinung reicht eine einfache binäre
Übertragung. Eventuell die Textübertragung konsequent als
Kommentar markieren (z.B. mit "#"), dann können zur besseren
Unterscheidung auch die Kanallisten durch kurze Kommentare
getrennt werden. Unsere Perl-Fans haben dann die Möglichkeit
alle denkbaren Filter zu implementieren.
@ Hayo: Zwei grundsätzliche Überlegungen.
1.) Sollten wir nicht für die 1er und 2er Bereiche den OPA
ebenfalls auf Verstärkung 1,25 schalten. Dann hätten wir
nur noch zwei Auflösungen x2,5 und x2. Ich kann darin keinen
Nachteil erkennen, die Änderungen in Set_Switches sollten kein
Problem sein, nur die Grafik muss angepasst werden.
2.) Bei Timebase > 6 wird nur jeder 4. Wert ausgewertet.
Wenn du eh an die Timebaseeinstellungen gehen möchtest,
solltet wir das gleich ändern. Dann werden unabhängig von
der Timebase immer 16k-Samples übertragen. Die Faktoren der
ProgrammingMaps werden dann vervierfacht, sonst ändert sich
nichts. Auf dem PC hätte das den Vorteil dass die FFT immer
mit 16k-Samples ausgeführt werden kann, was nicht nur die
zeitliche Auflösung vergrößert, sondern auch vertikal 24 dB
bringt,
Gruß, Guido
@Stefan
Super, ich werde mir das mal übermorgen ansehen. Grundsätzlich kann ich
Dir das Menü beliebig einrichten, Du müßtest nur genau beschreiben wann
was wo gesetzt oder gelöscht werden soll (welche Variablen und so).
@Bernd
Das nenne ich einen detailierten Fehlerbericht. Nicht übel. Etliche
Punkte fallen derzeit allerdings unter die Kategorie "minor problems".
Daher denke ich werden sie entweder mal so zwischendurch behoben (was
bei mir des öfteren vorkommt), oder es wird etwas dauern da es immer
noch einige größere Baustellen gibt. Auf jeden Fall danke für die
Hinweise.
Gruß Hayo
Hallo Kurt,
> ZMODEM ist ja auch noch komplizierter als XMODEM. Eigentlich reicht auch> ein XON/XOFF oder sogar zwischen Datenblöcken von 128Byte eine kurze> Pause einzulegen.
ZMODEM war ja nur dafuer gedacht um ein gaengiges Terminalprogramm
auf RS232 lauschen koennen zu lassen und automatisch Dateien vom
Oszi zu empfangen, ohne erstmal weitere Software zu installieren.
Mit XMODEM geht das leider nicht, weil da dummerweise im Protokoll
die Moeglichkeit fehlt auf Senderseite den Empfang direkt anzustoszen.
Mit dem XON/XOFF Software-Handshake geht es Dir primaer um die
Uebertragung an einen uC, oder? Kann ich Dir einbauen, wie
beschrieben die UART ISR steht allerdings noch etwas im Weg.
> Zum Zielsystem:> Für mich persönlich müssten die Daten auf einen mobilen Speicher. Die> Screenshots direkt auf den PC zu übertragen ist meistens zu umständlich.>> Also müsste das Oszi schon ein fertiges ppm File ausgeben können was von> einem µC auf einen Massenspeicher geschrieben wird. Ist diese direkte> Ausgabe möglich?
Ja klar, das ist natuerlich moeglich. Der Grund warum ich den Umweg
ueber die Planes mit RLE Kompression gegangen bin ist nur dass ich
dadurch auf ~15kB s/w und ~65kB Farbe komme (und mit minimalem
Programmcode).
Das DSO kann natuerlich auch gleich die Planes fertig ueberlagern
und eingefaerbt als PPM ausgeben, waeren auch nur geschaetzt nen
Dutzend Zeilen Code plus einige Konstanten mehr -- nur kaemen wir
da auf 640*480*3 = 900 kB. (Farbkomponenten kleiner als mit einem
Byte auszudruecken ist leider nicht spezifiziert bei PPM (setzt man
im Header < 255 muss man dennoch ein volles Byte ausschreiben pro
Farbkomponente).)
Nehmen wir unkomprimiertes BMP mit 4 Bit Palette sind's noch ~150 kB.
Dazu kommt noch ein wenig Rechenzeit, Bufferung bei der Ausgabe fehlt
da auch noch...
Wenn Dir das nicht zu langsam ist ergaenze ich das gerne. Kann
man ja so machen, dass das Ausgabeformat im Quick-Print Menue
und per RS232 fuer den Anwender/uC konfigurierbar ist.
> Zusätzlich die Möglichkeit der Ausgabe der ganzen Sampledaten mit den> wichtigsten Parametern als txt File welches später mit einem PC Programm> zu einem großen Bild zusammengesetzt werden kann.
Mit txt File meinst Du also direkt Menschen-lesbar? Auch kein
Problem, nur in welchem Format genau muesste man sich einigen.
> PPM ist als Format erstmal ausreichend und kann mit IrfanView betrachtet> werden.>> Tipps von einem Ahnungslosen:> BMP verwendet angeblich eine Lauflängenkodierung. Eine begrenzte> Datenreduktion ist vieleicht auch mit Huffman Codierung möglich.
Ja, RLE geht optional. Die Spec dazu hab' ich aber noch nicht
angeschaut. Bei den Screenshots hatte ich schonmal verglichen und
Gimp erzeugte mir unter Verwendung einer Palette und Kompression
ein iirc. 48kB BMP File. Da liege ich mit 65kB ziemlich gut dabei,
mit einem sehr simplen Algo wo sicher noch was rauzuholen waere.
Also, zusammenfassend:
- fertiges PPM oder BMP (unkomprimiert erstmal) rausschreiben:
kein Problem, nur wenige Zeilen zusaetzlicher Code plus
gesteigerte Rechenlaufzeit
- Software-Handshake mit Blockung:
auch kein groszes Problem, beschriebene Problematik mit der
jetzigen UART ISR steht nur bloed im Weg
- Messdaten gleich fertig menschenlesbar raus:
genauso, muessten wir uns nur auf ein Format einigen
(z.B. CSV, welche Felder, Anordnung)
Mit Massenspeicher meinst Du sowas wie eine SD-Card, per SPI
angesprochen? Das faende ich klasse. Besonders wenn man dann
ein schoenes Gehaeuse dazu macht koennte das fast "nativ" zum
DSO gehoerend aussehen.
Gruss,
Niklas
Richtig, XON/XOFF für den µC. Brauchst du aber noch nicht einzubauen,
wir brauchen erstmal ein richtiges Konzept.
Das Problem mit der Dateigröße ist mir eben auch in den Sinn gekommen.
Die ~65kB zu senden dauert ja schon gut 50sec. Noch langsamer darf es
nicht werden.
Also müsste man im Oszi ein PNG oder JPG basteln.
Diese Seite kennst du schon? http://www.wotsit.org/default.asp
Massenspeicher als SD-Karte oder mein Favorit der USB-Stick.
Ganz verrückte könnten die Daten per RFM12 Modul durch die Gegend
funken. ;-)
Sehr schön wäre die Bildkompression und Ansteuerung des Speichers direkt
vom FPGA aus. Das lässt sich aber vorerst nicht nachrüsten, außerdem
fehlen ja den 2-Kanalgeräten die 5? herausgeführten Pins am FPGA.
PS: Eigentlich sollte die Schaltung ins Oszi. Da ist noch genug Platz
drin.
Hallo Kurt
>Hier das Windows Konsolenprogramm für die aktuelle 80er Firmware.
Das Programm funktioniert bei mir.
(XP, W2024A, FW 0.80)
Bei "PGM" ladet er 16Planes runter bei "PGM BW" nur eine.
Grösse der Dateien 901KB
Aber blöde Frage: Was kann ich jetzt mit den Files machen?
Kann es mit keinen meiner Programme öffnen ?
Könnte man da vielleicht auch ein "jpg" oder ein "PNG" runterladen?
l.G. Roberto
Hallo Kurt,
> Das Problem mit der Dateigröße ist mir eben auch in den Sinn gekommen.> Die ~65kB zu senden dauert ja schon gut 50sec. Noch langsamer darf es> nicht werden.
Theoretisch sollte es ja von der Schnittstelle her bei den 115200
Baud wesentlich schneller gehen (im Prinzip grob 10 Sekunden).
Wieviel Anteil da Rechenzeit hat und etwaiges Warten mangels
fehlender Bufferung habe ich nocht nicht genau geschaut.
Bufferung kaeme ohnehin bei ZMODEM wg. Blocking.
Rechenzeit scheint mir schon enorm zu sein. Wobei ich vllt.
mal explizit sagen sollte, dass ich mich da nicht besonders
klever anstelle und jeden Pixel einzeln aus einer Speicherstelle
zurueck fuehre. Das laesst sich mit einer Portion Bitmask
Voodoo sicher optimieren, uebersteigt jedoch derzeit meinen
Horizont (Hilfe wird dankend angenommen :)).
> Also müsste man im Oszi ein PNG oder JPG basteln.> Diese Seite kennst du schon? http://www.wotsit.org/default.asp
Ne die Seite kannte ich noch nicht, gerade kurz bissl rumgeklickt,
sieht nett aus. Schaue ich spaeter mal genauer.
> Sehr schön wäre die Bildkompression und Ansteuerung des Speichers direkt> vom FPGA aus. [..]
Das waere natuerlich noch besser wenn ihr das hinbekommt.
> PS: Eigentlich sollte die Schaltung ins Oszi. Da ist noch genug Platz> drin.
Oh, noch besser :)
@Roberto:
> Bei "PGM" ladet er 16Planes runter bei "PGM BW" nur eine.> Grösse der Dateien 901KB
Ja das passt, bei S/W werden die 16 Planes direkt auf dem Oszi
kombiniert. ~900KB passt auch, sind unkomprimierte 640x480
Pixel mit 24 Bit Farbtiefe.
> Aber blöde Frage: Was kann ich jetzt mit den Files machen?> Kann es mit keinen meiner Programme öffnen ?
Ja, unter Windows ist PPM leider kein gaengiges Format, aber
fuer (ohnehin meist faule ;)) Programmierer ein extrem
einfach zu erstellendes Format.
Daher laengst meine Ansage fuer Windows-User auch BMP
zu generieren (was das naechst einfache Format waere ;)).
> Könnte man da vielleicht auch ein "jpg" oder ein "PNG" runterladen?
Ja, natuerlich. Steht auch schon auf meiner Agenda.
Kurt oeffnet die PPM mit Ifranview, iirc. Gimp sollte auch gehen.
Wobei ich natuerlich jetzt niemanden dazu bringen will nur
deswegen zusaetzliche Software zu installieren.
BMP-Ausgabe wird wie gesagt sicher in Kuerze folgen.
Gruss,
Niklas
@Stefan
Nachdem ich jetzt eine halbe Stunde lang bei SFN rumgeklickt habe und in
der Zeit nur zwei Sourcedateien geladen bekommen habe - kannst Du mir
die Sourcen hier hochladen, ich hab keine Lust mehr mich damit weiter
rumzuärgern. Das ist ja langsam und zäh wie Kaugummi mit dem Trac-Tool.
Gruß Hayo
@Roberto & all,
ich werde mich um eine neue Win Applikation für das DSO kümmern (Anzeige
und Steuerung des DSO), kann aber noch nicht sagen, unter welchem
Framework. Lazarus vielleicht? Ist frei und auch für Linux/OSX
verfügbar. Müsste mich aber erst einarbeiten.
Michel
Hallo,
so, ich hab' jetzt mal getestet wo da egtl. die Minute herkommt,
die so'n 65kB Dump braucht.
Erst einmal ist es kein Problem nur unter Verwendung von putchar()
da volle 10kB/s rauszuschoeffeln. Das ist schonmal gut.
Nicht so gut ist aber, dass die grob restlichen 50 Sekunden
tatsaechlich voll und ganz in den Pixelschleifen verbracht
werden. Dazu hab' ich nur die putchar() entfernt, RLE
wird weiter gemacht. Auch bei B/W braucht das Oszi noch
fast 15 Sekunden nur dafuer.
NiosII ist wohl einfach lahm. Langsamer als ich gedacht haette...
Bislang vermutete ich verschenkte Zeit indem ich ungebuffert
rausschreibe, ist aber irrelevant...
Wenn man sich mein diff (aus den geposteten .tgz) nochmal
anschaut sieht man, dass da quasi "nix" passiert. Natuerlich
ist wie in meinem letzten Posting gesagt die Pixelwandlung
nicht optimal, aber auch nicht so schlimm.
Damit dann gar PNG mit Deflate auf dem NiosII zu machen
koennen wir m.E. gleich mal komplett vergessen.
Sollten wir vllt. einfach die Speicherbereiche unveraendert
binaer rausjagen, auch wenn's iirc. 38400 Byte * 16 = 600kB
sind, und alles auf dem Computer erledigen?
(den Code dafuer haben wir ja schon...)
Und auch Fragen an die Leute die schon laenger mit NiosII
und/oder der Firmware zutun haben:
- Wuerde es helfen das in Assembler zu schreiben?
- Ist da etwas was ich da mache auf NiosII besonders ineffizient?
- Andere Datentypen verwenden?
Gruss,
Niklas
mal zum USB-BUS:
die UARTS des CY7C64713 können mit bis zu 230 KBaud kommunizieren. Gibt
es das Board/die Firmware her? Aus irgendwelchen Dokus sehe ich, dass
nur mit einem Viertel der möglichen Rate übertragen wird. Hier wäre noch
Potential.
Kann man den Germs-Monitor vielleicht auch auf den USB umbiegen? Ich
möchte lieber den USB nutzen als die serielle Schnittstelle.
Vielleicht sollte man eine Möglichkeit bieten, den Firmwareupload via
Auswahl in der Firmware (Menüpunkt) zu initiieren.
Wahrscheinlich ein wenig viel, oder ;-)
Neuer USB-Treiber, neue CY-Firmware, Anpassungen in der
Scope-Firmware...
sorry
@Niklas
Das Schreiben in Assembler könnte evtl. was bringen, ist aber eigentlich
kontraproduktiv, da wir uns bemühen etwas plattformunabhängiger zu
werden und daher die Assemblerroutinen durch c-coding zu ersetzen
> NiosII ist wohl einfach lahm. Langsamer als ich gedacht haette...
So ist es. Bei dieser Variante wurde auch noch auf das
Multiplikationsmodul verzichtet. D.h. bei der Optimierung auf
Geschwindigkeit sollte man folgendes beachten:
- Floating Point Operationen -> ganz schlecht, möglichst umstricken
auf Integer
- Integer Multiplikationen -> möglichst vermeiden
- Integer Additionen -> sind ok
- Shift Operationen -> möglichst oft verwenden da erheblich schneller
- komplexe Bibliotheksfunktionen -> ganz schlecht, möglichst durch
eigene optimierte Funktionen
ersetzen.
- oder noch besser -> durch schnellen indizierten Tabellenzugriff
ersetzen
Gruß Hayo
Nach längerer Zeit habe ich mal wieder eine FW....80 eingespielt und bin
begeistert.
Niklas O. schrieb:
> Hallo,
...
> Sollten wir vllt. einfach die Speicherbereiche unveraendert> binaer rausjagen, auch wenn's iirc. 38400 Byte * 16 = 600kB> sind, und alles auf dem Computer erledigen?> (den Code dafuer haben wir ja schon...)
Ich hatte mir auch mal eine Erweiterung geschrieben, mit der ich die
rohen ADC-Daten seriell ausgegeben habe (USB habe ich totgespielt).
Auf dem Display werden doch sowieso nur 512 Bytes angezeigt. Bei vier
Kanälen sind das maximal 512*4=2048 Bytes.
Wenn man im Header die Einstellung überträgt (Menü, Timebase...) und
dann 512 Bytes/Kanal, sollte das ordentlich flott werden. Die "hübsche"
Darstellung kann dann der PC übernehmen.
Aber auch die vollen 16kB/Kanal machen maximal 64kB, also ca. 6s.
Wenn man den PC-Teil in Qt schreibt, kann der auf allen gängigen
Betriebssystemen laufen.
Ich hatte das mal angefangen. Es müßten sämtliche Parameter per RS232
einstellbar sein. Auf Kommando könnten die Daten einmal oder dauernd
gesendet werden.
Wenn sich ein Qt-Spezialist fände, würde ich die HW-Schnittstelle PC-
und Scope-seitig implementieren. Wenn nicht, würde ich eine Oberfläche
basteln können. Schön wird das aber nicht ;-)
Falk
P.S.: Wie läßt sich USB wiederbeleben, wenn sie absolut nicht mehr
ansprechbar ist? Ich hatte mit ein paar Cypress?-Tools herumgespielt...
Hallo,
@Hayo:
Tja, ich mache ja egtl. nix anderes als Integer Additionen, Shift
und paar Array-Zugriffe... D.h., damit ist dann wohl Ende der
Fahnenstange, da von 50s auf humane 10s oder so zu kommen steht
wohl auszer Frage.
@Falk:
Jo die Ausgabe der ADC-Daten kann ich auch wahlweise auf die
angezeigten 512(*4) Werte reduzieren bei der Implementation
der Messdatenausgabe. Dein und/oder Michaels Programm koennten
dann beinahe in Realtime den Output anzeigen.
Fuer viele reicht es natuerlich, wenn da ein Programm die Kurven
einfach nachmalt. Dennoch ist es IMHO schoen, wenn man die Option
hat den originalen DSO-Screen 1:1 zu speichern, mit Cursorn und
Measurements. Koennte man natuerlich auch nachmalen mit Programm,
aber warum alles doppelt. Ich moechte auf die Screenshot-Funktion
zumindest nicht verzichten und sie hat mir lange gefehlt.
Niklas
Hallo Falk,
ich vergasz:
> [..] Es müßten sämtliche Parameter per RS232 einstellbar sein.> [..] [HW-Schnittstelle PC- und Scope-seitig implementieren]
Ja alle Knoepfe sind wohl bereits auf RS232 gemappt.
Da ich ohnehin einen Eingriff an der Original UART ISR vornehmen
muss, sollten wir vllt. das (und die Routinen die da draenhaengen)
direkt mal aufraeumen und zusammen ein klares Interface
festschreiben.
Wenn jemand Material/Erfahrung zu Interfaces von anderen
professionelleren Scopes hat sollte er die dann einbringen.
Ich zumindest hab' da leider nichts vorzuweisen.
Niklas
Niklas O. schrieb:
> Ich moechte auf die Screenshot-Funktion> zumindest nicht verzichten und sie hat mir lange gefehlt.
Das sehe ich genauso. Insbesondere für dokumentarische Zwecke sehr
praktisch wie man auch in meiner Anleitung sehen kann. Die Wartezeit von
einer Minute kann ich dabei locker verschmerzen. Mit der Kamera war ich
auch nicht schneller und hatte auch noch diverse Fehlversuche wegen
Verwackelung und Fehlbelichtung.
Für die FFT-Doku habe ich die Screenshot-Funktion statt ins QP-Menü
direkt auf den QP-Button gelegt und noch zusätzlich den Popuptimer für
die Dauer des Screenshots blockiert.
Hintergrund: Mit der Implementierung in der Version 0.80 läßt sich kein
geöffnetes Popupmenü blitzen und auf den Screenshots ist dann auch immer
das QP-Menü zu sehen, was aber für Dokumentationszwecke oft nicht so
günstig ist, da man ja auch die aktuellen Menü-Einstellungen
dokumentieren möchte.
Ich habe mir schon einige Gedanken gemacht wie man das lösen kann, dass
man trotzdem das QP-Menü zur Verfügung hat. Mal sehen...
Hat einer von Euch eine spontane Idee?
Hayo
Niklas O. schrieb:
> Hallo,> Jo die Ausgabe der ADC-Daten kann ich auch wahlweise auf die> angezeigten 512(*4) Werte reduzieren bei der Implementation> der Messdatenausgabe. Dein und/oder Michaels Programm koennten> dann beinahe in Realtime den Output anzeigen.>> Fuer viele reicht es natuerlich, wenn da ein Programm die Kurven> einfach nachmalt.
Mit den Rohdaten kann man aber noch viel mehr anstellen. Beispielsweise
mathematische Funktionen, die man im Scope nicht machen kann.
> Dennoch ist es IMHO schoen, wenn man die Option> hat den originalen DSO-Screen 1:1 zu speichern, mit Cursorn und> Measurements.
Natürlich ist das prima, keine Frage. Nur hat man dann keine Daten mehr,
sondern ein Bild.
> Ich moechte auf die Screenshot-Funktion> zumindest nicht verzichten und sie hat mir lange gefehlt.
Das geht mir nicht anders. Aber auch ein Dump der Daten ist praktisch
und eigentlich mit "Dump to XLS" schon vorhanden. (Ich halte .xls für
zwei/vier Spalten mit je 16.000 Zeilen für unsinnig. CSV reicht.)
Falk
@ Hayo: QP-Button im Menu "scharfschalten", Einstellungen
nach Belieben und der nächste Druck auf QP macht die Hardcopy.
3. Druck auf QP: Menu erscheint wieder.
Sollte ohne großen Aufwand gehen.
Hast du mal meine 2 Fragen von gestern angedacht?
Gruß, Guido
@Guido
Ja, sorry hatte ich etwas verdrängt.
> 1.) Sollten wir nicht für die 1er und 2er Bereiche den OPA> ebenfalls auf Verstärkung 1,25 schalten. Dann hätten wir> nur noch zwei Auflösungen x2,5 und x2. Ich kann darin keinen> Nachteil erkennen, die Änderungen in Set_Switches sollten kein> Problem sein, nur die Grafik muss angepasst werden.
Könnte man machen, allerdings könnte es schon etwas Aufwand geben, da
die Skalierung in alle möglichen Routinen mit einfließt. Ich denke
Stefan wird da bei QM auch mit zu tun haben. Vorteil wäre natürlich die
bessere Ausnutzung der Wandlerauflösung und damit verbunden das
geringere Rauschen in der Darstellung. Evtl. könnte es reichen die
Skalierungsfaktoren anzupassen. Ich hab mir die Set_Switches() noch
nicht so genau angesehen, ist die Umschaltung so ohne weiteres möglich?
> 2.) Bei Timebase > 6 wird nur jeder 4. Wert ausgewertet.
Nein das ist nicht ganz richtig. Grundsätzlich ist die Situation zur
Zeit so:
- es werden grundsätzlich immer 16k Werte gesampled
- die 1er und 5er Bereiche > 5µs nutzen jeden 5. Wert
- die 2er Bereiche > 5µs nutzen jeden 4. Wert
- der 5µs Bereich nutzt nur jeden 25. Wert
> Wenn du eh an die Timebaseeinstellungen gehen möchtest,> solltet wir das gleich ändern. Dann werden unabhängig von> der Timebase immer 16k-Samples übertragen. Die Faktoren der> ProgrammingMaps werden dann vervierfacht, sonst ändert sich> nichts. Auf dem PC hätte das den Vorteil dass die FFT immer> mit 16k-Samples ausgeführt werden kann, was nicht nur die> zeitliche Auflösung vergrößert, sondern auch vertikal 24 dB> bringt,
Das habe ich nicht ganz verstanden. Wieso werden die Faktoren
vervierfacht? Ich wollte die Faktoren eigentlich möglichst auf 1 oder 2
bringen. Es stehen jedoch trotz allem für eine FFT immer die vollen 16k
zur Verfügung, denn für die FFT ist nicht die eingestellte Timebase
ausschlaggebend, sondern nur die indirekt damit verbundene tatsächliche
Abtastrate. D.h. die Zeitbasen 2ns bis 1µs haben bei der FFT die
gleichen Ergebnisse. Erst beim Wechsel auf 2µs verändert sich der
Frequenzbereich durch die halbierte Abtastrate.
Für eine PC-Anwendung wäre es daher auch jetzt schon möglich die vollen
16k zu nutzen, da die Werte ja vorhanden sind, nur bei der Grafikausgabe
einfach übersprungen werden.
Gruß Hayo
@Niklas
Morgen hätte ich etwas Zeit. Soll ich die UART ISR mal strippen? Ich hab
mir das mal angesehen, das müßte eigentlich gehen ohne dem Keybord ISR
auf die Füße zu treten. Dann könntest Du da Deine Ideen reinverwursten.
Hayo
Hallo Hayo,
mit Set_Switches ist das kein Problem, ich muss mir nur wieder
klar machen, welches Bit für welchen Switch steht.
In den Bereichen mit Timebase > 6 werden 16k gesampled und im
FIFO abgelegt. In Readadc_all wird dann aber nur jeder 4. Wert
an den Anfang von DataArrayX geschrieben, in der
Assembler-Routine wird der Rest der Daten hinten angehängt, in
meiner C-Routine habe ich aus Geschwindigkeitsgründen darauf
verzichtet.
Besser wäre es unabhängig von der Timebase alle gesampleten
Daten hintereinander in DataarrayX zu schreiben, was für die
Grafik in den langsamen Bereichen die Faktoren vervierfacht.
Wenn man die (Hardware-)Timebase für alle Bereiche so
einstellen kann, dass immer korrekt gesampled wird, werden die
Faktoren natürlich 1. Das wäre optimal, ich habe aber nicht
verstanden warum das nicht so ist und vermute, dass da was in
der Hardware bockt (sonst hätten die das doch nicht gemacht).
Gruß, Guido
Da ja eh' nur RAW gesendet werden soll, es also keinerlei Entscheidung
bzgl. des Formats zu treffen gibt, kann man doch "Quick Print", ohne das
nachfolgende Menü nehmen. Quick-Print trifft's doch auf den Kopf...
@Guido
Das glaube ich nicht. Ich hab mir da schon so meine Gedanken gemacht
(anbei der neue Entwurf des Timebasecontrollers) und werde mal eine
Testversion bauen um das zu überprüfen. Allerdings muß man natürlich
damit rechnen, das sich die Sampledauer entsprechend verlängert, was
sich in den langsamen Zeitbasen schon recht spürbar auswirken kann.
Gruß Hayo
@elgodil
Keine schlechte Idee, aber per ISR läßt sich das gleichzeitige Drücken
von zweei Tasten nur schwer ermitteln. Der Germsmonitor-Auslöser dagegen
ist fest verdratet (siehe NIOS Doku).
@Stefan
Ja sowas in der Art dachte ich mir auch. Allerdings wenn weitere Daten
Übertragen werden sollen (Excel etc.), wäre ein Menü nicht schlecht.
Hayo
@Hayo
also kurz drücken und einen Quick-Print (Screenshot) bekommen - länger
drücken und ein Menü für weitere Optionen erscheint. Quick-Print
überschreibt somit keine angezeigten Settings, während die Anzeige der
Softkey für das weiter führende Menü beim Excel-Export nicht relevant
wäre.
@Kurt
Bei meine test's mit deinem screen.exe habe ich festgestellt, das die
Farben um ein Pixel verschoben sind. Eine Analyse des screenX.ppm zeigt
das unter Windows \n zu "0x0d 0x0a" wird! das fuehrt dazu dass die
farb-tripples um 1 Byte verschoben sind (deshalb musstest du den index
umstellen!). Anbei meine Version die mit \r arbeitet.
Martin
Michael W. schrieb:
> mal zum USB-BUS:> Kann man den Germs-Monitor vielleicht auch auf den USB umbiegen? Ich> möchte lieber den USB nutzen als die serielle Schnittstelle.
Das sieht erstmal schlecht aus, ohne die Verbindungen im FPGA zu ändern.
Der Germsmonitor wird vermutlich nur auf einer UART des Systems lauschen
und nicht auf mehreren.
Johannes Studt schrieb:
> Crazor schrieb:>> Writing line 004277 of 023377: .X............0 sec / 134 sec left>> Error: Timeout while reading response from DSO!>> Response was: 'S219815B3D34<#33><#13>>> '>> Da muss mir mal ein GERMS-Kundiger weiterhelfen. Was bedeutet es, wenn> der Monitor mit '!' antwortet? Darauf muss ich sicher nur korrekt> reagieren und dann ginge es weiter.>> /Hannes
Das Problem ist leider schon wieder aufgetaucht. Und es ist immer ein !
nach dem CR, das da zurückkommt. Kann leider auch nix finden, nichtmal
in der Referenz. Bin mir nach der Lektüre des Codes auch immernohc nicht
sicher, ob denn nach einem ! die Zeile nochmals übertragen wird oder
nicht (kann kein Wort Perl). Evtl. würde ein erneutes Senden schon
helfen!
Hallo,
anbei noch die v0.3 vom Screenshot Programm:
Jetzt auch fuer Windows und auch mit BMP-Ausgabe.
Kompiliertes EXE-File (unter MinGW), .BAT und README.txt sind
dabei. Wenn sich jemand wundert warum sein Lieblingsprogramm
die BMP evtl. nicht oeffnen vermag: steht in der README.
Ich wollte egtl. noch das Binaerformat der DSO Ausgabe
dokumentieren, habe aber nun keine Zeit mehr. Ich hoffe es
funktioniert alles richtig, habe nicht sonderlich lange testen
koennen.
@Hayo:
> Morgen hätte ich etwas Zeit. Soll ich die UART ISR mal strippen? Ich hab> mir das mal angesehen, das müßte eigentlich gehen ohne dem Keybord ISR> auf die Füße zu treten. Dann könntest Du da Deine Ideen reinverwursten.
Ja, mach das mal.
Niklas
Hallo Martin
> Bei meine test's mit deinem screen.exe habe ich festgestellt, das die>Farben um ein Pixel verschoben sind. Eine Analyse des screenX.ppm zeigt>das unter Windows \n zu "0x0d 0x0a" wird! das fuehrt dazu dass die>farb-tripples um 1 Byte verschoben sind (deshalb musstest du den index>umstellen!). Anbei meine Version die mit \r arbeitet.
Meinst Du damit den roten Schatten, rechts der gelben Linie ?
Habe das screen.cpp durch deines ersetzt.
Ist aber noch immer der gleiche Schatten ?
Muss man da noch was ändern?
l.G. Roberto
Daniel H. schrieb:
> Das Problem ist leider schon wieder aufgetaucht. Und es ist immer ein !> nach dem CR, das da zurückkommt. Kann leider auch nix finden, nichtmal> in der Referenz. Bin mir nach der Lektüre des Codes auch immernohc nicht> sicher, ob denn nach einem ! die Zeile nochmals übertragen wird oder> nicht (kann kein Wort Perl). Evtl. würde ein erneutes Senden schon> helfen!
Ok, habe nun Zeile 184 von
while ($buffer !~ /\+/) {
nach
while ($buffer !~ /[\+|\!]/) {
geändert. Daraufhin wird auch bei einem ! weitergemacht, leider hatte
ich dann .X.X.X.X. usw. in der Ausgabe, und nach dem 10. Versuch nen
Abbruch. Dann hab ich mir gedacht baue ich in die Abbruchfehlermeldung
auch die Ausgabe des Buffers mit ein, um zu sehen was der GERMSmonitor
weiterhin antwortet, aber dann hat der Upload (leider ;) gerade mal
funktioniert, sodass ich erst bei einem der nächsten Hayo-Releases
weitertesten kann...
@Nicklas
Das Programm funktioniert bei mir! :-)
Auch kein Schatten mehr :-)
Leider kann ich kein Englisch.... (Doku)
Was ist der Befehl "-b".
Warum speichert er jetzt so viele Files extra?
Das PGM BW macht jetzt BMP :-) (-->ok)
Warum nur in S/W?
In der Doku habe ich was von "png" gelesen.
Gehen jetzt auch .png Bilder?
l.G. Roberto
Daniel H. schrieb:
> Ok, habe nun Zeile 184 von> while ($buffer !~ /\+/) {> nach> while ($buffer !~ /[\+|\!]/) {> geändert. Daraufhin wird auch bei einem ! weitergemacht, leider hatte
Ok, richtig wäre /[!+]/ (in Zeichenklassen hat das Plus wie auch das
Ausrufezeichen keine Sonderbedeutung), aber es ist sicher prinzipiell
keine gute Idee das so zu machen. Das Ausrufezeichen ist wahrscheinlich
eine Fehlermeldung und keine Quittung, also sollte die Zeile erneut
übertragen statt einfach fortgefahren werden. Ich guck dann mal rein und
ändere das entsprechend, die Frau ruft nur eben wegen Abendbrots.
@Hayo: ich fände es ergonomisch, wenn der Druck auf QP einfach wie
gehabt das Menü aufruft und ein längerer Druck die Übertragung
stillschweigend auslöst. So würde ich das zumindestens bei meinen
Applikationen machen.
/Hannes
@Hayo
Hier sind die Sourceen. Hab in hardware.cpp, tc_vars.cpp, tc_vars.h,
display.cpp was geändert. Woanderst glaube ich nicht ;-)
@Stefan, der zweite
Können wir uns darauf einigen, dass ich ab jetzt mich immer als Stefan
E. oute und du dir auch noch nen Buchstaben gönnst? Sonst bin ich am
Ende noch selbst verwirrt, was ich geschrieben habe ;-)
Niklas O. schrieb:
> Hallo,> Ich wollte egtl. noch das Binaerformat der DSO Ausgabe> dokumentieren, habe aber nun keine Zeit mehr. Ich hoffe es> funktioniert alles richtig, habe nicht sonderlich lange testen> koennen.
Mir ist aufgefallen, daß fast 2/3 des Outputs Sequenzen "7e 7e 7e 0a"
sind.
Ich werde das rle_coding etwas verändern und hoffe, daß ich die
Datenmenge nochmal halbieren kann.
Den Code stelle ich dann hier zur Abstimmung ;-)
Falk
Johannes Studt schrieb:
> keine gute Idee das so zu machen. Das Ausrufezeichen ist wahrscheinlich> eine Fehlermeldung und keine Quittung, also sollte die Zeile erneut> übertragen statt einfach fortgefahren werden. Ich guck dann mal rein und> ändere das entsprechend, die Frau ruft nur eben wegen Abendbrots.
Dummes Hannes. :D
Na klar war das so vollkommen korrekt. Einfach die Zeile 183 wie oben
schon beschrieben auf
while ($buffer !~ /[+!]/) {
ändern und schon wird bis zu 10mal versucht, die Zeile neu zu
übertragen. Dabei wird jedesmal ein X gemalt, damit man weiß, dass da
was krumm war.
/Hannes
Könnte man, bei all den Optimierungen, evtl. bei den Kanaleinstellungen
einen Button aufmachen, der die Darstellung des jeweiligen Kanals auf
50% Helligkeit setzt; ihn 50% transluzent zu machen ist ja wohl nicht
drin :)
Oft hat man ein ein Signal vor dem Processing, und möchte es in bezug
darauf auch nach dem Processing darstellen. Optimal ist es dann, wenn
beide überlagernd liegen, aber da dominiert eben eine Farbe die andere
immer sehr...
Hallo,
> Ich wollte egtl. noch das Binaerformat der DSO Ausgabe> dokumentieren, habe aber nun keine Zeit mehr. Ich hoffe es> funktioniert alles richtig, habe nicht sonderlich lange testen> koennen.
leider doch ein Fehler: Unter Windows wurde immer com1 verwendet,
auch wenn mit -c ein anderer COM-Port definiert wurde. Anbei
die behobene aber ansonsten unmodifizierte Version.
@Roberto:
> Was ist der Befehl "-b".
Der bewirkt das Schreiben von BMP statt PPM Dateien.
> Warum speichert er jetzt so viele Files extra?
Das war schon immer so im Falle von PPM. Da wird jede
Plane (Darstellungsebene, z.B. Kanal1-4, Cursor, ...)
auch einzeln gespeichert. Ist ganz nuetzlich wenn man
bei der Entwicklung Darstellungsfehler lokalisieren will.
Bei Kurts Version war das wohl abgeschaltet und es wurde
immer nur eine Datei geschrieben.
> Warum nur in S/W?
Wenn Du im Quick Print Menue vom DSO die Taste ohne BW
drueckst sollte das farbig rauskommen.
> Gehen jetzt auch .png Bilder?
Nein, noch nicht. In der README ist hinten beschrieben
wie man unter nicht-Windows da ein PNG raus machen koennte.
Deutsche Kurzbeschreibung werde ich in den naechsten Versionen
beifuegen. Kurz gesagt wird mit dem Parameter -c der COM-Port
festgelegt, also etwa -c 4 fuer COM4. Mit -f kann man einen
Dateinamen-Prefix festlegen, bei -f fft -b wuerde dann eine
Datei fft.bmp geschrieben. -h zeigt Hilfe in Englisch an.
@Kurt:
> [Main Loop]
Werde ich per Schalter -l oder so hinzufuegen in den naechsten
Versionen, schreibt dann [prefix][nnnn].[suf], wobei nnnn
aufsteigend.
> Wo kriege ich die ganzen fehlenden Includes her?
Was benutzt Du denn als Compiler? Ich habe das unter MinGW
kompiliert. Bei de(r|n) (keine Ahnung davon) Windows libc
scheint es ja nichtmal snprintf() zu geben, jedenfalls habe
ich gesehen dass Du das mit strcat() usw. emulieren musstest.
Niklas
Hallo Niklas,
ich verwende das Visualstudio 6 bzw. 2008 Express.
Den Wechsel von .c auf .cpp hat das Studio vorgegeben. Nötig ist er
glaube ich nicht.
Die unistd darf bei mir nur unter Linux eingebunden werden.
Ersetzen von (int) usleep(1000) durch (void) Sleep(1000)
Ersetzen von snprintf() durch sprintf_s().
Aus fopen wird fopen_s
Dann gibt es noch Probleme mit optarg und getopt()...
Die Frage ist ob die Änderungen auch mit Linux laufen. Sonst muss man
mehr #ifdef einsetzen. Außerdem weiß ich nicht, was diese ganzen safe
Funktionen sollen. Muss ein Feature von C++ sein.
Die Sache mit strcat() war nur eine Notlösung, weil ich vergessen hatte
das es sprintf() gibt.
PS:
Mit MinGW geht es bei mir aber auch so. Ich musste erstmal googlen wie
man damit kompiliert. ;-)
Das Wochenende ist gerettet!
Hier die neue 0.82 beta (hoffentlich werden wir den beta status los
bevor wir die 100 knacken).
- für Niklas habe ich die UART ISR leergeräumt - hat jetzt nur noch 7
Zeilen. Deiner Implementierung steht also nichts mehr im Wege.
- Stefans neue QM-Routinen sind auch mit dabei. Sieht nach den ersten
Tests sehr vielversprechend aus. Dank des Redesigns ist das Flashfile
wieder unter 1.3 MByte auf rekordverdächtige 1234 KByte geschrumpft!
- einige kleinere bugs sind gefixed.
- Der Screenshot liegt wie schon erwähnt direkt auf dem QP-Button,
b/w-Screenshots sind daher zur Zeit nicht möglich.
Bei der QM-Funktion wird leider der untere Gridrand etwas zerbröselt,
das wäre eigentlich was für unseren Plane-Spezialisten Guido.
Interessanterweise tritt das bei der Cursorfunktion nicht auf.
Gruß Hayo
QM ist denke ich soweit ganz brauchbar. Der Rest, der noch nicht
umgearbeitet ist (Delay, Phase, Math-Kanal,...) kommt auch noch
irgendwann...
Gruß,
Stefan
@Niklas
Die neue 0.3 Screenshotversion arbeitet einwandfrei auch unter Windows.
Das wird viele nicht-Linuxer freuen, da sie jetzt auch in den Genuss
dieser praktischischen Funktion kommen.
Eine wirklich nützliche Erweiterung für unser W20xxA.
Hayo
Also bei mir laufen sowohl die BF.0.80, als auch die neue 0.82 nicht.
Die ganze Gruppe um 'Measure', 'Waveform' und 'File' geht einwandfrei;
bei 'Trigger' reagiert kein einziger Button und die Channel-Buttons sind
ebenfalls tot - 'Math' geht wiederum.
Es wird kein einziger Kanal angezeigt, bis auf die Menüs und die
Cursor-Lines oder Quick-Measure -sofern aktiviert- ist der Bildschirm
schwarz.
'Utility|Calibrate ADC/DAC' und 'Utility|Search Zero Lines' laufen
ebenfalls durch - allein, ich hab' keine Signale...
Spiele ich die FW1.2.BF.0.75 beta zurück, geht sofort alles wieder.
Es ist ein E2024A. 'About' zeigt eine Hardware Version 8C7.0E
Was noch auffällt: unten links machen drei oder vier blaue Pixel
permanent einen Mini-Night-Rider !?
Ist mir noch zu helfen ?
Ja es ist Dir zu helfen.
Da die Variablen der FFT-Funktion jetzt auch im Flash abgelegt werden,
kann es vorkommen, dass das DSO. in einem Zwischenzustand der FFT
startet wenn der Flashspeicher vorher nicht initialisiert war. Da Du
Dich im FFT-Modus befindest, ist das ganze Triggermenü deaktiviert.
Abhilfe: den Mathbutton mehrfach drücken bis der normale Main-Modus
wieder aktiv ist, dann das Edge-Menü drücken und Default-Setup. Jetzt
noch die Timebase verstellen und bei nächsten mal ist alles gut.
Hayo
Hallo Hayo,
wollte eigentlich schon gestern ein paar Kommentare zu der neuen FFT
loswerden. Hab das Ganze eben mit der Version 0.82 überprüft, meine
Anmerkungen treffen soweit auch darauf zu.
1.) Überraschend gutes Ergebnis (wenn man bedenkt, daß die HW und die
Rechenleistung dafür eigentl. nicht ausgelegt ist)- Respekt!.
2.) Mit dem Cal. Signal ist mir aufgefallen, daß mit 50mV/Div der Pegel
der Grundschwingung mit ca. 160mV angezeigt wird (Probe x1,5ms/Div,
Poisson3.0). Beim Umschalten auf 25mV/Div wird er zu ca. 80mV angezeigt.
Bei den anderen Fensterfunktionen ist das Verhältnis entsprechend.
3.) Da du die Beschriftung der log. Skala an der linken Achse angebracht
hast, frage ich mich ob man das nicht auch für die lin. Skala übernehmen
könnte.
4.) Lecroy korrigiert die fft Darstellung so, daß die Spektralllinien im
Pegel dem Level im Zeitbereich entsprechen s.h. Dokument, Seite C-5
oben.
http://www.lecroy.com/tm/library/manuals/download.asp?id=784
5.) Da du bei der log. Darstellung ja nicht etwa dBm oder dBV
verwendest, sondern dB, würde ich eine auf die Grundschwingung (=0 dB)
normierte Darstellung erwarten. Oder ist die Anzeige so zu verstehen,
daß die Summe aller Spektralllinien 0dB entsprechen?
6.) Leider fehlt die Beschriftung der Freq.- Achse noch...
7.) Mir war gar nicht bewusst, welch großen Einfluss die Fensterfunktion
auch auf den Pegel der Grundfrequenz hat, umso stärker wäre eine auf 0dB
normierte Darstellung anzustreben.
8.) Eigentl. müssten doch alle Informationen zur Unterdrückung von
Aliasing zur Verfügung stehen (TB, TB-Faktor, Freq. der
Grundschwingung). Will damit sagen, könnte man nicht die Darstellung von
Frequenzen die das Nyquist- Kriterium verletzen, direkt unterdrücken?
Gruß, brunowe
@Bruno
Also grundsätzlich zur Scalierung ist anzumerken, dass sich die
Performance bei der FFT unter anderem nur bewerkstelligen ließ, in dem
auf Multiplikationen verzichtet wurde und stattdessen Shift-Operationen
eingesetzt wurden. Dadurch sind die verfügbaren Skalierungen erstmal
beschränkt. Man kann das sicher auch noch etwas feiner abstufen, wie bei
der normalen Grafikroutine, aber auch das kostet zusätzlich Zeit. Hier
muß man also abwägen.
Die Beschriftung für das Grid ist erstmal nur im Log-Modus verfügbar da
diese sich ja wegen der Normierung nicht ändert. Wenn ich den Linearen
Modus beschrifte muß ich jedesmal einen Refresh durchführen wenn der
Messbereich wechselt. Ist aber durchaus machbar. Das Gleiche gilt für
die Frequenzanzeige.
Ich habe auch schon überlegt was sich da an eleganten Lösungen so
anbietet.
Die Beschreibung von Lecroy ist sehr interessant, die werde ich mir noch
mal genauer ansehen. Ich lasse da gerne Anregungen von anderen Oszis mit
einfließen.
> 4.) Lecroy korrigiert die fft Darstellung so, daß die> Spektralllinien im Pegel dem Level im Zeitbereich entsprechen> s.h. Dokument, Seite C-5 oben.
Das war ursprünglich bei mir auch so, aber ich fand es besser die volle
Gridhöhe zu nutzen. Spricht was dagegen?
OdB bezieht sich auf die Amplitude des Signals im Zeitbereich bei
Vollaussteuerung. D.h. ein Sinussignal sollte eine Frequenzlinie mit 0
dB Verlust haben, während ein Rechteck sogar mit der Grundschwingung H1
ein wenig im +dB Bereich (Verstärkung) liegen sollte wenn im Zeitbereich
der ADC-Wandler mit den vollen 8 Bit (255) ausgesteuert ist.
Zu 8: Die Aliasfrequenzen entstehen leider nicht erst bei der FFT,
sondern schon direkt bei der Abtastung, so dass man einem Datensatz
nicht ansieht ob die Frequenzen nun echt sind oder nicht. Wenn man die
Auswirkungen kennt, kann ein Mensch das zwar auf dem Bild erkennen, aber
der Rechner kann es nicht herausrechnen - schade, sonst könnte man sich
Bandbegrenzungsfilter sparen.
Gruß Hayo
@Bruno
Ich habe mir die LeCroy-Doku noch mal genauer durchgelesen. Mit der
Skalierung der Amplitude auf die Amplitudenhöhe im Zeitbereich war hier
nicht der Skalierungsmaßstab gemeint, sondern die Korrektur der
Amplitude, wenn diese in einen gedämpften Frequenzbereich fällt. Siehe
hierzu auch meine Anleitung Seite 10 Abb. 7 - Gewichtung im
Frequenzbereich.
Eine solche Korrektur ist natürlich eine feine Sache, das wäre noch was
für die ToDo-Liste, ebenso wie die Anzeige des Leistungsspektrums. Werde
ich mir mal vornehmen...
Gruß Hayo
@Niklas
Der Screenshot funktioniert ja, wie die Anderen ja auch bereits
feststellten, prima; nur ist das Ergebnis auf dem PC doch sehr flau.
Besteht da eine Chance, dass die auf dem Scope dargestellten satte
Farben auf dem PC ein ähnliches Niveau erreichen. Also Gelb ein FFFF00,
Grün ein 00FF00 u.s.w.
Das Blassgrün in Verbindung mit dem Blassblau hat einen doch sehr
niedrigen Kontrast.
Ich möchte nicht quengelig erscheinen; das was Du hier abgeliefert
hast, hilft mir sehr und ist weit mehr, als man eigentlich in so kurzer
Zeit erwarten konnte - vielen Dank noch einmal !
Hallo Hayo,
zu 8.) hast du natürlich recht... war ein Schnellschuß- kann in meinem
Alter schon mal vorkommen ;-)
Wenn das so einfach wäre, würden das renommierte SA Hersteller schon
lange so machen.
Kannst du unter 2.) aufgeführtes Phänomen nachvollziehen?
zu 5.) Soweit kein Problem- wenn man weiß wo der Bezugspunkt, sprich 0dB
liegt.
Gruß, brunowe
Quick-Measure funktioniert prima - viel besser als erwartet.
Mir ist dabei aufgefallen, dass eine Umschaltung des Kanals via Softkey
nichts bewirkt. Erst das Aus- und wieder Einschalten von Quick-Measure
übernimmt den geänderten Kanal.
Wenn man einmal 'Measure Average' gewählt hat, wie kommt man wieder zur
vorhergehenden Einstellung (?) ist das eine Einbahnstraße ?
Ich habe die Datenkompression für Niklas' Quick-Print-Funktionen etwas
überarbeitet.
Die Datenmenge ist deutlich kleiner, die Geschwindigkeit leider nicht so
ganz. Ein SW-Dump dauert jetzt 10s, Farbe dauert 30s.
Bei Interesse stelle ich die Änderungen hier ein. (Oder zieht Ihr einen
anderen Ort vor?)
Als nächstes könnte ich die "Save to CSV"-Funktion schreiben.
Falk
Hallo Kurt,
das macht es schon deutlich einfacher, die Darstellung der einzelnen
Kanäle zu differenzieren. Auch wenn hier noch etwas Abstimmung in bezug
auf die Wahrnehmung der einzelnen Farben (annähernd gleiche Helligkeit)
erforderlich wäre. Ist das gleiche Problem, dass sich beim layouten
darstellt. Grün und Gelb recht dominant gegenüber Rot und in diesem Fall
besonders Blau.
Weitere Möglichkeit zur Datenreduktion:
Die FFT läuft jeweils nur auf einem einzigen Kanal. Die Planes der
anderen 3 Kanäle müssen nicht übertragen werden.
Das Grid, auch wenn es mehrere gibt ist immer gleich. Es reicht die
Grids durchzunummerieren und die Nummer des jeweils aktiven Grid zu
übertragen. Die eigentlichen Daten dieser Plane liegen im PC Prog als
Tabelle vor.
Es muss nicht die Cursor oder Math Plane übertragen werden, wenn die
garnicht benutzt werden...
Wenn man zuerst den aktuellen Betriebsmodus sendet und nur die nötigen
Daten solle sich die Übertragungszeit um 15-20 sec. reduzieren lassen.
@Bruno
Nein, bei mir sieht das völlig anders aus. Bei 25mV + 50mV mit
Rechteckfenster werden 40mV angezeigt, mit Poisson-Fenster nur noch ca.
12mv - Das ist ein durchaus nicht unerwartetes Ergebnis.
Hayo
Stefan, du könntest auch diese Bild mit einem Zeichenprogramm ausmalen
;-)
PaintNet zeigt direkt die HEX Werte der Farben an.
Die geraden Linien mit dem "Farbeimer", die diagonalen mit dem
Linienwerkzeug.
Wenn du die schönste Farbkombination gefunden hast kann man die im Oszi
und im Programm einbauen.
Ich bin leider Farbenblind. ;-)
Hallo,
@Stefan:
> Besteht da eine Chance, dass die auf dem Scope dargestellten satte> Farben auf dem PC ein ähnliches Niveau erreichen.
Ja, sicher. Die Werte die ich genommen habe sind nur per Daumen
und Augenmass anhand meiner Wahrnehmung vom DSO Output von mir
geschaetzt, hab' da aber nicht wirklich Zeit fuer investiert.
Wie Kurt zeigt kann man die Konstanten aendern, sicher koennen
wir in zukuenftigen Versionen die Werte ueber z.B. eine .ini-Datei
direkt vom Benutzter anpassen lassen.
@Falk:
[Optimierung RLE Algo, Zeitreduktion]
Das klingt gut, ich finde wir sollten Deine Aenderungen direkt
uebernehmen. Ich persoenlich finde das diff-Format dazu
( http://de.wikipedia.org/wiki/Diff ) am praktischsten.
> Bei Interesse stelle ich die Änderungen hier ein.> (Oder zieht Ihr einen anderen Ort vor?)
Ob wir das immer alles hier in dieses Forum posten sollten weisz
ich nicht, fuer mich waere auch die Google Group i.O.. Das pflegen
des Codes ueber eine Versionsverwaltung waere auch in Ordnung, ich
hab' hier schonmal gelesen das wohl der Service von Sourceforge
nicht so prickeln ist und Leute Probleme damit haben.
Wenn Interesse besteht kann ich sowas aber auch selbst hosten
(habe eigene Rechner in RZ).
> Als nächstes könnte ich die "Save to CSV"-Funktion schreiben.
Ja kannst Du wenn Du Zeit hast mit anfangen, ich hab' da diesbzgl.
auszer den geschilderten Vorueberlegungen nocht nichts gemacht.
Ich werde auch noch meine bereits geschriebenen ZModem Funktionen
einstellen, auch wenn da noch noch auf dem DSO die ISR Anpassung
fehlt um die verwenden zu koennen.
@Kurt:
[Nicht alle Planes uebertragen]
Daran hab' ich auch schon gedacht. In der Tat sind ein paar der 16
Planes ueberhaupt gar nicht benutzt, zudem kann man wie Du beschreibst
noch weitere ausschlieszen. Da das DSO ohnehin da "Ewigkeiten"
pro Plane braucht liesze sich da deutlich Zeit einsparen.
Es gibt allerdings ein paar Sachen zu beachten, ich hab' ja schon
die Beobachtung gemacht (im Sourcecode gibt's nen Kommentar dazu),
dass die roten Pfeile und das rote Stop(p)-Schild auf die Channel 4
Plane gelegt sind (weil die vmtl. gerade rot war, oder so...).
Ohnehin war mir zum Zeitpunkt als ich das schrieb' noch nicht klar,
welche Planes nun genau zu welchem Zweck genutzt wurden und habe
alle rausschreiben lassen, auch die Marker Planes, die gar keine
Einfaerbung erhalten.
Also ja. Auch die Zeitersparnis die wir dadurch gewinnen koennen wir
bitter gebrauchen. Vllt. noch fuer die Entwicklung die Moeglichkeit
offen lassen trotzdem alles zu uebertragen, um wie schonmal gesagt
Darstellungsfehler einfacher lokalisieren zu koennen.
@alle:
Sollten wir vllt. irgendwo eine stets aktuell gehaltene Liste haben
"wer arbeitet gerade woran" um doppelte Arbeit zu vermeiden?
Niklas
Kurt,
Ich musste eben auch feststellen, dass es nicht ganz so trivial ist wie
es auf den ersten Blick schien :-\
Ein paar Linien mit Corel auf einer schwarzen Fläche sind ähnlich blass,
wenn nicht schlimmer; hingegen kommt ein Screenshot aus dem Layout doch
deutlich "leuchtender" rüber - mir fehlt jetzt ein sich am Kopf
kratzender Smiley ;)
Ich vermute mal, dass mein Bildschirm bescheiden abbildet oder meine
Augen schlecht eingestellt sind...
Ich glaube auch es sind deine Augen ;-)
Im Layout will man immer möglichst große Flächen haben, wohingegen im
Screenshot die Linien möglichst dünn sein sollen. Das verbessert deren
Sichtbarkeit natürlich nicht gerade.
Hallo Kurt,
> Den Wechsel von .c auf .cpp hat das Studio vorgegeben. Nötig ist er> glaube ich nicht.
Ja, ich hab' die w2000a-screenshot.c nur zu nem .cpp gemacht weil
der Parser die ComTools.h sonst nicht fressen wollte. Die benoetigten
Sachen die die ComTools machen koennen wir denke ich auch leicht
selbst neu bauen.
> Die unistd darf bei mir nur unter Linux eingebunden werden.> Ersetzen von (int) usleep(1000) durch (void) Sleep(1000)
sleep(1000) wuerde 1000 Sekunden warten unter allen mir
bekannten libc... (Ist abgesehen davon auch POSIX)
> Ersetzen von snprintf() durch sprintf_s().> Aus fopen wird fopen_s
Noch nie irgendwo implementiert gesehen, was machen die
anders als die n-Versionen?
http://netbsd.gw.com/cgi-bin/man-cgi?snprintf
Die n sind egtl. soweit ich weisz auch C99...
> Dann gibt es noch Probleme mit optarg und getopt()...
Zu erwarten...
> Die Frage ist ob die Änderungen auch mit Linux laufen.
Leider nicht.
> PS:> Mit MinGW geht es bei mir aber auch so. Ich musste erstmal> googlen wie man damit kompiliert. ;-)
Wollen wir bei MinGW bleiben, oder statt der n die ganz normalen
Versionen verwenden und getopt() selbst implementieren?
Statt fopen() geht ja auch open(), oder fehlt das auch?
Niklas
Hallo, nochmal,
urgs, merke gerade das ich oben als ich von den Planes mit
(mir) noch nicht bekannten Funktionen sprach da die Marker
Planes erwaehne. Da meinte ich natuerlich die Memory Planes.
Niklas
Da dieser Thread mittlerweile die 1000 Einträge überschritten hat, wäre
es da evtl. sinnvoll ihn noch einmal zu splitten (?) funktioniert ja bei
Hardware | Software auch ganz gut.
Dieser hier würde dann für Rückmeldungen bzgl. eventueller Fehler,
Usability und ggf. Wunschdenken aktiv bleiben, während sich ein neuer
Thread in Richtung allgemeine Entwicklung, Tools, sowie konzeptionelle
Ausrichtung und Strategien abspaltet... ich vermute mal, dass eine
Abspaltung der überschaubaren Anzahl aktiver Entwickler disziplinierter
vonstatten gehen würde, als die Vielzahl der hier mitlesenden auf einen
neuen Thread umzubiegen.
Ist nur so eine Idee - bitte nicht kreuzigen :)
Ich denke eine weitere Aufsplittung würde es eher unübersichtlicher
machen, allerdings könnte man den Thread evtl. mal wieder neu aufsetzen
damit die Beiträge überschaubar bleiben.
Hayo
Hallo Hayo,
ich habe folgendes Problem:
ich nehme ein Signal auf (5µs/div), drücke auf Stop. Signal bleibt
stehen. Ich zoome rein auf 2µs/div, Signal wird kurz vergrößert
dargestellt, so wie es gedacht ist. Aber dann wird auch schon ein neues
aufgezeichnet.
Kannst du das mal fixen?
Gruß,
Stefan
Hi, anbei die diffs für die überarbeiteten Screenshot-funktionen.
Das diff für die Firmware ist für 0.82, kann aber einfach am Ende von
src/display_t.cpp gegen die drei ursprünglichen Funktionen,
tschuldigung, Methoden, is ja C++ ;-) ausgetauscht werden.
Das diff für den PC-Teil bezieht sich auf die Version 0.2, wenn Niklas
den entsprechend einpflegen könnte?
@Hayo: Mein Vorschlag zur Bedienung der Screenschot-Funktion:
Quick-Print macht einen Screenshot wie in 1.2.BF.0.82.
Da die Screenshots und Rohdaten ohne ein Stück Software auf dem PC
sowieso sinnlos sind, kann die PC-Soft einfach ein Kommand über RS232
schicken, das die gewünschte Aktion startet.
Ich stelle mir das so vor, daß die bisherige Steuerung unverändert
bleibt, abgesehen von dem Zeichen "starte spezielle funktion" STX, ASCII
0x02.
Hardware::ISR_UART bekommt eine simple State-machine, die alles
durchreicht, außer STX-LEN-Daten-ETX und nach ETX ein Flag setzt. Das
könnte mit UART_NewData=2 realisiert werden.
In Hardware::Keyboard_Interface könnte dann etwa so aussehen:
1
switch(UART_NewData){
2
case1:UART_NewData=0;//reset UART ISR flag
3
if(UART_RXData=='a'){lMenuKey=0;}// Acquire
4
....
5
case2:handle_remote_control(...)
6
}
7
UART_NewData=0
Ich würde das einbauen, wenn wir uns nicht gegenseitig dabei stören.
Gruß,
Falk
Stefan schrieb:
> Da dieser Thread mittlerweile die 1000 Einträge überschritten hat, wäre> es da evtl. sinnvoll ihn noch einmal zu splitten (?) funktioniert ja bei> Hardware | Software auch ganz gut.
Wie wäre es mit einem eigenen Forum. Dann könnte man die Threads nach
HW, Software, Diskussionen etc. trennen.
Mir gefällt "Phorum" ganz gut und einen Server hätte ich dafür.
Falk
@BF.0.82: Läuft ziemlich gut. 3 Dinge sind mir aufgefallen:
* About Oscilloscope: Auch hier gibts Artefakte, wenn man z.B. vorher
im Quick Measurement Menü war
* Quick Measurement: Wenn ich z.B. das Probe Comp Signal (bei
200uS/div) anschaue, dann ist die Periode dauerhaft 1.00ms, aber die
Frequenz flackert zwischen 995.0 und 999.0 Hz, ohne dass die
Nachkommastelle mal ungleich wäre. Auch die Spannungsmessungen wie z.B.
Pk-Pk ändern nie ihre Nachkommastelle.
* UART: Wenn ich im Quick Measurement Modus bin, reden die
Messfunktionen bei jedem Aufruf auf der UART. Solche Meldungen, die beim
Entwickeln sehr helfen, solltet ihr unter Zuhilfenahme eines Makros
ausspucken, damit die in den Releases still sind. Das kostet alles
unnötige Zeit, wenn andauernd auf die UART geschrieben wird.
Falk Willberg schrieb:
> Wie wäre es mit einem eigenen Forum. Dann könnte man die Threads nach> HW, Software, Diskussionen etc. trennen.>> Mir gefällt "Phorum" ganz gut und einen Server hätte ich dafür.
Nochmal das Angebot: Nutzt doch das phpBB auf SourceForge mit:
http://sourceforge.net/apps/phpbb/welecw2000a/
SourceForge-Handles haben eh' die meisten schon, und ihr könnt gern alle
Mod- oder Admin-Rechte haben und eine beliebige Menge Foren und
Kategorien anlegen. Würde mich freuen, wenn das Forum dort mehr genutzt
würde.
Daniel H. schrieb:
...
> Nochmal das Angebot: Nutzt doch das phpBB auf SourceForge mit:> http://sourceforge.net/apps/phpbb/welecw2000a/
Gefällt mir ;-)
Mal sehen, ob es ankommt...
Falk
@Daniel
SFN könnte man natürlich machen, aber ich fand das immer recht zäh und
langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit
eigene Foren einzurichten ist natürlich nicht übel.
@Falk
Auch Dein Angebot einen Server zur Verfügung zu stellen ist recht
reizvoll da dann die Kontrolle quasi "in unserer Hand" bzw. in Deiner
läge. Vermutlich wären auch die Antwortzeiten attraktiver als bei SFN.
Zudem bestünde wohl auch die Möglichkeit überlaufende Threads in
regelmäßigen Abständen zu archvieren und zu bereinigen, so dass nicht
immer neue Treads nötig sind.
Zum UART: Von meiner Seite her keine Einwände. Ich bin da nicht mehr
zugange, ich hatte nur für Niklas aufgeräumt - da müßtest Du Dich also
am Besten mit Ihm abstimmen. Meine Baustelle ist nach wie vor die FFT,
die ich gerade komplett überarbeite und erweitere (angeregt durch Bruno
und die LeCroy Broschüre).
Zu Deiner zerschossenen USB-Schnittstelle: Poste das doch noch mal im
Hardwarethread, eigentlich müßte doch nur das Flash fur den
USB-Controller neu geschrieben werden wenn ich mir das so überlege. Da
waren doch schon einige aktiv glaube ich.
Und zu guter Letzt finde ich es prima dass Du wieder aktiv dabei bist,
nachdem ich einige Zeit nichts mehr von Dir gehört hatte.
Gruß Hayo
Hallo,
ich würde auch gerne mal Eure neue FW testen, bevor ich allerdings etwas
kaputt mache, will ich vorher nochmal kurz nachfragen.
Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim
nächsten Oszi Start dann wieder weg?
Kann ich das unter Windows einfach mit der WelecUpdater.exe machen? Oder
muss ich mir vorher nen Perl-Interpreter zulegen, damit ich das mit dem
Skript machen kann?
Danke! Gruß,
Michael
Hayo W. schrieb:
> @Daniel>> SFN könnte man natürlich machen, aber ich fand das immer recht zäh und> langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit> eigene Foren einzurichten ist natürlich nicht übel.
Ich habe da jetzt einfach mal einen Thread zum Thema screendump
aufgemacht.
Wenn sich das nicht bewährt, kann ich auch ein Forum bereitstellen.
...
> Zum UART: Von meiner Seite her keine Einwände. Ich bin da nicht mehr> zugange, ich hatte nur für Niklas aufgeräumt - da müßtest Du Dich also> am Besten mit Ihm abstimmen.
Ok. Ich denke, Niklas hat es mitbekommen. Ich brauche die ISR
wahrscheinlich nicht, meine Erweiterung sollte sich in
Hardware::Keyboard_Interface einbauen lassen.
> Meine Baustelle ist nach wie vor die FFT,> die ich gerade komplett überarbeite und erweitere (angeregt durch Bruno> und die LeCroy Broschüre).
Sehr schön. Ich habe mal einen screendump von einer FFT angehängt.
Eingang ist der Sonnenschirm als Antenne ;-)
> Zu Deiner zerschossenen USB-Schnittstelle: Poste das doch noch mal im> Hardwarethread, eigentlich müßte doch nur das Flash fur den> USB-Controller neu geschrieben werden wenn ich mir das so überlege. Da> waren doch schon einige aktiv glaube ich.
Werde ich mal machen. Mit RS232 komme ich aber gut aus. Schneller ist
die sowieso...
> Und zu guter Letzt finde ich es prima dass Du wieder aktiv dabei bist,> nachdem ich einige Zeit nichts mehr von Dir gehört hatte.
Ich habe mich jetzt wieder hineingefunden und werde das Scope eine Weile
nicht zum Arbeiten brauchen.
Als erste Fleißarbeit habe ich meine neue Baustelle aufgeräumt:
>Sehr schön. Ich habe mal einen screendump von einer FFT angehängt.>Eingang ist der Sonnenschirm als Antenne ;-)
Coole Idee ;-)
>Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim>nächsten Oszi Start dann wieder weg?
Die ist beim nächsten Start wieder weg. Aber trotzdem vorsicht, da die
Firmware trotzdem Einstellungen in den Flash speichert. Also vorher auf
alle Fälle einen Backup ziehen. Da ist eine Sicherung der
Config-Bereichs mit dabei.
Ich würde mir Perl installieren. Der WelecUpdater ist schnarch langsam.
Ob .ram damit überhaupt geht, hat glaube ich, keiner mehr ausprobiert.
Gruß,
Stefan
Falk Willberg schrieb:
...
> Das diff für den PC-Teil bezieht sich auf die Version 0.2, wenn Niklas> den entsprechend einpflegen könnte?
Hier das diff-file für 0.3.
Falk
Michael schrieb:
> ich würde auch gerne mal Eure neue FW testen, bevor ich allerdings etwas> kaputt mache, will ich vorher nochmal kurz nachfragen.
Beides eine gute Idee... allerdings steht eigentlich so ziemlich alles
in den Beipackzetteln die ich mit dazugetan habe. Trotzdem hier schnell
noch ein Antwort auf Deine Fragen.
> Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim> nächsten Oszi Start dann wieder weg?
So ist es. Aber wie Stefan schon anmerkte - die neue Version verwaltet
die im Flash abgelegten Daten etwas anders. D.h. beim nächsten Start der
alten Software kann es merkwürdige Nebenwirkungen geben, die sich jedoch
mit Default Setup beheben lassen sollten. Auf jeden Fall solltest Du Dir
mit dem Welecupdater ein Backup Deines Flash machen - Anleitung dazu
liegt im Doku Ordner der Betaversion.
> Kann ich das unter Windows einfach mit der WelecUpdater.exe machen?
Nein! Der Welecupdater kann es nicht, und zwar einfach deswegen nicht,
weil er die Endung .ram nicht unterstützt. Du müßtest die TomCat.ram
einfach nur umbenennen in TomCat.flash (aber nicht mit der Richtigen
verwechseln ;-) ), dann sollte es gehen.
> Oder muss ich mir vorher nen Perl-Interpreter zulegen,> damit ich das mit dem Skript machen kann?
Wenn Du das öfter machen möchtest, kann ich das nur dringend empfehlen,
da
der Unterschied 20 Minuten zu 3 Minuten doch schon gewaltig ist.
Gruß und viel Spaß
Hayo
@Falk
> Als erste Fleißarbeit habe ich meine neue Baustelle aufgeräumt:
Sehr schön, wenn wir so weitermachen schrumpft das File noch unter 1,2
MByte trotz neuer Funktionen ;-)
Auf jeden Fall wird der Code langsam immer übersichtlicher und
strukturierter.
Gruß Hayo
Hallo,
nachdem ich euren Thread jetzt eine Weile verfolgt habe, habe ich mir
auch ein Welec bestellt, das nächste Woche eintrudeln müsste. Zur Zeit
bin ich noch im Prüfungsstress, danach möchte ich mich aber auch an der
Verbesserung des Gerätes beteiligen.
Achja, was mir noch aufgefallen ist: können die Dinger wirklich nur bis
zu 5V/div nach oben? Mein jetziges Oszi lässt sich auf bis zu 50V/div
schrauben und zumindest 10V/div und 20V/div habe ich auch schon
desöfteren benutzt.
Mir fehlt noch der Überblick über Hard-/Software des Welec - kann man
die Messbereiche noch hinzufügen oder steht dem etwas entgegen?
Viele Grüße,
Michael
Hayo W. schrieb:
> @Daniel> SFN könnte man natürlich machen, aber ich fand das immer recht zäh und> langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit> eigene Foren einzurichten ist natürlich nicht übel.
Erstmal gehts ja nur um das Forum. Das ist ein phpBB und entspricht
somit wohl dem de-facto-Standard für Forensoftware. Die Antwortzeit ist
wesentlich besser als bei diesen Mega-Threads hier im Forum
> Zudem bestünde wohl auch die Möglichkeit überlaufende Threads in> regelmäßigen Abständen zu archvieren und zu bereinigen, so dass nicht> immer neue Treads nötig sind.
Das können wir bei SF auch. Da gibts vollen Zugriff auf die übliche
phpBB-Administration. Allerdings sollte sowas garnicht nötig sein, denn
meiner Meinung nach sollte für das, wofür hier Threads verwendet werden,
im phpBB ein Unterforum angelegt werden, in dem dann für
unterschiedliche Gedankengänge unterschiedliche Threads genutzt werden
;) Aber das ist sicherlich Geschmackssache (des Moderators =)
> Ich habe da jetzt einfach mal einen Thread zum Thema screendump> aufgemacht.> Wenn sich das nicht bewährt, kann ich auch ein Forum bereitstellen.
Wenn überhaupt sollten wir einfach mal beschließen, das eine oder das
andere Board zu benutzen und dann hier "Schilder" aufstellen ähnlich
(wie im alten Welec-Thread, dass nun hier und im HW-Thread gepostet
werden soll), dass Diskussionen in Zukunft woanders stattfinden sollen.
Ich möchte nicht noch eine weitere Aufspaltung auslösen (wie schon mit
dem Google Groups Kram).
Aktuelles:
- Die Option -c <serial-port> geht auch unter Linux
- Mit einer kleinen Firmwareänderung wird der Dump vom Programm
gestartet
- Man kann die Option "-m" für einen monochromen screendump angeben
(10s)
- Mit "-d" werden die Daten als CSV ausgegeben (7s).
- Ohne Optionen -c oder -m wird ein farbiger screendump ausgegeben (30s)
Die entsprechenden Patches kommen morgen...
Die Grafik zeigt die Ausgabe, die "kst" aus dem CSV-file erzeugt.
Falk
Daniel H. schrieb:
> Wenn überhaupt sollten wir einfach mal beschließen, das eine oder das> andere Board zu benutzen und dann hier "Schilder" aufstellen ähnlich> (wie im alten Welec-Thread, dass nun hier und im HW-Thread gepostet> werden soll), dass Diskussionen in Zukunft woanders stattfinden sollen.
Gute Idee. Ich werde meine Änderungen künftig in SFNET ablegen und hier
darauf hinweisen.
Dieses Forum ist nicht schlecht, aber mit Themen, Unterthemen etc. ist
SFNET einfach besser geeignet.
> Ich möchte nicht noch eine weitere Aufspaltung auslösen (wie schon mit> dem Google Groups Kram).
Ich werde den Google-Groups-Kram bald zumachen und einen Hinweis hierhin
und nach SFNET anbringen (wenn ich herausfinde, wie das geht).
Falk
@Stefan
Nur kurz zur Abstimmung, ich habe die vertikalen Cursordaten korrigiert,
so dass jetzt alle Spannungen korrekt angezeigt werden
-> void Display::CALCCURSORDATA(void)
Hayo
@Stefan
Nochmal kurz zur Abstimmung - ich schmeiße die bei einigen
Anzeigefunktionen die sich wiederholenden switch() Anweisungen raus und
ersetze sie durch indizierten array fetch. -> Display::MEASURETIME(),
CALCCURSORDATA(), CALCPRETRIGGER(), CALCTIMEBASE()
Hayo
Niklas O. schrieb:
Hallo Niklas,
> @Kurt:> [Nicht alle Planes uebertragen]>> Daran hab' ich auch schon gedacht. In der Tat sind ein paar der 16> Planes ueberhaupt gar nicht benutzt, zudem kann man wie Du beschreibst> noch weitere ausschlieszen. Da das DSO ohnehin da "Ewigkeiten"> pro Plane braucht liesze sich da deutlich Zeit einsparen.
Im aktuellen Stand werden ja so weit ich das überblicke sämtliche Planes
übertragen und dann auf dem PC genauso wie auf dem Oszi mit Farben
versehen und übereinandergelegt. Bei der Übetragung der Planes geht viel
Zeit drauf. Wäre folgender Weg nicht besser?
Beispiel für drei Planes (A, B, C) wobei A die oberste (dominante) Plane
ist:
Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt
ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der
Wert "1" gemerkt/übertragen. Wenn der Pixel in Plane A nicht gesetzt ist
wird geprüft, ob der Pixel in Plane B gesetzt ist. Wenn ja, dann erhält
dieser Pixel den Wert "2" und wird gemerkt (bzw. übertragen). Wenn der
Pixel auch in Plane B nicht gesetzt ist, dann wird Plane C geprüft. Wenn
der Pixel hier gesetzt ist, erhält dieser Pixel den Wert "3" wenn nicht,
erhält der Pixel den Wert "0" (für transparent bzw. schwarz).
Das Bild, das übertragen wird, entspricht dann 1:1 dem auf dem Oszi
dargestellten Bild und die zu übertragende Datenmenge reduziert sich auf
ein Viertel, da nun pro Pixel (bei 16 Planes) statt bisher 16 Bits (1
pro Plane) nur noch vier Bits (2^4 == 16 Planes) übertragen werden
müssen.
RLE funktioniert hier natürlich immer noch, da man ja statt einzelner
Bits auch 4-Bit Sequenzen zusammenfassen kann. Auch auf dem Oszi dürft
sich auch einiges an Laufzeit sparen lassen. Für das Überlagern der
Planes im Oszi geht zwar etwas Zeit drauf, aber statistisch müssen nur
noch 50% der Plane-Daten gelesen werden, da die "hinteren" Planes nach
einem Match gar nicht mehr gelesen werden müssen.
Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben,
aber schnelle Screenshots sind noch schöner.
Gruß,
Bernd
Bernd O. schrieb:
>> Hallo Niklas,
Ich bin zwar nicht Niklas, habe aber seine Routinen bearbeitet.
...
> Beispiel für drei Planes (A, B, C) wobei A die oberste (dominante) Plane> ist:>> Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt> ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der> Wert "1" gemerkt/übertragen. Wenn der Pixel in Plane A nicht gesetzt ist> wird geprüft, ob der Pixel in Plane B gesetzt ist. Wenn ja, dann erhält> dieser Pixel den Wert "2" und wird gemerkt (bzw. übertragen).
...
Klingt gut! Sollte sich einfach implementieren lassen.
> Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben,> aber schnelle Screenshots sind noch schöner.
Auf 30s sind wir schon, mit Deinem Vorschlag könnte das noch schneller
werden.
Ich muß jetzt mal das protected flash zurückspielen :-( aber dann gucke
ich mal...
Gruß,
Falk
Hallo Hayo,
die Änderungen gehen klar. Muss ich dadurch was an den QM-Funktionen
ändern? Magst du dir mal einen SVN-Client zulegen. Dann würde ein Klick
reichen und alle hätten gleich die aktuellste Version. Geht, wenn einmal
eingestellt, auch mit SourceForge "relativ" fix.
Gruß,
Stefan
Leider gibt es, meiner Meinung nach, unter Linux keinen wirklich
perfekten Client wie z.B. Tortoise unter Windows. Bei mit leistet "eSVN"
noch am wenigsten Widerstand. KSVN geht bei mir mit SF nur sehr träge.
Gruß,
Stefan
Stefan E. schrieb:
> Leider gibt es, meiner Meinung nach, unter Linux keinen wirklich> perfekten Client wie z.B. Tortoise unter Windows.
Im alltäglichen Umgang braucht man eigentlich nur eine Handvoll
Kommandos:
svn checkout
svn update
svn status
svn commit
svn add
damit sind 95% aller Tätigkeiten abgedeckt.
Dafür kann man gut, auch als nicht Kommandozeilen-Freund, mit
der Kommandozeile leben.
Gruß,
Günter
Falk Willberg schrieb:
> Ich muß jetzt mal das protected flash zurückspielen :-( aber dann gucke> ich mal...
Leider hilft ein Flash-Update nicht gegen kalte Lötstellen oder
Wackelkontakte. Jedenfalls startet die Firmware nur noch bis
Ein wenig ans Gehäuse zu klopfen hat das Problem kurzfristig lösen
können.
Der GERMS-Monitor funktioniert aber noch.
Schön, wenn man drei Jahre Garantie hat :-)
Falk
Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für
typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?
Einen Logic-Analyzer hab' ich zwar bereits, aber der ist PC-basiert und
oft möchte man einfach nur mal kurz einen Datenstrom verifizieren; da
würden die 2-4 Kanäle -je nach Protokoll- völlig ausreichen...
Na geil.
Ich gebe zu, dass ich mich durch die Anfrage von Hayo inspiriert sah.
Die Idee schwirrte mir schon so lange im Kopf rum, dass es wohl einfach
nur eines Triggers bedufte.
@Stefan
finde ich auch gut :-)
@
0.82 funktioniert bei mir (W2024A) :-)
Was mir auch noch aufgefallen ist:
Wenn ich "Search Zero Lines" drücke, wandern die Kanäle 3 und4 ein paar
Pixel nach unten. ?!
erst nach "calibrate DAC" sind sie wieder in der Mitte ..
Ist das bei Euch auch so ?
Leider schaut das 1kHz Signal bei 1ms/div noch immer so aus wie bei
200ms/div
Vielleicht wäre es sinnvoll, dieses Problem voranging zu beheben, damit
man damit auch richtig messen kann .( "Quick Meas" zeigt dann 3,84Hz an
)
Bei 1ms/div zeigt es mit "Quick Meas" richtig die 1kHz an :-)
Und ein Großes Lob und DANKE, an alle die hier so toll mitarbeiten!!
l.G. Roberto
@Roberto
Was du bemängelst (und misst) ist das typische Antialiasing das bei
allen DSO's auftritt. Es ist dem Anwender überlassen die richtige
Zeitbasis einzustellen (wenn das Signal nicht bekannt ist einfach mit
einer möglichst hohen sample-rate beginnen und runtergehen bis das
Signal richtig dargestellt wird).
Martin
>Leider schaut das 1kHz Signal bei 1ms/div noch immer so aus wie bei>200ms/div>Vielleicht wäre es sinnvoll, dieses Problem voranging zu beheben, damit>man damit auch richtig messen kann
Das ist nur eine "optische Täuschung" (Aliasing), die durch das Abtasten
bei zu geringer Frequenz entsteht.
Unter Linux habe ich die besten Erfahrungen mit "rapidsvn"
(http://rapidsvn.tigris.org/) gemacht. Ist aber denke ich bei jedem
unterschiedlich.
Svn selbst ist ziemlich cool, hat aber den Nachteil, dass es auf
Client-Seite das doppelte an Speicherplatz für die Sourcen braucht.
PS:
"svn diff" als Befehl auf der Kommandozeile ist auch sehr nett.
Damit kann mensch eine Projektbetreiber seine Änderungen schicken,
wenn mensch selbst keinen Schreibzugriff auf das Repository hat.
Hab gerade die 1.2.82 eingespielt. Funktioniert leider erstmal gar nicht
gut.
Im Math Menü habe ich beim FFT-Softkey ein Rufzeichen drinnen. Wen ich
in ein anderes Menü wechsle bleibt dieses Rufzeichen erhalten.
Zusätzlich im Softkey "1+2" ein paar Artefakte.
Das Math-Menü reagiert bei mir gar nicht. Auf keinen Tastendruck.
Wenn ich "Quick-Print" drücke hängt sich das Oszi komplett auf. Es geht
gar nichts mehr.
Die violette Math-Linie, die angezeigt wird sobald der Math-Modus aktiv
ist, durchbricht Menüs. Zb das Quick-Measure Menü. Wobei das eher ein
Minor Bug ist.
Ich denke, das Beste ist wenn ich den Komplett-Dump neu einspiele.
lg Robert
@Robert
Wenn sich das Problem durch Default Setup, Drehen an der Timebase und
Neustart nicht beheben läßt, ist das Einspielen eines Dumps in der Tat
die beste Lösung. Bei mir war das auch schon mal nötig, danach ist dann
aber alles wieder in Ordnung.
Hayo
Robert S. schrieb:
...
> Wenn ich "Quick-Print" drücke hängt sich das Oszi komplett auf. Es geht> gar nichts mehr.
Das ist normal, sollte aber nach ca. 30s vorbei sein.
Falk
@Falk
> spurious interrupt number: .................
die gleiche Fehlermeldung hatte ich beim versehentlichen Überschreiben
des Stacks als ich eine Assemblerroutine mit falschen Parametern
versorgt habe. Bist Du sicher, dass es sich um einen Hardwarefehler
handelt?
Hayo
Hallo,
Da ich auf meinem Windowsrechner keinen Platz für ein zweites
Betriebssystem habe konnte ich bisher den Source nicht selbst
compilieren.
Jetzt habe ich jedoch auf dem ftp server von altera die cygwin version
des compiler's gefunden! (in der Version 3.2)
Mit dem ist es möglich auch unter Windows an der SW Entwicklung mit zu
machen.
Anbei eine kleine Anleitung in englisch (sicherlich noch
verbesserungswürdig).
Martin
Hi Martin,
das ist cool, dann kann ich auch im Urlaub in Italien weiterentwickeln,
mein Lappy hat nämlich nur Windows drauf (meine Frau wird mich
steinigen).
Ich werde das mal nach Deiner Anleitung versuchen.
Gruß Hayo
Wenn deine Frau den ersten Stein aufhebt, dann mach' ihr klar, wie viele
arme kleine Wittig User sie ins Unglück stürzen würde. Vielleicht lässt
sie dich dann uns zu liebe am Leben und zielt nur auf Körperteile, die
nicht zur Firmwareentwicklung benötigt werden...
Kurze Anfrage zum Organisatorischen:
Nachdem jetzt Google.Groups geschlossen ist, wo kann ich außer hier noch
das komplette Firmwarepaket hochladen? Gibt es da auf SFN eine
Möglichkeit?
Hayo
Ja, die gibt es. Ich habe dir mal die Berechtigungen gesetzt, damit du
Releases erstellen kannst. Hier ist alles erläutert:
http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download
Falls es nicht klappen sollte, können wir das ja mal zusammen
durchgehen, Skype-Daten von mir sind ja überall zu finden. Bin
allerdings erst morgen abend wieder richtig zugegen (Prüfungsstress).
Konkrete Fragen kann ich sonst auch hier oder per Mail/PN beantworten.
Hallo werte Gemeinde,
ab sofort gibt es die aktuellen Open Source Releases hier:
https://sourceforge.net/projects/welecw2000a/files/
Zur Zeit ist noch die 0.82 das aktuelle beta Release, aber das Nächste
ist schon in Arbeit und kommt hoffentlich zum Ende der Woche.
Gruß Hayo
Hallo,
ist ja einiges in den letzten paar Tagen in meiner Abwesenheit
passiert :)
@Falk:
Hab' Deine Patches gesehen und werde die die naechsten
Tage migrieren, wohl gar direkt ins SourceForge SVN
Repository, wenn ich das richtig sehe das ihr euch
entschlossen habt dieses zu nutzen.
Schoen das wir jetzt auf 30 Sekunden sind. Wobei sich mir
jetzt die Frage stellt, ob da nicht auch die auf 1/8 reduzierten
Funktionsaufrufe etwas dazu beigetragen haben (die Komplexitaet
ist ja an sich etwas gestiegen). Hast Du schonmal probiert,
aus der RLE Funktion ein Makro zu machen? (ich gehe mal
ungeprueft davon aus dass der GCC die Funktion nicht inlined)
@Bernd:
Das was Du beschreibst ist in etwa das was bei dem S/W Dump
passiert, nur wird dort dann gleich auch noch die Farbe/dominante
Plane mit weg geworfen. Zeitlich waren das trotzdem noch
iirc. 10-15 Sekunden allein an Rechenzeit. Ansonsten gebe ich Dir
wie Falk auch Recht. Die Frage ist, ob jetzt Falks
Verbesserungen plus Planes aussparen (wie Kurt vorschlug)
schneller waere oder Dein Neuansatz. Erstere (alte) Loesung
waere flexibler und bereits implementiert, von daher wuerde
ich, sollte letztere nicht schneller sein, dabei bleiben.
@Falk: Hast Du da diesbzgl. in der Zwischenzeit schon
weiter gemacht?
Niklas
Jürgen schrieb:
>> Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für>> typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?>> Aber sicher wäre das Klasse!!
Ich finde die Idee auch gut, aber das sollten wir erstmal auf der
Wishlist unterbringen und die Realisierung erst dann vornehmen wenn wir
vom beta Status weg sind.
Gruß Hayo
@Niklas
Die diffs von Falk werde ich in die nächste Beta einpatchen. Vielleicht
kann ja jemand eine aktuelle Windowsversion (.exe) bereitstellen, da
dann die alten Programme nicht mehr kompatibel sind zum Datenformat.
Ich werde meine Releases wie gehabt als Komplettpaket bereitstellen nur
jetzt mit der SFN Releaseverwaltung
Gruß
Hayo
Niklas O. schrieb:
...
> @Falk:> Hab' Deine Patches gesehen und werde die die naechsten> Tage migrieren, wohl gar direkt ins SourceForge SVN> Repository, wenn ich das richtig sehe das ihr euch> entschlossen habt dieses zu nutzen.>> Schoen das wir jetzt auf 30 Sekunden sind. Wobei sich mir> jetzt die Frage stellt, ob da nicht auch die auf 1/8 reduzierten> Funktionsaufrufe etwas dazu beigetragen haben (die Komplexitaet> ist ja an sich etwas gestiegen).
Das frage ich mich auch. Leider habe ich keine Informationen, welche
Operationen, wieviel Last erzeugen. Im Standardfall (Sehr viele gleiche
Bytes), passiert aber ca. 60.000-mal nicht anderes als ein increment und
ein 16-Bit Vergeich.
> Hast Du schonmal probiert,> aus der RLE Funktion ein Makro zu machen? (ich gehe mal> ungeprueft davon aus dass der GCC die Funktion nicht inlined)
Das dürfte die Code-Größe gewaltig steigern (640*480-mal die
RLE-Funktion...)
> @Bernd:> Das was Du beschreibst ist in etwa das was bei dem S/W Dump> passiert, nur wird dort dann gleich auch noch die Farbe/dominante> Plane mit weg geworfen. Zeitlich waren das trotzdem noch> iirc. 10-15 Sekunden allein an Rechenzeit. Ansonsten gebe ich Dir> wie Falk auch Recht. Die Frage ist, ob jetzt Falks> Verbesserungen plus Planes aussparen (wie Kurt vorschlug)> schneller waere oder Dein Neuansatz.
Wenn ich das richtig sehe, müssen wir einfach die Nummer der ersten
Plane mit gesetztem Pixel (4 Bit) statt eines Bits übertragen. Ist
simpel zu implementieren. Evtl. muß die Reihenfolge der Planes in der
Definition geändert werden.
> Erstere (alte) Loesung> waere flexibler und bereits implementiert, von daher wuerde> ich, sollte letztere nicht schneller sein, dabei bleiben.> @Falk: Hast Du da diesbzgl. in der Zwischenzeit schon> weiter gemacht?
Leider ist mein Scope defekt. Das geht morgen erstmal zur Reparatur.
Ich sage Bescheid, wenn ich weitermachen kann, bis dahin lasse ich den
Kram in Ruhe.
Inzwischen mache ich mich auch mit SVN vertraut.
Vielleicht bastele ich inzwischen ein ppm2splashlogo.pl ;-)
Falk
P.S.: Ich finde es prima, daß wieder mehr Leute dazu beitragen, ein
Scope so zu verbessern, daß Anwenderwünsche direkt berücksichtigt werden
können.
Hallo Hayo,
> Die diffs von Falk werde ich in die nächste Beta einpatchen. Vielleicht> kann ja jemand eine aktuelle Windowsversion (.exe) bereitstellen, da> dann die alten Programme nicht mehr kompatibel sind zum Datenformat.
Ja das werde ich machen. Den Sourcecode fuer die Tools wuerde ich dann
unter pc/screenshot/ einpflegen.
> Ich werde meine Releases wie gehabt als Komplettpaket bereitstellen> nur jetzt mit der SFN Releaseverwaltung
D.h., (noch) nicht den Sourcecode im SVN Repository pflegen? Haette
den Vorteil das wir alle direkt Aenderungen committen koennten ohne
dass Du die selbst einbauen muesstest. Damit man sich nicht in die
Quere kommt koennten wir noch Branches machen, aber im Moment sollten
wir auch ohne auskommen. Oben wurden ja schon ein paar SVN-Clients
genannt. Ich faend's super wenn wir uns darauf einigen koennten
das SVN zu nutzen. Kleine Bugfixes und Verbesserungen wie zuletzt
das charTOlMenuKey Array von Falk waeren so sofort eingebaut und auch
von allen Interessierten noch vor dem naechsten offiziellen Release
getestet. Ich koennte auch etwas wie einen automatischen
"Nightly Build" bereit stellen, also eine fertige Firmware die den
aktuellen Stand im Repository wiederspiegelt.
Niklas
Hallo Falk,
>> Hast Du schonmal probiert,>> aus der RLE Funktion ein Makro zu machen? (ich gehe mal>> ungeprueft davon aus dass der GCC die Funktion nicht inlined)> Das dürfte die Code-Größe gewaltig steigern (640*480-mal die> RLE-Funktion...)
Stimmt, bloede Idee. (auch wenn man das auf 640*480/8 runter
dreht noch...)
>> @Bernd:>> Das was Du beschreibst ist in etwa das was bei dem S/W Dump>> passiert, nur wird dort dann gleich auch noch die Farbe/dominante>> Plane mit weg geworfen. Zeitlich waren das trotzdem noch>> iirc. 10-15 Sekunden allein an Rechenzeit. [..]>> Wenn ich das richtig sehe, müssen wir einfach die Nummer der ersten> Plane mit gesetztem Pixel (4 Bit) statt eines Bits übertragen. Ist> simpel zu implementieren. Evtl. muß die Reihenfolge der Planes in der> Definition geändert werden.
Ja, stimme ich Dir zu. Waere 'ne simple Modifikation der B/W Funktion,
baue ich mal ein.
> Leider ist mein Scope defekt. Das geht morgen erstmal zur Reparatur.
:/ Bin mal gespannt wie der Service bei Wittig ist.
Niklas
Mit SVN muß ich mich erst noch näher auseinander setzen. Da ich momentan
einiges zu tun hatte und gleichzeitig am nächsten Release dran war hatte
ich da keine Zeit für. Deine Lösung mit dem Nightly Build klingt ganz
Interessant, denn mir ging es in erster Linie darum nicht nur die
Entwickler mit dem neuesten Stand zu versorgen, sondern auch den
Benutzern die Gelegenheit zu geben die aktuellsten Versionen
auszuprobieren.
Weiterhin möchte ich auch vermeiden meinen Verwaltungsoverhead zu groß
werden zu lassen um möglichst viel Zeit für die Entwicklung zu nutzen.
Gruß Hayo
Hallo Zusammen,
ich arbeite gerade an einer "Hardwarelösung" für die Screenshots. Die
Platine enhällt:
ATMega32/644, VNC1L, MAX232, 64kBit FRAM, SUB-D Anschlüsse für Oszi und
PC, USB Anschlüsse für Stick und Oszi und eine Pinleiste um den Vinculum
das erste mal zu programmieren. Größe ist 80x80mm einseitig mit einigen
Brücken.
Ich werde noch Layout und Schaltplan etwas überarbeiten und dann hier
reinstellen. Allerding befürchte ich, das der Vinculum etwas schwierig
zu löten ist.
Sollte das Konzept funktionieren kann man aber immer noch auf ein
fertiges Modul ausweichen. Der Flaschenhals ist definitiv nicht auf der
Platine sondern die lahme RS232 vom Oszi.
Mfg,
Kurt
Moinsen allerseits,
wenn man hier ein paar Tage nicht reinschaut hat man ganz schön was zu
lesen. Respekt vor dem Elan mit dem hier gewerkelt wird...
Noch eine Tipp zu Subversion-Clients: ich kann jedem nur aller wärmstens
eclipse ans Herz legen. Nicht nur, dass es die Entwicklung massiv
vereinfacht, es bringt auch einen sehr brauchbaren SVN-Client
(Subversive) mit.
Viel Spaß weiterhin.
Beste Grüße,
odic
Hallo Kurt,
na deine Platine sieht ja echt gut aus. Vielleicht sollten wir, wenn
feststeht das die Schaltung funktioniert, auch dafür eine professionelle
Lösung in Betracht ziehen? Bei den meisten dieser "Produkte" drückt eine
Herstellung von 30...50 Stck. ganz massiv den Preis.
Ich hätte da auf jeden Fall Interesse dran.
Gruß, brunowe
P.S.: mit Eagle3D gemacht?
Hallo Bruno,
ja, mit Eagle 3D.
Auch ja zur Professionellen Lösung. Leiterbahnen mit 8mil und Abstände
mit 11mil sind nicht für jeden einfach zu ätzen. Außerdem soll die
Platine später kleiner und doppelseitig werden damit man die
Versorgungsspannungen ordentlich routen kann.
Sehr interessante Erweiterung, die dürfte weggehen wie warme Semmeln
(ich bin z.B. ein Doppelabnehmer). Daher denke ich sollte eine größere
Auflage zu Gunsten des Preises kein Problem sein.
Was Anderes: Um die ToDo-Liste zu komplettieren bin ich mal in Gedanken
die wichtigsten Funktionen des DSO durchgegangen, dabei ist mir
aufgefallen, dass ich noch nie die Speicherfunktion für die Signale
benutzt habe. Hat das schon jemand ausprobiert? Ist das ein Feature das
ausnahmsweise mal einfach so funktioniert, oder müssen wir da auch das
Baustellenschild aufstellen?
Gruß Hayo
Hallo Hayo,
die Save/Recall Sachen funktionieren bei der Original-Firmware
einigermaszen, habe ich schon oefters benutzt wenn ich z.B. Signale
vergleichen wollte. Dummerweise konnte ich die dann allerdings
nicht mehr mit der Welec Originalsoftware vom Oszi holen, da wurde
einfach eine neue Signalfolge aufgenommen.
Auch kann man die Funktion nutzen um Kanal- und Zeitachsen-
einstellungen zu sichern, die werden naemlich gleich mit
wiederhergestellt.
Bei der Beta-Firmware scheint da aber genau gar nichts zu
funktionieren. Habe da sehr absurde Effekte. Genau genommen
ist wohl Reboot faellig nach einem Save gefolgt von Recall,
in benutzbaren Zustand habe ich mein Geraet zumindest nicht
wieder versetzt bekommen.
Waere schoen wenn wir das zum Laufen bekaemen, habe mich da aber
noch nicht umgeschaut. Vermutlich werden die ADC-Daten samt
Parameter abgelegt und einfach neu gerendert, oder? Die iirc.
80 Speicherplaetze die da Wittig vorgesehen hat sind aber IMHO
etwas uebertrieben. Vllt. koennen wir das auch aufteilen, d.h.,
Recall Trace und Recal Settings.
BTW: Hast Du meine Nachricht auf SF wg. Devel schon gesehen?
Niklas
Hallo Hayo,
mhm, muesstest egtl. die SF E-Mails an Deine Adresse
geforwardet bekommen. Ging nur darum dass Du mich
(niklas_olmes auf SF) als Devel zum Projekt hinzufuegst.
Geht mit "Project Admin->Membership" eingeloggt unter
https://sourceforge.net/projects/welecw2000a/develop
Niklas
Ich hab mir die Save/Recall-Geschichte mal angesehen, ich glaube es
liegt an den geänderten Parametern die im Flash abgelegt werden, da kann
ich bei Gelegenheit mal beigehen.
Hayo
Hallo,
wenn sich einer dranmacht an der Save/ Recall Funktion rum zu basteln,
dann sollte man direkt den Vorschlag von stendres aus der SF Wishlist
mit einfließen lassen. Halte ich für nen guten Vorschlag.
http://sourceforge.net/apps/trac/welecw2000a/wiki/FWwishlist
Gruß, brunowe
Hallo Bruno,
ja, das waere in der Tat sehr nuetzlich. Koennte man dazu einfach
die (scheinbar) unbenutzten Memory-Planes hernehmen? Sind allerdings
nur drei.
Wo ich gerade die Wishlist sehe finde ich den ersten Vorschlag
von michelwernersen auch wichtig. Da ich (noch) die Original-Firmware
im Flash habe und die aktuelle Beta ins RAM lade bin ich staendig
am Justieren. Das liesze sich sicher recht einfach realisieren,
ich werde da spaeter mal drueber schauen.
Niklas
Stefan E. schrieb:
> Hallo Hayo,>> die Änderungen gehen klar. Muss ich dadurch was an den QM-Funktionen> ändern? Magst du dir mal einen SVN-Client zulegen. Dann würde ein Klick> reichen und alle hätten gleich die aktuellste Version. Geht, wenn einmal> eingestellt, auch mit SourceForge "relativ" fix.
Ich hab's mal ausprobiert:
auf die Nase.
Wer kann einem SVN-Anfänger mal das Brett vom Kopf nehmen?
Außerdem scheint mir, daß es eine gute Idee wäre, die Dateien weiter
aufzuteilen. So könnte der PC-Kommunikationsteil doch in
"pc-comms.[cpp|h]" ausgelagert werden.
Gruß,
Falk
Hallo Falk,
die doppelten/dreifachen Sourcen siehst nicht nur Du :)
Der letzte committete Stand scheint 0.80 zu sein.
Hayo hat selbst ja noch nichts eingepflegt.
Mit
1
$ svn log $file
kannst Du Dir die Commit Messages der Revisions anschauen, bei
der die angegebene Datei betroffen ist.
Mit
1
$ svn diff -r113 src/hardware_t.cpp
siehst Du die Aenderungen seit Revision 113 (und warum es
nicht kompiliert). (Wenn Du die Datei hinten weglaesst
siehst Du den ganzen Diff.)
Warum da jetzt mehrfach Sourcen rumliegen weisz ich nicht,
die Logmessage dazu besagt "creating new brachn for QM".
Sieht fuer mich nach nem Unfall aus, da ich sonst aber mit
CVS und GIT vertraut bin will ich mich nicht festlegen, kann
auch nen Feature sein ;)
Wir sollten IMHO erstmal hergehen und den aktuellen Versionsstand
(0.82) einmal sauber importieren.
Ansonsten, nochmal Kurzeinweisung fuer Falk:
Mit svn commit wuerdest Du den Kram abschicken, wirst dabei
noch um eine Logmessage als Beschreibung gebeten.
Die restlichen Kommandos erklaert Dir svn help gerne :)
Niklas
Hallo,
jo der src-Order unter src ist ein Unfall ;-) Muss ich mal versuchen,
wieder zu löschen.
Der QM-Ordner sollte eigentlich mein Branch werden, in dem ich die
QM-Funktion ändere und dann später wieder in die anderen sourcen
einpflege.
Ich komme selber noch nicht ganz mit svn zurecht. Also net gleich
schlagen ;-)
Vielleicht gibts ja hier einen, der das mal so aufräumt, wie es sich
gehört.
hat denn schon mal jemand das compilieren unter windows getestet? ich
hab es nicht hin bekommen. es kommt folgende meldung
># 2009.07.08.19:37:21 --- Compiling nios-elf-gcc -I ./inc -I ./src -I ./inc >-I .>/inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 >-D_Debug_> src/TomCat.cpp -o obj/TomCat.cpp.o>process_begin: CreateProcess(NULL, nios-elf-gcc -I ./inc -I ./src -I ./inc >-I ..>/inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 >src/TomCat>.cpp -o obj/TomCat.cpp.o, ...) failed.>make (e=2): Das System kann die angegebene Datei nicht finden.>make: *** [obj/TomCat.cpp.o] Error 2
er findet also die tomcat.cpp.o nicht. kann er auch nicht weil die noch
gar nicht existiert. hat jemand einen tip?
gruß sunny
Stefan E. schrieb:
> Hallo,>> jo der src-Order unter src ist ein Unfall ;-) Muss ich mal versuchen,> wieder zu löschen.
Könnte ich mit ksvn vielleicht schaffen. Die Dateien sind sowieso alle
identisch.
> Der QM-Ordner sollte eigentlich mein Branch werden, in dem ich die> QM-Funktion ändere und dann später wieder in die anderen sourcen> einpflege.>> Ich komme selber noch nicht ganz mit svn zurecht. Also net gleich> schlagen ;-)
Schade, hatte den Knüppel gerade geputzt ;-)
Stattdessen habe ich Version 0.4 von w2000a-screenshot committed.
Vielleicht hat das ja geklappt...
Falk
sunny schrieb:
> hat denn schon mal jemand das compilieren unter windows getestet? ich> hab es nicht hin bekommen. es kommt folgende meldung
...
>>make (e=2): Das System kann die angegebene Datei nicht finden.>>make: *** [obj/TomCat.cpp.o] Error 2> er findet also die tomcat.cpp.o nicht. kann er auch nicht weil die noch> gar nicht existiert. hat jemand einen tip?
Er findet nicht die tomcat.cpp.o nicht (die will er ja gerade erzeugen),
sondern die includes unter inc/. Die findest Du da:
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/welec/improved/inc/
Hat mich auch eine Weile gekostet, das herauszufinden.
Falk
die .inc datein sind aber da. im \inc verzeichniss.
ich habe den kompletten build aus dem svn gezogen und nach c:\build
entpackt. dann das makefile geändert und die umgebungsvariablen gesetzt.
wie genau (name,wert) hast du denn bei dir die umgebungsvariablen
gesetzt?
gruß sunny
sunny schrieb:
> die .inc datein sind aber da. im \inc verzeichniss.> ich habe den kompletten build aus dem svn gezogen und nach c:\build> entpackt. dann das makefile geändert und die umgebungsvariablen gesetzt.> wie genau (name,wert) hast du denn bei dir die umgebungsvariablen> gesetzt?
Ich habe nichts setzen müssen. Ich hatte die gleiche Fehlermeldung wie
Du, aber unter Linux. Da mußte ich nur das .../inc besorgen, make
eingeben und es lief...
Vielleicht meldet sich noch ein Windows-User...
Falk
unter linux funktioniert es bei mir auch. ist nur unpraktisch weil ich
linux nur af dem satreciver laufen hab.
vielleicht hat ja noch jemand einen tip zum compilieren windows.
gruß sunny
Hallo sunny,
ev. fehlen nur die Standardheader wie stdio.h u.ä. Die müsste die
Umgebung liefern und dementsprechend müsste das Makefile geändert
oder Umgebungsvariablen gesetzt werden. Das wäre jetzt aber mal
wirklich ein Anlass für einen neuen Thread. ;-)
Gruß, Guido
>ev. fehlen nur die Standardheader wie stdio.h u.ä. Die müsste die>Umgebung liefern
ja, tut sie auch die sind in einem unterverzeichniss
>dementsprechend müsste das Makefile geändert>oder Umgebungsvariablen gesetzt werden.
da müsste man halt nur wissen wie und wo.
>Das wäre jetzt aber mal wirklich ein Anlass für einen neuen Thread. ;-)
ach, so wichtig ist es nun auch wieder nicht. hätte ja sein können das
es schon einer hinbekommen hat.
gruß sunny
Hallo sunny,
suche halt die Standardheader und ergänze im Makefile unter
"INCLUDE_PATHS = \" noch
-I /wo_sind_die Standardheader\
Das musste ich unter Ubuntu auch machen, da war es /usr/include.
Gruß, Guido
Hallo,
so, habe gerade zu spaeter Stunde die 0.82 von Hayo sauber
in fpga/firmware importiert und Falks letztes Diff eingespielt.
Sollte so wie es da liegt und ausgecheckt werden kann kompilieren.
Das obj/ Verzeichnis wird automatisch angelegt.
fpga/welec/official habe ich entsorgt.
Etwaige Aenderungen in fpga/welec/src und/oder fpga/welec/src/src
usw. ;) muessten noch manuell uebertragen werden. Z.B. ueber
1
<0>[23:46]niklas@empire:/tmp/W/welecw2000a/fpga/welec$ diff -u ../firmware/src/ improved/src/ | less
schauen was noch relevant ist und uebertragen.
@Falk:
Das diff-Format ist bissl komisch gewesen, wie hast Du das erzeugt?
Da fehlten die Header damit patch(1) den Kram alleine ohne manuelle
Angabe jeder Datei findet.
diff -uNr (u fuer unified, N fuer include new files, ggfls. weglassen,
r fuer rekursiv, auch ggfls. weglassen) ist ganz okay.
Andere Sache: Wo wir jetzt schon mal das Format fuer die Ausgabe
geaendert haben und auch noch Messwerte rausschreiben koennen waere
IMHO nen kleiner Header nuetzlich, der besagt was kommt und in welcher
Version das ist. Also statt 'S' 0xff am Anfang koennten wir machen
'S' p v 0xff, Rest beibehalten.
Wobei p Protokoll/Anwendung ist, z.B. 0x01 fuer Screenshot, 0x02
fuer Messdaten. V waere die Version. Das Ausleseprogramm koennte
dann entsprechend handeln.
Niklas
>so, habe gerade zu spaeter Stunde die 0.82 von Hayo sauber>in fpga/firmware importiert und Falks letztes Diff eingespielt.>Sollte so wie es da liegt und ausgecheckt werden kann kompilieren.
Sollte auch davor möglich gewesen sein, die Sourcen zu kompilieren. War
eigentlich auf dem aktuellen Stand. Bis auf der zweite src-Ordner, der
ein Versehen war.
Jetzt liegt es irgendwie bescheuert, da nich klar ist, für welches
FPGA-Design die Firmware gedacht ist.
Gruß,
Stefan
Hallo (Martin)
>Was du bemängelst (und misst) ist das typische Antialiasing das bei>allen DSO's auftritt. Es ist dem Anwender überlassen die richtige>Zeitbasis einzustellen (wenn das Signal nicht bekannt ist einfach mit>einer möglichst hohen sample-rate beginnen und runtergehen bis das>Signal richtig dargestellt wird).
Habe mal einen Freund gebeten, ein 1kHz Signal mit seinem
Agilent Infiniium 54831B, 4Kanal, 600Mhz, 4Gsa
aufzunehmen...
Schaut schon viel besser aus!
Bilder : links oben mit 200us/div bis rechts unten mit 500ms/div
Vermutlich schaut das durch den grösseren Speicher besser aus?!
Versuch gerade das mit der Abtastrate und dem Speicher zu verstehen...
Stimmen da meine Rechnungen?
Bei 1ms/div = 250kSa/s -> = 12ms pro Bild würde ich auf 3000 Samples
kommen?
Bei 200us/div = 1MSA/s -> = 2,4mS pro Bild --> 2400 Samples?
Hat das Welec DSO nicht 16KB/ Kanal?
(oder denke ich da irgendwie falsch?)
l.G. Roberto
Hallo Roberto,
Ist etwas unfair einen Rolls Royce mit einem Fiat zu vergleichen!
Aber zu deiner frage:
Die Darstellung hangt von der Samplerate ab, beim Welec (das uebrigens
nur 4KB Samplespeicher hat) ist die bei 500ms/div nur
500Samples/Sekunde, bei dieser Samplerate kann ein 1kHz Signal
natuerlich nicht mehr richtig dargestellt werden (niquist sagt das die
sample rate mindestens doppelt so hoch sein muss wie die hoechste
Eingangsfrequenz, und ein Rechtecksignal enthaelt nicht nur die 1kHz
sondern auch oberwellen). Das Agilent hat 2MB Samplespeicher und kann
daher bei 500ms/div mit 400kSamples/Sekunde samplen!
Martin
Niklas O. schrieb:
> Hallo,
...
> @Falk:> Das diff-Format ist bissl komisch gewesen, wie hast Du das erzeugt?> Da fehlten die Header damit patch(1) den Kram alleine ohne manuelle> Angabe jeder Datei findet.
Ich hatte einfach "diff" benutzt und manuell nacheditiert. Mit svn
brauchen wir das ja nicht mehr.
Ich habe übrigens den PC-Teil nach
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/
hochgeladen und ihn Version 0.4 genannt.
Falk
@Roberto
Die Sampletiefe ist immer 16k. Aber die real verfügbare Sampletiefe
hängt vom Darstellungsfaktor ab. Den Zusammenhang hatte ich weiter oben
schon mal im Zusammenhang mit Aliasing erklärt. Die genauen
Zusammenhänge entnimmst Du der Timebasetabelle in den Programming Maps,
die Du hier findest:
http://groups.google.com/group/welec-dso/files
Hayo
Hayo W. schrieb:
> Sag mal Falk,>> wie machst Du eigentlich diese schicken Bilder? Hast Du da ein> Datenauswertungsprogramm das Diagramme erstellt?
Ja: http://kst.kde.org/
Damit mache ich die meisten Auswertungen von geloggten Daten.
Falk
Falk Willberg schrieb:
> Für die Dump-Funktion ist es auch nur wichtig, ob es sinnvoll ist, immer> die 16KB auszulesen.
Kommt drauf an was man damit machen will. Für die Rekonstruktion das
Bildschirmbildes reicht weniger. Um selbiges zu rekonstruieren muß man
verschiedene Parameter kennen:
- mit welchem Offset beginnt das aktuelle Memory Window
- welcher Faktor wird verwendet (Timebasetabelle)
Bsp.: der Offset liegt bei 400, mit dem Faktor 5.
Dann müßte die Übertragung beginnend beim 400sten Wert jeden 5. Wert
übertragen und zwar so viele wie das Grid breit ist (600 char Werte)
D.h. ausgewertet wird der Bereich von 400 - 3400
Ein Sonderfall sind die Ultra Slow Time-Bases, und die interpolierten TB
da die Daten hier in separaten Speicherbereichen abgelegt sind und auch
ohne Offset mit Faktor 1 ausgewertet werden.
Gruß Hayo
Hallo,
@Stefan:
tut mir Leid, das mit Deiner Namensgebung erschlieszt sich mir
erst jetzt mit Deiner Erklaerung. Wobei das irgendwie auch
bloed ist, dass da sowohl C Code fuer den Nios Softcore und
VHDL vermischt liegt. Koennte man (wenn man nicht wuesste
dass Welec das Design nicht hergeben will/kann wegen fremder
IP) auch so intepretieren, dass fpga/welec/improved das
verbesserte Design enthaelt. Der Pfad sagt ja nicht aus,
ob es sich da um Softcore Code oder VHDL-Design handelt.
"Firmware" erschien mir da logischer, ohne natuerlich wie
Du schon richtig klarstellst zu beachten, dass es ja
parallel eine zweite Entwicklungslinie gibt.
Ich stelle mal die Frage in den Raum was man da tun sollte.
Da die importierte 0.82 Deine (@Stefan) Aenderungen enthaelt
kann fpga/firmware/ jetzt als aktuell angesehen werden. doc/
und tools/ von fpga/welec/improved/ kann noch uebernommen
werden oder, vllt. besser, die PDFs koennten (wenn nicht schon
getan) im Wiki verlinkt werden.
@Falk:
[PC-Teil]
Hab' ich gestern noch gesehen und schon etwas rumgefummelt.
Ich hoffe es ist okay das ich Deinen Code insbes. bzgl.
Conditionals ungefragt neu eingerueckt habe, da sich
die Ebenen fuer mich einfach nicht mehr entschlossen.
Was ich noch einbauen wollte war die -l Loop Funktion,
angeregt durch das Standard-Verhalten der Windows-Versionen
von Kurt, wo automatisch eine neue Datei mit aufsteigender
Nummerierung erzeugt wurde. Zudem noch eine kurze
deutschsprachige Anleitung. Dann kann Hayo den Sourcecode
und die Windows-.EXE ja vllt. kuenftig in seinen Releases
direkt mitfuehren.
kst ist btw. sieht ja wirklich schick aus, muss ich auch
mal ausprobieren. Ich haette jetzt einfach das diesbzgl.
unhandlichere gnuplot hergenommen.
Niklas
Niklas O. schrieb:
> Hallo,
...
> @Falk:> [PC-Teil]> Hab' ich gestern noch gesehen und schon etwas rumgefummelt.> Ich hoffe es ist okay das ich Deinen Code insbes. bzgl.> Conditionals ungefragt neu eingerueckt habe, da sich> die Ebenen fuer mich einfach nicht mehr entschlossen.
Kein Problem. Schön, daß Du die Fehlerbehandlung eingebaut hast.
Ich sollte vielleicht aufhören, nach dem Motto zu verfahren "wenn es
kompiliert, gib's frei, wenn es nicht läuft, versuche -Wall" ;-)
Falk,
derzeit Sope-los...
@Niklas
Da die ganze Versionsgeschichte hier im Augenblick etwas unübersichtlich
ist eine schnelle Frage:
Die Source die Du in SFN abgelegt hast ist schon auf dem neuesten
gepatchten Stand, korrekt?
D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen, auch
korrekt?
Nicht dass ich im nächsten Release den falschen Zwischenstand drin hab.
Zur Windows .exe - klar, die kann ich mit ins Release-Package tun.
Gruß Hayo
@Sunny
ich hatte auch solches Problem bei Kompilieren unter Windows. Das
Problem war nur falsche cygwin version. Ganze Quartus zu installieren
ist ja mühsam nur für richtige cygwin version zum kriegen.
Als Anhang ist abgespeckte cygwin von Quartus II 41sp2 und registry
patch
Gruß Ben
Hallo Hayo,
> Die Source die Du in SFN abgelegt hast ist schon auf dem neuesten> gepatchten Stand, korrekt?
Ja, genau.
Ganz konkret ist's:
BlueFlash_Build_0_62.zip
+ FW1.2.BF.0.82_beta.zip
+ FW1.2.BF.0.82_beta-dl3daz.diff
(aus Beitrag "Screendumps" )
- *~ (vi (u.a.) Backup Files), obj/,
WelecUpdater (ist woanders im SVN), usw.
(GERMSloader.pl ist jedoch drin, kann Hannes entscheiden
ob er das im SVN verwalten will, woanders hinschieben usw..
Bzgl. der WelecUpdater.exe: Die sollte in den Files/Releases
Bereich, da sie ja aus den Sourcen erzeugt werden kann und
statisch ist. Gleiches fuer die Windows Screenshot.exe.
Oder wir sparen das und wir tun sie allein in die
Firmware-Releases.)
> D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen,> auch korrekt?
Ja, genau.
Niklas
Da die Screenshot.exe unter Umständen (so wie jetzt) nur zu dem
jeweiligen Release passen, ist es eigentlich keine schlechte Idee sie
mit ins Paket zu tun, dann gibts keinen Frust wegen inkompatibler
Versionen.
Hayo
@Falk & Niklas
Wenn ich das so richtig mitverfolge, ist ja auch ein reiner
Datendownload in Arbeit.
Hier hatte ich ja mal die Idee geäußert auf vorhandene PC-Software
zurückzugreifen und das Datenformat auf DSO-Seite entsprechend
anzupassen. Das hätte den Vorteil, dass man das Rad nicht zweimal
erfinden müßte. Ich denke da sowohl an Open Source Programme für
verschiedene andere DSOs als auch evtl. Programme von den
DSO-Herstellern, sofern das Datenformat bekannt ist.
Wie ist denn da Eure Meinung?
Bzw. @all
Wer kennt denn evtl. entspechende Programme?
Hayo
Hallo Hayo,
>D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen, auch>korrekt?>Nicht dass ich im nächsten Release den falschen Zwischenstand drin hab.
...und was ist mit dem XY-Grid - Patch? War nach der 0.82!
Oder hab ich etwa eine Beta verpasst?
Gruß
Jürgen
Mal eine Frage an die Experten:
Wenn zwei Leute gleichzeitig bspw. die Datei display_t.cpp bearbeiten,
kann es doch beim Commit zu Kollisionen kommen. Oder irre ich?
Ich denke, wir sollten die gigantischen Monolithen sinnvoll in möglichst
kleine Files aufteilen. Ich würde das übernehmen, wenn ich damit nicht
hintenherum etwas anderes umwerfe...
@Niklas:
was hat es mit src/display_t_bak.cpp und src/fft/ auf sich?
Beim kompilieren werden die nicht angefasst...
@Hayo:
Ich halte es für eine gute Idee, das Datenformat für die
PC-Kommunikation von einem anderen Scope zu kopieren, wenn es dafür
ordentliche Software gibt, die auch unter Linux läuft.
Ich habe nur keine Idee, welches geeignet sein könnte.
Falk
@Jürgen
der XY-Grid Patch ist in der 0.83, die aber noch nicht released ist, da
die neu aufgesetzte FFT noch unfertig ist. Mir ging es darum die
gepatchte 0.82 mit meiner 0.83 abzugleichen bevor ich die jetzt zum
Wochenende raushaue. Vielleicht sollte ich mit dem Abgleich auch noch
bis zum Schluß warten falls noch Patches dazukommen.
Gruß Hayo
@Falk
Mit dem Aufteilen warte mal bis wir auf einem konsolidierten Stand sind,
d.h. wenn ich die 0.83 released habe. Dann können wir einen kurzen
Entwicklungsstop machen und das Organisatorische klären. Sonst gibt es
ein heilloses durcheinander von Versionen, die nicht zueinander passen.
Bei solch umfangreichen Änderungen müssen wir einen sauberen Schnitt
machen, da ja auch die Versionierung im SFN sonst nicht mehr korrekt
ist.
Hayo
Moin moin,
melde mich von der ersten Klausur des Semesters erfolgreich zurück ;)
Bzgl. SVN: Ich hatte hier:
https://sourceforge.net/apps/trac/welecw2000a/wiki/Repository mal
angefangen, die Struktur des Repositories zu dokumentieren. Ist nicht
ganz aktuell wie ich gerade sehe, aber vll könnt ihr euch auch dran
halten bzw. eure Zweige dort grob benennen. Die Struktur könnte noch
optimiert werden, da es ja mittlerweile euren Branch gibt der auf dem
NIOS basiert und auch noch den Kram von Slog, wobei ich bezweifle, dass
da mal wieder was passiert... Ach ja, und die Originalsourcen...
Was mir aufgefallen ist ist dass der ein oder andere Commit der letzten
Tage gut hätte zusammengefasst werden können, statt pro Datei ein
Changeset zu machen. Man kann also durchaus mehrere Dateien in einem
Rutsch (und mit einer gemeinsamen Lognachricht) einchecken. Aber ich
glaube das habt ihr nun auch bemerkt ;)
Was die Sache mit dem src/src/ Ordner angeht: Wenn ich die Logs richtig
im Kopf habe, sollte das ne "Branch" zum Entwickeln werden. Dazu
vielleicht noch ein paar Worte:
1) Wenns geht, würde ich persönlich das Branch&merge gebastel bei SVN
lieber vermeiden. Hab schon diversen Kram mit SVNs versioniert und bin
auch bei größeren Gruppen nicht in die Verlegenheit gekommen, sowas zu
machen. Aber wenn's jemanden gibt, der das Merging am Ende voll drauf
hat, nur zu ;)
2) SVN unterscheidet nicht zwischen Branching, Tagging und Kopieren.
Alles geschieht mittels svn copy, also sowohl release-tags anlegen als
auch branching ist letztlich nix anderes als ne Kopie. Wobei
Serverseitig natürlich nix dupliziert wird, solange es keine Änderungen
gibt. Das mal im Hinterkopf behalten, wenn gebranched wird. Es empfielt
sich also, eine Struktur anzulegen, wie man das in vielen öffentlichen
SVN sieht, also "branches/ tags/ trunk/"-Ordner, wobei Trunk natürlich
der Hauptentwicklungszweig ist.
Da wir hier mehrere parallele Projekte in einem Repo haben, sollte jedes
Unterprojekt in seinem Unterprojekt-Ordner sowas anlegen.
3) ... hab ich gerade vergessen. Naja Vortrag beendet ;)
LG
Hayo W. schrieb:
> @Falk>> Mit dem Aufteilen warte mal bis wir auf einem konsolidierten Stand sind,> d.h. wenn ich die 0.83 released habe. Dann können wir einen kurzen> Entwicklungsstop machen und das Organisatorische klären. Sonst gibt es> ein heilloses durcheinander von Versionen, die nicht zueinander passen.>> Bei solch umfangreichen Änderungen müssen wir einen sauberen Schnitt> machen, da ja auch die Versionierung im SFN sonst nicht mehr korrekt> ist.
Ok, ist das sinnvollste.
Siehe auch Daniels Beitrag.
Falk
Hallo,
@Falk:
> was hat es mit src/display_t_bak.cpp und src/fft/ auf sich?> Beim kompilieren werden die nicht angefasst...
Die stammen offensichtlich aus dem 0.62. fft/ habe ich glatt
uebersehen und ist dann wohl die alte FFT Implementation aus
der 1.2. Beides kann dann weg.
> Wenn zwei Leute gleichzeitig bspw. die Datei display_t.cpp bearbeiten,> kann es doch beim Commit zu Kollisionen kommen. Oder irre ich?
Kann es, ja, in der Regel geht das aber gut wenn nicht gerade genau
dieselbe Stelle im Code von beiden Bearbeitern modifiziert wird.
Wenn die Software das Problem nicht selbst loesen kann (Im Falle
von "Bearbeiter haben an verschiedenen auseinander liegenden Stellen
was geaendert" kann sie das) wird der commit verweigert und man
muss selbst Hand anlegen. Wie das bei SVN konkret ablaeuft kann ich
Dir jetzt allerdings nicht sagen.
Ich stimme Dir zu dass die Dateien teilweise wirklich gigantische
Ausmasze haben und unuebersichtlich sind. Vom Standpunkt der
Revisionsverwaltung muss das aber nicht unbedingt zu schweren
Kollisionen fuehren wie gerade gesagt. Ich wuerde Deinem Vorhaben,
da aufzuraeumen voll zustimmen. Da gerade Hayo aber schon an
0.83 dran war waere es aber sinnvoll, dass Hayo nen Diff zieht
und wir (oder er) das direkt einspielen und Du erst dann aufteilst,
so dass Hayo da spaeter nicht ein groszes Chaos hat.
@Hayo:
> Hier hatte ich ja mal die Idee geäußert auf vorhandene PC-Software> zurückzugreifen und das Datenformat auf DSO-Seite entsprechend> anzupassen. Das hätte den Vorteil, dass man das Rad nicht zweimal> erfinden müßte. Ich denke da sowohl an Open Source Programme für> verschiedene andere DSOs als auch evtl. Programme von den> DSO-Herstellern, sofern das Datenformat bekannt ist.
Das sehe ich genau wie Falk und Du auch. Ich hatte auch schonmal
nach Ausgabeformaten gefragt, leider kam diesbzgl. kein Vorschlag,
ist vllt. auch unter gegangen in der Fuelle von Posts.
Leider kenne ich keine anderen DSOs bzw. Programme dazu. Jeden
Hinweis und Dokumentation gehe ich da gerne nach.
Leider komme ich im Moment zeitlich noch nicht dazu die von mir
angepeilten Dinge (Auto-Setup/Kalibrierung, -l in Screenshot
Programm, usw.) zu realisieren. Wir haben aber ohnehin genug
Baustellen. Wie sieht es btw. da nochmal mit einer immer aktuell
gehaltenen Liste "wer arbeitet gerade woran" aus? SF Wiki
waere da nun die praedestinierte Stelle.
(btw: Irgendwie ist das ziemlich unpraktisch, wenn nur Admins
die Hauptseite des Wikis aendern duerfen, so kann man nur versteckt
in einer vorhanderen Unterseite eine neue Seite verlinken.
Kann man das der Software irgendwie abgewoehnen?)
Update/Edit: Hab' den Satz in Klammern bzgl. Kollisionen mal
ausgeweitet damit klar wird, dass ich dort den automatisch
loesbaren Fall meinte.
Niklas
@Niklas
Der FFT Ordner stammt von mir. Da hatte ich mir mal einige
Beispielsourcen reinkopiert und dann den Ordner vergessen zu löschen -
kann also weg.
Ich hatte mal in der SFN Roadmap einige Entwicklungen eingetragen.
Aktueller wärs natürlich wenn jeder seine momentanen Sachen selber
einpflegt.
Hayo
Niklas O. schrieb:
> (btw: Irgendwie ist das ziemlich unpraktisch, wenn nur Admins> die Hauptseite des Wikis aendern duerfen, so kann man nur versteckt> in einer vorhanderen Unterseite eine neue Seite verlinken.> Kann man das der Software irgendwie abgewoehnen?)
Kann man, möchte ich aber nicht. Öfter mal bei letzten Projekt scheinbar
automatisierten Frontpage-Vandalismus gehabt, deswegen die alte
Gewohnheit, die Seite auf Read-Only zu sitzen. Wenn du mir dein Handle
sagst, kannste gern die entsprechenden Bearbeitungsrechte bekommen.
Wär vll ne gute Gelegenheit, erstmal die Developer-Tabelle im Wiki zu
aktualisieren, damit der Überblick erhalten bleibt ;)
Hallo,
@Hayo:
Roadmap habe ich gefunden :)
@Daniel:
Merke gerade auch, dass ich manche andere Seiten
auch nicht editieren kann (Developers, ...).
Mein Handle entspricht meinem vollen Namen.
Die Rechte beim Trac Wiki hab' ich noch nicht ganz
verstanden. Kann man es so machen, dass alle
eingetragenen und aktiven Developer/Members
(die ja ohnehin manuell von einem Admin hinzugefuegt
werden muesen und damit "geprueft" sind) entsprechende
Rechte bekommen? Im Repository konnte ich direkt
ohne weiteres "rumfuschen", btw..
Abgesehen davon, geht das nur mir so oder ist
das Webinterface bei SF irgendwie ziemlich lahm?
(hab' diverse Firefox Plugins (Ad-Blocker, NoScript, ...)
die das bei mir ausbremsen koennten, daher frage ich mal)
Niklas
Hayo W. schrieb:
> SFN ist so lahm! Daher auch mein eher zögerlicher Zuspruch. Teilweise> mußte ich pro Seitenaufbau 10s - 20s warten.
Ist hier auch so...
Einerseits gab es mehrere Angebote, einen eigenen Server aufzusetzen,
andererseits gefällt mir, daß es nicht so viele verschiedene Orte gibt,
an denen das Thema bearbeitet wird.
Noch was: Wie wäre es mit Unterverzeichnissen .../FW1.2.BF.0.82/
../FW1.2.BF.0.84/ etc?
Falk
@Niklas: Rechte gesetzt.
@Antwortzeit SF: Das schwankt bei mir stark, ist aber im Mittel gerade
noch erträglich. Aber der Server bei SF ist unabhängig. Im letzten
Projekt war plötzlich der Mensch mit dem Server nicht mehr erreichbar,
nachdem kurz vorher alle Daten weg waren und plötzlich kein Backup
existierte. Ob er sich geschämt hat?
@Falk: Üblich für SVN wäre, wenn ihr in eurem "Hauptverzeichnis" unter
trunk/ die jeweils aktuellen Sourcen hättet. Wenn dann ein Release
herausgebracht wird, ist der erste Schritt, trunk/* nach
tags/FW1.2.BF.0.xy/* zu kopieren. Im tags/ Ordner wird nie editiert, das
dient ausschließlich der Konservierung von definierten Ständen. Falls
ihr euere Ordnung dahingehend ändern wollt: mit svn move kann man das
erledigen, ohne dass History verloren geht.
Daniel H. schrieb:
...
> @Falk: Üblich für SVN wäre, wenn ihr in eurem "Hauptverzeichnis" unter> trunk/ die jeweils aktuellen Sourcen hättet. Wenn dann ein Release> herausgebracht wird, ist der erste Schritt, trunk/* nach> tags/FW1.2.BF.0.xy/* zu kopieren. Im tags/ Ordner wird nie editiert, das> dient ausschließlich der Konservierung von definierten Ständen. Falls> ihr euere Ordnung dahingehend ändern wollt: mit svn move kann man das> erledigen, ohne dass History verloren geht.
Ich sehe schon, ich werde mich mal näher mit SVN beschäftigen müssen.
Da ich derzeit kein Scope habe und anderes zu tun ist, halte ich mich
aus der Software ein paar Tage lang heraus.
Falk
@xCometz
danke für deine hilfe. leider hat es mich nicht weiter gebracht.
ich hatte zuvor selber schon etwas rumprobiert und bekahm daraufhin
folgenden fehler
# 2009.07.09.19:41:22 --- Compiling nios-elf-gcc -I ./inc -I ./src -I
./inc -I .
./inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32
-D_Debug_
src/TomCat.cpp -o obj/TomCat.cpp.o
Assembler messages:
for reading.open
: No such file or directory
make: *** [obj/TomCat.cpp.o] Error 1
das einspielen deiner cygwin version hat da auch nichts daran geändert.
trotzdem danke.
gruß sunny
sunny schrieb:
> @xCometz> danke für deine hilfe. leider hat es mich nicht weiter gebracht.> ich hatte zuvor selber schon etwas rumprobiert und bekahm daraufhin> folgenden fehler> # 2009.07.09.19:41:22 --- Compiling nios-elf-gcc -I ./inc -I ./src -I> ./inc -I .> ./inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32> -D_Debug_> src/TomCat.cpp -o obj/TomCat.cpp.o> Assembler messages:> for reading.open> : No such file or directory
Mhhh, irgendwie hätte ich da mehr als ":" erwartet....
Kannst Du mal
hi falk
der gcc sagt folgendes
Reading specs from
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-l
ib/nios-elf/2.9-nios-010801-20030718/specs
gcc version 2.9-nios-010801-20030718
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf
/2.9-ni
os-010801-20030718/cpp.exe -lang-c++ -v -I ./inc -I ./src -I ./inc -I
../inc -I
../../inc -I ../../../inc -iprefix
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/
bin/../lib/gcc-lib/nios-elf/2.9-nios-010801-20030718/ -D__GNUC__=2
-D__GNUG__=2
-D__GNUC_MINOR__=9 -D__cplusplus -D__nios__ -D__nios__ -Amachine(nios)
-D__EXCEP
TIONS -D__OPTIMIZE__ -g2 -W -D__nios32__ -D_Debug_ src/TomCat.cpp
/cygdrive/c/DO
KUME~1/op/LOKALE~1/Temp/ccMyr3vG.ii
GNU CPP version 2.9-nios-010801-20030718 (cpplib)
(nios)
ignoring nonexistent directory `../inc'
ignoring nonexistent directory `../../inc'
ignoring nonexistent directory `../../../inc'
ignoring nonexistent directory
`/cygdrive/c/altera/kits/nios/bin/nios-gnupro/inc
lude/g++-3'
ignoring nonexistent directory
`/cygdrive/c/altera/kits/nios/bin/nios-gnupro/nio
s-elf/sys-include'
ignoring nonexistent directory
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/include/g++-3'
ignoring nonexistent directory
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/lib/gcc-lib/nios-elf/2.9-nios-010801-20030718/include'
ignoring nonexistent directory
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/nios-elf/sys-include'
ignoring nonexistent directory
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/nios-elf/include'
#include "..." search starts here:
#include <...> search starts here:
inc
src
inc
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/lib/gcc-lib/nios-elf/2.9-ni
os-0108
01-20030718/include
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/nios-elf/include
End of search list.
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf
/2.9-ni
os-010801-20030718/cc1plus.exe
/cygdrive/c/DOKUME~1/op/LOKALE~1/Temp/ccMyr3vG.ii
-quiet -dumpbase TomCat.cc -mno-zero-extend -m32 -g2 -O2 -W -version -o
/cygdri
ve/c/DOKUME~1/op/LOKALE~1/Temp/ccaKz1Xj.s
GNU C++ version 2.9-nios-010801-20030718 (nios-elf) compiled by GNU C
version 2.
9-cygwin-990830.
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf
/2.9-ni
os-010801-20030718/../../../../nios-elf/bin/as.exe
Assembler messages:
for reading.open
: No such file or directory
ich glaub aber das führt jetzt hier zu weit. ich dachte es ist nur
irgend ein kleines problem. wenn es unter windows nicht geht ist es auch
noch so. ich kann ja immer noch meinen satreciever misbrauchen. auf
meinem laptop will ich mir kein linux installieren. es reicht mir schon
wenn ich mich bei meinem reciever mit diesem linuxmist rumärgern muß.
auf jeden fall danke für eure hilfe.
gruß sunny
@Sunny
Wie viele cygwin hast du im deinem PC? Bist du sicher dass du auf die
richtige cygwin gelaufen hast?
Es sieht wie falsche cygwin version aus wahrscheinlich einen falsche
path search.
Schau mal den Anhang
Gruß, Ben
Ich habe den Eindruck, das SVN ist schwieriger zu verstehen als die
Welec Firmware?
@Robert,
danke für das Angebot. Aber die Platine ist schon geätzt und bestückt.
Es wird aber bestimmt einen zweiten Prototypen geben...
Der Vinculum läuft auch schon einigermaßen. Jetzt muss ich mich etwas
näher mit dem Befehlssatzt beschäftigen. Sobald die Kommunikation läuft,
werden aus dem Schaltplan die letzten Fehler beseitigt und ich laden ihn
hier hoch.
Ein erstes kleines Beispieprojekt wird es dann auch geben.
PS:
Später ist auch eine RTC geplant damit die Dateien ein vernünftiges
Datum und eine Uhrzeit haben.
@xCometz
ich habe jetzt 2 cygwin auf meinem pc. einmal das was bei quartus mit
dabei war und dann das von dir.
ich hab es jetzt aber hin bekommen. es funktioniert nur wenn ich zuerst
cygwin starte, dann in der cygwin konsole in mein build verzeichniss
wechsle und make starte.
danke noch mal
gruß sunny
Kurze Info für die Screenshot-Spezis.
Im Rahmen einer Fehlersuche habe ich mal schnell eine Colordemo
gebastelt. hier zu sehen sind alle angezeigten Planes (13 Stück,
UI-Plane 2 ist schwarz). Die Memory-Planes werden in der Tat nicht
angezeigt, ebenso wie die Buffer-Planes.
Leider sieht man den Fehler den ich gesucht habe hier nicht. Dafür muß
man kurz aus dem nächsten Beitrag...
...die TomCat.ram laden. Dann Sieht man den Fehler deutlich. Und zwar
hat die UI-Plane 1 eine Macke (hatte Guido ja auch schon vermutet). Die
gesamte Plane ist um 32 Pixel nach rechts verschoben, was dazu führt,
dass die ersten 32 Pixel nicht gezeichnet werden, aber dafür die letzten
32 Pixel auf der rechten Seite durchgeschoben werden und um eine Zeile
nach unten verschoben auf der linken Seite wieder rauskommen.
Daher auch die komischen Linien bei dem ganz linken Funktions-Button.
Hayo
Nachtrag:
Es ist durchaus möglich, das dieser Fehler im VHDL-Design des FPGA
liegt. Ich vermute mal, das die alternativen VHDL-Designs dieses Problem
nicht haben??
Hayo
Hayo W. schrieb:
> Es ist durchaus möglich, das dieser Fehler im VHDL-Design des FPGA> liegt. Ich vermute mal, das die alternativen VHDL-Designs dieses Problem> nicht haben??
Ich sehe keinen Grund, warum diese Plane-Geschichte in HW realisiert
sein sollte... Das würde ja bedeuten, dass es sozusagen für jede Plane
einen Framebuffern gäbe, also in getrennten Speicherbereichen? Ich hätte
jetzt vermutet dass die in Software zusammengeführt werden, habe aber
noch nicht in den Source geschaut.
Wo steckt denn überhaupt der Framebuffer? Im SRAM oder im FPGA-Blockram?
Kann man das evtl. an der Adressaufteilung sehen?
In der Firmware konnte ich den Fehler bislang noch nicht lokalisieren,
in dem Bereich ist das Coding auch ziemlich unübersichtlich.
Kann gut sein, dass es auch eine reine Softwaresache ist. ich bin noch
nicht dazu gekommen zu prüfen ob das Problem auch bei der originalen
FW1.4 auftritt.
Wenn nicht, wäre die Frage geklärt.
Hayo
Hallo,
nö, ich glaube nicht, dass das von der Firmware kommt. Hab da ja schon
mal länger rumprobiert inkl. Neuschreiben von DrawRoundButton und
PixelP.
@ Hayo: Wenn es eine Verschiebung wäre, ließe sie sich leicht
korrigieren. Die 8, 16 und 32 Bit, waren es, wenn ich mich recht
entsinne, aber nicht. Mein Verdacht war eher, dass im VHDL-Code
zwei Adressbits für den Framebuffer vertauscht sind. Das war das
letzte womit ich rumprobiert habe, denn auch das müsste man
korrigieren können.
Gru0ß, Guido
So, für alle die um diese Urzeit auch noch vor dem Rechner sitzen ein
kurzer Zwischenstand in Sachen FFT-Redesign.
Anzubieten hätte ich diese Version...
...oder diese. Welche erregt denn bei Euch mehr Wohlwollen?
Die Cursorfunktion geht natürlich bei beiden.
Hat jemand Verbesserungsvorschläge oder eine Idee welche Daten z.B. im
Bereich Magnitude noch von Interesse wären?
Gruß
Hayo
Hallo Hayo,
mir gefällt die zweite Version deutlich besser, nicht nur weil
sie auch mit übermüdeten Augen noch ablesbar ist ;-), auch das
Grid wirkt harmonischer.
Magnitude in dBm ist zu ehrgeizig, da der Abschluss ja nicht
gewährleistet ist. Besser db mit Bezugspunkt. Wenn aber Mag in
dB oder dBm angegeben ist, sollte Delta-Y nicht in mV sein.
Ich hoffe doch sehr, demnächst auch mal wieder einen Beitrag
leisten zu können, aber es geht wirklich super voran.
Gruß, Guido
Hayo W. schrieb:
> ...oder diese. Welche erregt denn bei Euch mehr Wohlwollen?
^^^^^^
Diese (#2) erregt ähm, also, genau: mein Wohlwollen ;-)
> Die Cursorfunktion geht natürlich bei beiden.
Applaus!
Falk
Also ich finde die untere vorallem wegen der Lesbarkeit besser. Koennte
man denn auch beide kombinieren ?? Also obere Version mit den Farben der
unteren.
Ich finde das Subtile der schwarzen Version eigentlich auch nicht uebel
aber das gelb halte ich fuer praktischer. Form follows function... ;)
Die Skalierung ist noch nicht ganz fertig. Das untere Bild zeigt aber
schon die korrekten Cursorwerte in Volt. Die Anzeige im Abschnitt
Magnitude ist nur eine statische Zeile für Testzwecke.
So jetzt jetzt haben wir schon zwei Meinungen und natürlich genau
gegensätzlich.
Meine Meinung dazu ist noch etwas schwankend. Die Anzeige im ersten Bild
ist etwas technischer gehalten und hat den Vorteil, dass sie in der
Helligkeit mit dem Grid zusammen verstellt werden kann. Die zweite
Version ist dafür etwas angenehmer abzulesen, weil die schwarze Schrift
auf dem hellen Untergrund mehr Kontrast bietet.
Nicht einfach zu entscheiden.
Gruß
Hayo
Hallo Hayo,
beide Versionen sehen echt gut aus! Top Arbeit.
Die Erste ist etwas unaufdringlicher, die Schrift etwas schwer zu lesen-
das mag im Original natürlich besser sein. Die zweite Vers. ist dafür
einheitlicher. Würde eher zur Version 2 tendieren.
Was noch an Info dazu sollte bzw. kann?
Evtl. mal bei den renommierten Herstellern nachsehen, so spontan fällt
mir nichts ein.
Gruß, brunowe
Ja mir fiel so spontan auch nichts mehr ein. Sonst lasse ich das erst
mal frei, da kommen bestimmt noch Vorschläge.
Angeregt durch Deine Kommentare und die LeCroy Broschüre habe ich auch
die FFT-Modi etwas aufgebohrt. Wir wollen ja schließlich nicht hinter
LeCroy zurückstehen... ;-)
Hayo
Sehr schoen, ich warte schon gespannt auf den naechsten Release und
werde dann gruendlich Testen. Jedenfalls wenn ich bin dahin alle meine
Pruefungen geschrieben habe. ;)
Hallo,
ja Hayo du hast recht, wir sollten uns an der Spitze orientieren.
Wenn das nicht klappt, verfahren wir getreu dem Wahlspruch:
WO WIR SIND IST VORN...
UND WENN WIR EINMAL HINTEN SIND, DANN IST HINTEN VORN!
Gruß, brunowe
Es kommt wie es kommen muß:
Ich habe beide Varianten dringelassen. Default ist die Variante 2. Über
Shift + X kann die Variante 1 ein und ausgeschaltet werden. So kann sich
jeder selbst eine Meinung bilden und das dann entsprechend einstellen.
Hayo
Hier schon mal der vorläufige Schaltplan des Vinculum Boards.
Über eine 3MBaud UART Verbindung zum Vinculum kann man mit ca.
112kByte/s auf den Stick schreiben. Getestet vom PC aus.
Allerdings soll später der parallele FIFO zum Einsatz kommen.
PS: LED3 und LED4 sind natürlich falschrum drin.
Hallo Kurt,
Ich habe mir deinen Schaltplan angeschaut, und habe zwei kleine
Anmerkungen:
1. Die last C's des 12MHz Quatz sollten 68pF sein (meiner Erfahrung nach
ist der VNC1L hier recht empfiendlich).
2. Wenn du den FIFO mode nutzen willst ist es von Vorteil auch den PIN
45 (DATAREQ# in FIFO und SPI mode) von der CPU aus steuern zu koennen.
Martin
Muss es eigentlich sein, dass der Trigger automatisch auf einen anderen
Kanal gelegt wird, wenn der momentan den Trigger führende Kanal
deaktiviert wird ? Ich finde das mehr als unpraktisch denn:
- es kommt vor, dass man auf einen Kanal triggern, diesen aber zwecks
Übersichtlichkeit nicht permanent darstellen möchte. Der kleine
Bildschirm ist schon so voll genug :\
- triggert man auf Kanal 1 mit einer hohen Impulsfolge und womöglich mit
einem hohen Signalpegel, sieht man von den anderen Kanälen nahezu nichts
mehr, da das Gelb doch sehr dominant ist. Schaltet man nun Kanal 1 kurz
aus, um sich einen Eindruck von den anderen Signalen zu verschaffen, ist
sofort der Trigger flöten und man steht erst mal im Regen; bzw. fummelt
wieder am Trigger rum bis es passt.
Da die Triggermarke, bedingt durch die farbliche Darstellung am Rand,
die Triggerquelle auch dann eindeutig anzeigt, wenn der Kanal
deaktiviert ist, empfinde ich die Zwangsumschaltung als sehr lästig.
Evtl. geht es ja dem einen oder anderen auch so...
Stefan
Hallo,
echt toll was ihr da Entwickelt.
Was mir noch fehlt ist das Umschalten des Sampleverhalten.
D.h. es wird immer mit der vollen Samplerate gemessen und im FPGA dann
gleich auf die benötigte Samplerate heruntergerechnet.
Professionelle Oszis können da:
Peak (min und max der ADs wärend eines Erfassungstaktes)
HiRes (Mittelwert der ADs wärend eines Erfassungstaktes)
Sample (Nur 1. Wert der ADs wärend eines Erfassungstaktes) so ist es
jetzt immer
Average (HiRes und Mittelwert über mehrere Triger)
Mfg Michael
Hallo Martin,
die Kondensatorgeschichte scheint sehr abhängig vom Quarz zu sein. Bei
mir läuft es mit 10pF ohne Probleme.
Ich werde trotzdem im Schaltplan den Wert auf 22pF oder 47pF erhöhen.
Wofür brauche ich denn den DATAREQ# Pin? Ich dachte mit dem schaltet man
nur zwischen Data und Command Mode um.
Kann aber auch angeschlossen werden. Der AVR hat noch genug Pins.
Mfg,
Kurt
Kurt,
Der Kondensator haengt sowohl von dem Quarz als auch von dem Treiber /
Eingang des IC's ab. Ich habe mit dem VNC1L boese Erfahrung gemacht, der
Prototyp lief mit einem zu kleine C ohne Probleme, aber in der Serie
hatte ich dann einige Baugruppen wo der Oszillator nicht immer an lief.
Was DATAREQ# betrifft hast du recht wenn du nur den Pendrive verwenden
willst ist er nicht noetig (wird fuer di Umschaltung von Kommandomodus
in einen reinen Datenmodus verwendet, zum Beispiel fuer die Verbindung
zu einem PC).
Martin
Michael schrieb:
> D.h. es wird immer mit der vollen Samplerate gemessen und im FPGA dann> gleich auf die benötigte Samplerate heruntergerechnet.
Nein. es wird nicht immer mit der vollen Samplerate gemessen, sondern
mit der angezeigten. Das weitere Herunterrechnen findet dann in der
Firmware statt.
Hayo
Ich habe die aktuelle Firmware und das Problem, dass sich -je nach
Messbereich- der negative Bereich der gemessenen Spannung verschiebt.
Mache ich da etwas falsch oder kann ich dem Scope nicht mehr trauen ?
Anbei zwei Bilder, es geht mir um Kanal 4 (Rot, Kanal steht auf DC)
Besteht evtl. die Möglichkeit, dass QuickMeassure im nächsten Update
gefixed wird? Die Wahl des QM-Kanals via Menü wird leider erst
übernommen, nachdem QM aus- und wieder eingeschaltet wurde.
Btw: QM läuft ganz prima - vielen Dank !
Hallo,
als frisch gebackener W2024A-Besitzer habe ich heute eure Firmware
0.82beta getestet und gleich eine Frage dazu. Ich habe den Abgleich von
ADC bzw. DAC nach Anleitung gemacht, komme aber was den Abgleich der
Nullinien angeht nicht zum gewünschten Ergebnis. Ich kann zwar den DAC
z.B. für 5V, 2V und 1V kalibrieren, wenn ich dann aber den 500mV Bereich
kalibriere verschiebt es den 5V Bereich wieder, bei 200mV den 2V u.s.w.
Was mache ich falsch?
>Die Wahl des QM-Kanals via Menü wird leider erst>übernommen, nachdem QM aus- und wieder eingeschaltet wurde.
Kann ich so leider nicht nachvollziehen. Bei mir klappt das alles
einwandfrei. Mit Ausnahme der weiter oben genannten funktionen.
Kannst du genauer beschreiben, was du nacheinander drückst und welche
Einstellungen du verwendest?
>Btw: QM läuft ganz prima - vielen Dank !
Danke für das Lob!
Sollte sich tatsächlich noch ein Fehler in der Kanalwahl herausstellen,
werde ich versuchen den noch zu beheben. Ansonsten wird es
voraussichtlich erst wieder Mitte August Neuerungen von meiner Seite
geben.
Bis dahin wollen noch eine Reihe Klausuren bestanden werden und der
Computer braucht dann so Anfang August mal zwei Wochen Ruhe ;-)
Gruß,
Stefan
Andreas schrieb:
> Ist nicht Dein Ernst !?> Und ich dachte, der DAC-Abgleich erledigt alle Einstellungen in einem> Schwung. Aber Danke, das erklärt so manches.
Im Paket der Beta FW ist eine Beschreibung wie man den Abgleich in der
richtigen Reihenfolge macht.
Die DAC-Kalibrierung läuft getrennt für die 1er 2er und 5er Bereiche.
Hintergrund ist:
1. Ich wollte anfangs eine Möglichkeit haben das getrennt voneinander
durchzuführen um nicht schon gut kalibrierte Bereiche wieder zu
verschlechtern.
2. Die DAC-Kalibrierung ist als Ergänzung zu der ungenügenden original
Kalibrierung zu sehen.
2. Jetzt funktioniert das eigentlich so gut, dass man auch alle in einem
Durchgang kalibrieren könnte, hatte aber noch keine Zeit das zu
implementieren. Wurde auch schon von anderer Seite angefragt. Werde ich
mal mit den Prioritäten der anderen Baustellen abgleichen.
Für alle neu Dazugestoßenen - die original FW war leider so schlecht
geschrieben, dass es bei den anfänglich geringen Entwicklerkapazitäten
nur langsam voran ging. Ich bitte daher noch nicht so perfekt
funktionierende Bereiche zu entschuldigen. Dafür geht es jetzt bei der
starken Beteiligung hier erheblich zügiger voran.
Hayo
Hallo Hayo,
kannst du dir erklären, warum bei mir die bereits kalibrierten Kanäle
wieder verschoben werden, wenn ich andere kalibriere? Bin genau nach
Anleitung vorgegangen, bekomme aber Nullinien die bis zu mehreren DIVs
abweichen...
Du brauchst dich doch nicht zu entschuldigen :) Ich habe mir ueberhaupt
erst ein solches Scope gekauft als ich gesehen habe was ihr hier
veranstaltet. So einen Aufwand kann bei gott keiner erwarten und ich
moechte mich nochmal in aller Form bei euch fuer das bis jetzt
geleistete bedanken.
Ich werde nach den Pruefungen auch sehen wie ich zu dem Projekt
Beitragen kann. Leider hab ich noch 0 erfahrung mit Oszi-Programmierung,
aber vielleicht kann man ja etwas Learning by Doing betreiben :) Ich
schaue jedenfalls jeden Tag hier rein und fast immer wurde irgendwas
verbessert. Wirklich super !!!
Ohh! Nein das höre ich zum ersten Mal. Bei meinen Geräten klappt das
einwandfrei und auch die Anderen hier hatten das Problem nicht.
Du sagst ja, Du hast das nach Anleitung gemacht und vorher alle Eingänge
abgezogen oder kurzgeschlossen? Wenn nicht bekommt man nämlich genau
diesen Fehler. Am besten macht man erstmal den ADC-Abgleich, da der nur
einen relativen Vergleich der Pegel durchführt. Dann den originalen
Search Zeros und zum Schluß als Feinschliff den DAC-Abgleich.
Ach ja, ganz zu Anfang am Besten noch Default Setup, dann ist man auch
gleich in der günstigsten Timebase für den Abgleich.
Hayo
>Sollte sich tatsächlich noch ein Fehler in der Kanalwahl herausstellen,
werde ich versuchen den noch zu beheben.
Also wenn QM aktiv ist, kann man ja im dazu gehörigen QM-Menü den Kanal
wählen, den QM auswertet. Wählt man hier während der Messung einen
anderen Kanal, arbeitet QM trotzdem weiter auf dem bisherigen und
wechselt auf die geänderte Einstellung erst, nachdem man QM deaktiviert
und dann wieder aktiviert.
Mist, ich hasse solche Sonderrollen....
Also,
- FW 0.82beta (compiliertes HEX-File aus dem Release-Archiv) liegt im
Flash
- Gerät ist warmgelaufen
- alle Probes sind abgezogen
Vorgehen:
- "Default Settings" im "Edge" Menü
=> alle Kanäle sind an und im 5V-Bereich
- einmal "Calibrate ADC"
- einmal "Search Zero Lines"
=> Abweichungen von max. 0,2DIV in den 5V-Bereichen
- "Calibrate DAC"
=> alles bestens im 5V Bereich
- alle Kanäle auf 2V
- "Calibrate DAC"
=> alles bestens im 2V Bereich
- alle Kanäle auf 1V
- "Calibrate DAC"
=> alles bestens im 1V Bereich
- Kontrolle
=> alles bestens in den Bereichen 1V, 2V und 5V
- selbes Vorgehen für 500mV, 200mV und 100mV
=> Nullinien der Kanäle sind in den Bereichen 1V, 2V und 5V wieder bis
ca. 1 DIV verschoben
- selbes Vorgehen für 50mV, 20mV und 10mV
=> Nullinien der Kanäle sind in den Bereichen 1V, 2V und 5V wieder bis >
8 DIV verschoben
Insgesamt sind die Verschiebungen auf Kanal 1+3 nur gering, auf Kanal 2
ausgeprägt und Kanal 4 ist nicht benutzbar (Abweichung > 6 DIV).
Habe ich ein Montagsgerät erwischt??
Stefan schrieb:
> Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für> typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?> Einen Logic-Analyzer hab' ich zwar bereits, aber der ist PC-basiert und> oft möchte man einfach nur mal kurz einen Datenstrom verifizieren; da> würden die 2-4 Kanäle -je nach Protokoll- völlig ausreichen...
Ich hab' mir mal Gedanken gemacht:
https://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=14
Falk, derzeit scopelos
>Also wenn QM aktiv ist, kann man ja im dazu gehörigen QM-Menü den Kanal>wählen, den QM auswertet. Wählt man hier während der Messung einen>anderen Kanal, arbeitet QM trotzdem weiter auf dem bisherigen und>wechselt auf die geänderte Einstellung erst, nachdem man QM deaktiviert>und dann wieder aktiviert.
Na ja. Du kannst ja unterschiedliche Kanäle gleichzeitig messen und
willst nicht für alle Messungen gleichzeitig den Kanal ändern. Ich
glaube,das was du meinst ist, dass du einen der drei Mess-Slots
auswählen und diesen dann geziehlt bearbeiten (Messfunktion, Kanal) oder
gezielt löschen willst.
Das wäre auch mein Wunsch an die GUI. Bis jetzt kann man nur alle drei
Slots gleichzeitig löschen. Um einen Kanal zu ändern kommt man nicht
drum rum alle zu löschen.
@ Odic X,
willkommen im Club ;-)
Ich mache den DAC-Abgleich nur für 5-, 2- und 1-V-Bereich, für
die kleineren stimmt er dann automatisch. Durch die höheren
Störpegel in den empfindlicheren Bereichen kann der Abgleich
wohl schon ins Schleudern kommen.
Also: erst Search-Zero (ev. mehrmals), dann ADC-Abgleich und
dann dreimal DAC-Abgleich.
Gruß, Guido
@Odic
Ahh, verstehe, Du wiederholst die Kalibrierung zig mal bis in alle
Unterdivisions. Das ist so nicht gedacht. Es gibt jeweils einen
Korrekturfaktor für alle 5er Bereiche, einen für alle 2er Bereiche und
einen für alle 1er Bereiche (also nur drei Korrekturfaktoren). Du mußt
also nur einmal für 5V, 2V und 1V kalibrieren, dann sollte es stimmen,
auch in den kleineren Spannungsbereichen.
Hayo
Funktioniert leider bei mir nicht. Wenn ich z.B. Kanal 4 im 5V-Bereich
perfekt abgeglichen habe, liegt die Nullinie im 500mV-Bereich 0,5 DIV
höher und im 50mV-Bereich 4 DIV höher.
Das ist so leider nicht zu gebrauchen....
So, ich habe das Ganze nochmal lediglich in den 1-5V Bereichen
durchgespielt. Bei den Kanälen 1 und 3 klappt es. Bei Kanal 2 kann man
mit der sich ergebenden Abweichung von 0,3 DIV notfalls leben. Nur bei
Kanal 4 funktioniert das Ganze leider überhaupt nicht:
5V: abgeglichen
500mV: +0,2 DIV
50mV: +1,8 DIV
2V: abgeglichen
200mV: +0,5 DIV
20mV: +4,6 DIV
1V: abgeglichen
100mV: +0,9 DIV
10mV: >+8 DIV
Wäre es in der Firmware viel Arbeit, die Korrekturwerte für jeden
Bereich einzeln ermitteln zu können?
@Odic
Hmmm, da läuft aber bei Deinem Gerät was mächtig schief. Leider kann ich
mir da so auf Anhieb auch keinen Reim drauf machen.
> Wäre es in der Firmware viel Arbeit, die Korrekturwerte für jeden> Bereich einzeln ermitteln zu können?
Erstens wäre es schon einiger Aufwand und außerdem ist es technisch auch
eigentlich nicht nötig, da die jeweiligen Analogbereiche der Hardware
immer für alle 5er 2er 1er Bereiche ausgelegt sind. Daher auch nur
drei Korrekturfaktoren.
Meine Idee wäre zuerst mal einen Flashdump einzuspielen um sicherzugehen
dass da nichts schief hängt.
Hayo
Also ich hab jetzt auch etwas getestet.
Gestern hat der abgleich auf allen Kanaelen noch wunderbar geklappt...
als ich dann heute das Scope angeworfen habe war alles wieder voellig
durcheinander, d.h. die Nulllinien wieder irgendwo. Als ich kann den
Abgleich auf allen Kanaelen gleichzeitig durchgefuehrt habe (also 1-4 AN
und dann die ganze Prozedur), trat genau das Problem das du beschrieben
hast auf.
Jetzt habe ich mich dann nochmal Hayo's Hinweis, das man alle Kanaele
auch einzeln abgleichen kann, erinnert und das durchgefuehrt. Also nur
Kanal 1 an und dann 1V-5V abgeglichen. Dann das selbe nur mit Kanal 2
an, alle andren aus usw. Nun habe ich in allen Bereichen schoene
Nullinien und das Scope merkt sich die auch beim Neustart.
Woran das genau liegt kann ich mir so aber nicht erklaeren. Gestern
dachte ich das das auf allen Kanaelen sauber funktioniert hat... war
aber auch schon spaet.
Nach weiteren Tests habe ich jetzt bemekrt das das Scope sich die
Offsets wohl nicht merkt. Nachdem das Scope jetzt laenger aus war und
ich es angeschalten habe war erstmal alles durcheinander, nix hat
gepasst. Nach ausfuehren von Default Setup:
5V Bereich: Alles in Ordnung, auch nach Neustart
2V Bereich: Abweichung um ca. 0.3Div nach Neustart
1V Bereich: Abweichung um ca. 0.3Div nach Neustart
Auffallend ist das die Offsets sich alle nach unten verschoben haben.
@Alexis
Durch Temperaturunterschiede (kaltes / warm gelaufenes Gerät) habe ich
auf allen Kanälen auch Schwankungen der Nullinie von -0,2 bis -0,5 DIV.
Das ist zwar lästig, aber erklärbar.
@Hayo
Ich versuche es mal mit dem Dump. Die FW hatte ich bereits nochmal neu
eingespielt da ich vermutet habe, dass dabei etwas schief gegangen ist.
Leider ohne Erfolg.
Ok, nächstes Problem. :-(
Das Zurückspielen des Dumps bricht reproduzierbar an folgender Stelle
ab.
Writing line 044014 of 071372: ............ 422 sec / 262 sec left
Error: Timeout while reading response from DSO!
Response was: 'S3150005247FFF<#33><#13>
Kann sich jemand einen Reim darauf machen??
Odic X. schrieb:
> Writing line 044014 of 071372: ............ 422 sec / 262 sec left> Error: Timeout while reading response from DSO!> Response was: 'S3150005247FFF<#33><#13>
Hatten wir weiter oben schon mal. Das DSO antwortet aus leider nirgendwo
beschriebenen Gründen mit einem "!" statt einem "+". Deswegen bricht der
GERMSloader ab. Der Script (s.Anhang) ist bereits geändert, um das
schlicht zu übergehen, allerdings wohl noch nicht in das Firmwarepaket
integriert.
/Hannes
Johannes Studt schrieb:
> Odic X. schrieb:>> Writing line 044014 of 071372: ............ 422 sec / 262 sec left>> Error: Timeout while reading response from DSO!>> Response was: 'S3150005247FFF<#33><#13>>> Hatten wir weiter oben schon mal. Das DSO antwortet aus leider nirgendwo> beschriebenen Gründen mit einem "!" statt einem "+". Deswegen bricht der> GERMSloader ab.
Wenn ich mich recht erinnere, bedeutet "!", daß ein Fehler (beim
Schreiben) aufgetreten ist. Das kann daher kommen, daß der zu
schreibende Bereich nicht gelöscht wurde...
> Der Script (s.Anhang) ist bereits geändert, um das> schlicht zu übergehen, allerdings wohl noch nicht in das Firmwarepaket> integriert.
Ich würde den Fehler nicht ignorieren...
Falk
Ja, "ignorieren" ist falsch ausgedrückt. Es bricht nicht sofort ab (wie
es dummerweise bisher war), sondern versucht bis zu 10mal die gleiche
Zeile erneut zu schreiben. Erst dann wird mit einem Fehler wirklich
abgebrochen. Man muss dann halt untersuchen, was der Grund für das "!"
ist.
Und stimmt, weiter oben war der Grund für das "!" wohl eine etwas
instabile serielle Verbindung, was hier offenbar anders ist, wenn der
Fehler immer an derselben Stelle auftritt. Da wird also der geänderte
Skript auch nicht helfen.
/Hannes
@Odic
Es ist nicht die Firmware, sondern der Configbereich der hin und wieder
beim Rumexperimentieren mit unterschiedlichen FW-Versionen einen
abkriegt.
Übrigens braucht man eigentlich nicht die Kanäle einzeln abzugleichen,
das kann er auch gleichzeitig.
Hayo
Hi,
gerade wollte ich die neue 0.84 Firmware mit dem neuen Screenshot
ausrüsten,
aber bei SFN ist kein Durchkommen. Weder komme ich an die Sourcen heran,
noch an die Screenshot.exe.
Daher werde ich gleich die 0.83 mit der alten Screenshot-Funktion
rausgeben.
Hayo
New beta release 0.83 out now!
Please pay attention to the release notes! You will find it here:
https://sourceforge.net/projects/welecw2000a/files/
Es sind zahlreiche Bugfixes und Neuerungen eingeflossen. Leider konnte
ich die neue Version der Screenshot-Funktion nicht mit einbauen. Das
wird dann in der nächsten kommen. Die passenden PC-Programme zur alten
Version sind mit im Paket.
Die Statusanzeigevariante (gelbe Buttons oder "black edition") im
FFT-Modus kann über ein Terminal mit shift + V umgeschaltet werden und
bleibt dann auch nach dem Aus- und wieder Einschalten so eingestellt!
Die FFT-Sektion ist noch in Arbeit und an einigen Stellen nicht ganz
fertig. Die Skalierung ist nur für die linearen Bereich korrekt und bei
den logarithmischen FFT stimmt nur der 5V Bereich.
Da es mich bei der Cursorfunktion etwas störte, das die Deltaanzeige die
kleineren Werte verdeckte, habe ich der Cursorfunktion eine zwei
Stufenlogik verpasst (auch im Normalbetrieb).
- Einmal den Cursurknopf drücken -> Anzeige ohne Delta
- nochmal den Cursorknopf drücken -> Anzeige mit Delta
- nochmal drücken -> Cursor aus
Kritik und Anregungen sind wie immer ausdrücklich erwünscht.
Viel Spass
Hayo
Habe auch schnell einen Test mit der Abgleichfunktion gemacht. Habe dazu
alle vier Kanäle eingeschaltet gelassen, Default Setup aufgerufen, dann
ADC, Zero Lines und DAC ausgeführt auf 5V, dann nochmal DAC auf 2V und
auf 1V. Danach war bei mir über alle Spannungsbereiche alles im Lot. Das
einzige, das mir aufgefallen ist, ist, dass die Nullliniensuche erstmal
zig DIV's danebengehauen hat, was nach dem DAC Abgleich dann aber i.O.
war.
Also bei mir gabs kein Problem mit dem gleichzeitigen Abgleich aller
Kanäle.
Den neuen GERMSloader werde ich morgen testen, wenn ich dann die 0.83
flashe. Aber ich befürchte fast, dass ein Retry nach einem ! nichts
bringt. Außerdem denke ich, dass das ! nix mit der wackeligen seriellen
Schnittstelle zutun hat. Wenn ein Zeichen fehlte oder zuviel war,
scheiterte die Übertragung ja auf andere Weise, was dann dank der
Retries ziemlich schnell vom Tisch war.
Gibt's eigentlich Sourcen vom GERMSloader irgendwo? Ich meinte mal
gelesen zu haben, dass jemand den verändert hätte für eine neue
Plattform. Eventuell lassen sich in den Sourcen ja Infos finden, was die
Rückgabe des ! zu bedeuten hat? In diverser Doku von Altera bin ich
jedenfalls nicht fündig geworden.
@Hannes:
Besten Dank für das Skript, damit funktioniert es
@Hayo
Das Einspielen des Dumps hat keine Veränderung gebracht. Das Verhalten
tritt auch mit der Orginal-FW auf. Damit würde ich ein SW-Problem
eigentlich ausschließen.
Ach ja, ich mache den Abgleich für alle Kanäle gleichzeitig. Da habe ich
mich vielleicht unklar ausgedrückt...
Hat irgendwer eine Idee, wie die HW diesen Effekt verursachen könnte?
@Odic
Wenn sich die Nulllinien weder mit der beta FW noch mit der originalen
FW einigermaßen einstellen lassen, ist das meines Erachtens ein
Garantiefall. Schließlich ist die (zugesicherte) Funktion nicht
vorhanden.
Hayo
Daniel H. schrieb:
> Bzgl. SVN: Ich hatte hier:> https://sourceforge.net/apps/trac/welecw2000a/wiki/Repository mal> angefangen, die Struktur des Repositories zu dokumentieren.
Ich dachte eigentlich, dass auf der Seite oben direkt ersichtlich wird,
dass die verschiedenen Entwicklungszweige auf FPGA-Seite nach
verwendetem Softprozessor geordnet sind... Mehrdeutigkeiten wie eure
jetzige Location "/fpga/firmware/" wollte ich eigentlich vermeiden. Mal
davon abgesehen, dass es sowas wie "Firmware" eh' nicht gibt (Entweder
hard oder soft), wäre vermutlich alles andere im Repository im
fpga-Ordner nach eurer Definition auch Firmware ;) Also, warum packt ihr
eure Sourcen nicht lieber nach "/fpga/nios/*"? z.B. im NIOS-Ordner noch
einen Unterordner "Blueflash" oder so anlegen? Dann könnte noch der
offizielle Welec-Kram auch dort reingeschoben werden und alles ist
wieder übersichtlich (ok, vielleicht nicht übersichtlich, aber dennoch
nach einer Regel abgelegt. Deswegen ja die Wiki-Seite.)
@Daniel
Du hast Recht, die von Dir vorgeschlagene Struktur ist logisch gesehen
korrekt. Allerdings würde ich vorschlagen möglichst nicht so tiefe
ordnerstrukturen anzulegen, denn ich finde die Navigation doch recht
mühsam, da man bei Zurücknavigation immer zum Rootverzeichnis
zurückspringt und sich dann wieder neu durchkämpfen muß.
Übrigens habe ich meine Probleme beim Zugriff auf SFN zu einem großen
Teil auf den Browser zurückführen können. Mit Opera und Firefox komme
ich an einige Stellen im Repository nicht heran. Nur mit dem IE klappt
es dann. Den benutze ich aber eigentlich lieber nicht.
Hayo
Ich bräuchte noch etwas Unterstützung.
Für die neue Screenshotversion fehlt mir noch die aktuelle Windows-.exe
Wo kann ich die finden, bzw. kann die jemand hier einfach mal posten?
Dann kann ich nähmlich kurzfristig noch eine aktualisierte Fassung
rausbringen.
Hayo
Hallo Hayo,
wie ich gerade feststelle kompiliert das ganze wegen der
Aenderungen von Falk nicht mehr unter Windows. Zudem
muss noch eine generalisierte Write-Funktion her.
Ich versuche das gerade umzustricken, mehr in ein paar Minuten.
Bin allerdings nicht zu Hause, habe daher keine DSO da und
kann es nicht testen.
Niklas
Hallo nochmal,
okay, sollte laufen. Win32 .EXE im Anhang. Bitte sowohl unter
unixoid als Windows testen. Aenderungen siehe SVN Log.
(und wenn Du die Sourcen dabei packen solltest nicht vergessen
die aktuellen aus dem SVN zu nehmen ;)
Niklas
Niklas O. schrieb:
> Hallo Hayo,>> wie ich gerade feststelle kompiliert das ganze wegen der> Aenderungen von Falk nicht mehr unter Windows. Zudem> muss noch eine generalisierte Write-Funktion her.
Ich sehe schon, ich muß das auch für Windows kompilieren. Was braucht
man dazu?
Falk
Hallo Falk,
> Ich sehe schon, ich muß das auch für Windows kompilieren. Was braucht> man dazu?
ich nehme MinGW ( http://www.mingw.org/ ) dafuer. Damit kann man
auch fuer Win32 crosscompilen.
Niklas
Hallo Hayo,
sorry, eine Sache vergessen. Bei -c (Angabe Com-Port) musste
das Argument bei 0 starten (0 fuer COM1), entgegen der
dokumentierten und vorherigen Praxis. Anbei korrigierte Fassung.
Niklas
Alles klar, danke für die schnelle Reaktion.
Noch zwei Fragen (hatte nur kurz aufs Coding geschaut):
1. Werden bei der V 0.4 noch die nicht benötigten Memoryplanes
übertragen, oder ist das schon optimiert? Ich habe nämlich im Coding
gesehen, dass diese noch mit definiert werden.
2. Ist die Triggerung des Screenshots über das PC-Programm optional oder
wird der ScrShot immer getriggert wenn das Programm aufgerufen wird?
Hayo
Hallo Hayo,
zu (1): Die Memory-Planes werden noch uebertragen. Auch andere
unbenutze Planes (abgeschaltete Channels, abgeschaltete Cursor)
werden noch weiter uebertragen.
Das ist alles noch nicht implementiert.
zu (2): -l ist allerdings noch nicht implementiert. Es wird
jetzt vom Programm aus immer getriggert (Falk moege mich korrigieren
wenn das nicht stimmt). -l noch einzuauen waere aber nicht
schwierig.
Niklas
denkste, es gibt keinen Parameter -l. Irgendwie kriege ich das unter
Linux nicht zum Laufen.
Wie ich sehe (zu 1.) werden die überflüssigen Planes noch übertragen ->
hier kann noch optimiert werden!
Hayo
@Niklas
wir haben uns hier gerade überschnitten. Ich hab noch mal schnell
ausprobiert, man könnte zumindest für die neue Beta schon mal die drei
Memory planes rausnehmen und die -l Option einbauen.
Ich bin gerade dabei für das QP-Menü eine zweistufige Logic einzubauen
Einmal drücken -> QP Menü
Zweimal kurz hintereinander drücken -> direkter Screenshot
Daher ist das Triggern über PC-Programm nicht unbedingt nötig. Praktisch
wäre z.B.
- default ist warten
- optional ist externes Triggern des ScrShot
Hayo
Hallo Hayo,
> denkste, es gibt keinen Parameter -l. Irgendwie kriege ich das unter> Linux nicht zum Laufen.
Unter Linux sollte das nun ungefaehr so ablaufen:
1
$ ./w2000a-screenshot -c /dev/ttyUSB0 -b
Triggert einen Farb-Screenshot auf dem ersten USB<->RS232 Adapter
und schreibt ihn als Bitmap raus. (-c hat Falk fuer non-Windows
implementiert. Unter Windows ist das -c 1 fuer COM1 wie gehabt.)
Dank Falks Optimierung dauert das ganze bei mir jetzt nur noch
iirc 37 Sekunden statt knapp unter einer Minute.
Die nicht-existente Option -l wuerde dann halt warten bis das
Scope etwas sendet (Screenshot oder Messdaten), im Falle von
Screenshot das ganze in eine Datei mit aufsteigendem Zahl als
Suffix schreiben und weiterlaufen. Also so wie das einst bei Kurts
Windows-Port war.
> Wie ich sehe (zu 1.) werden die überflüssigen Planes noch übertragen ->> hier kann noch optimiert werden!
Ja, das wissen wir :) Die Entwicklung hat ja nur gestoppt weil Falks
Scope zur Reperatur ist und ich im Moment nicht so viel Zeit habe.
Wenn Du warten moechtest bis zu Deinem naechsten Release kann ich
versuchen das heute Abend und/oder morgen noch einbauen.
> wir haben uns hier gerade überschnitten. Ich hab noch mal schnell> ausprobiert, man könnte zumindest für die neue Beta schon mal die drei> Memory planes rausnehmen und die -l Option einbauen.
Ja das waere die einfachste Variante.
> Einmal drücken -> QP Menü> Zweimal kurz hintereinander drücken -> direkter Screenshot
Das klingt gut.
> - default ist warten> - optional ist externes Triggern des ScrShot
Ja, das waere auch das alte Verhalten. -l wuerde dann zudem das
Programm am Laufen halten um so ohne Neustart mehrere Dinge
empfangen zu koennen.
Ist jetzt die Frage wie lange Du warten moechtest bis zum naechsten
Release?
Niklas
Meine Bastelecke (FFT) bleibt erstmal unverändert. Ich wollte eigentlich
nur die Screenshotfunktion nachreichen, damit wir einen kurzen Break
machen können um auf einer gemeinsamen Sourcebasis die nächsten Schritte
abstimmen zu können:
- weitere Aufteilung der Sourcefiles -> hatte Falk angestossen
- ordnen der SFN-struktur
- kurze Abstimmung wer macht wo weiter
Morgen habe ich ziemlich wenig Zeit, daher wäre es vielleicht am Besten
den Stand so rauszugeben wie wir Ihn heute fertiggestellt bekommen.
Würdest Du die Änderungen denn heute Abend schaffen? Dann würde ich so
lange warten.
Hayo
Niklas O. schrieb:
...
>> Einmal drücken -> QP Menü>> Zweimal kurz hintereinander drücken -> direkter Screenshot>> Das klingt gut.>>> - default ist warten>> - optional ist externes Triggern des ScrShot>> Ja, das waere auch das alte Verhalten. -l wuerde dann zudem das> Programm am Laufen halten um so ohne Neustart mehrere Dinge> empfangen zu koennen.
Wie wäre es damit: Ohne Angabe, was geladen werden soll (Farbe,BW,CSV)
wartet das Programm, was vom Scope kommt, andernfalls veranlasst es den
download?
Falk
P.S.: Ich hatte man eine Fernsteuerung mit QT angefangen. Damit kann man
Knöppe drücken, sich die Ausgabe ansehen, Parameter einstellen etc. Das
werde ich mal an die neue Firmware anpassen und mit SVN bei SFN
einwerfen.
P.P.S.: Das scope ist Samstag bei Wittig angekommen. Ich bin mal
gespannt, wie lange der Tausch dauert...
Hallo,
@Hayo:
> Würdest Du die Änderungen denn heute Abend schaffen?
Ich versuche es.
@Falk:
> Wie wäre es damit: Ohne Angabe, was geladen werden soll (Farbe,BW,CSV)> wartet das Programm, was vom Scope kommt, andernfalls veranlasst es den> download?
Mhm, verstehe ich gerade nicht ganz. Soll das Programm eine gewisse
Zeit warten ob vom Scope etwas kommt und dann, falls nicht, den Vorgang
selbst anstoszen?
Faende ich dann ueberfluessig, m.E. will man etwas sofort abspeichern
oder man moechte alles bereit haben und dann auf Knopfdruck ein
oder mehrere (-l) Screenshots ziehen, wobei es egal ist ob der Mensch
am DSO sich da ne Minute oder mehrere Stunden Zeit laesst.
Niklas
> Wie wäre es damit: Ohne Angabe, was geladen werden soll (Farbe,BW,CSV)> wartet das Programm, was vom Scope kommt, andernfalls veranlasst es den> download?
Das ist gut. Optional dann noch der Parameter -b für .bmp
Hayo
Mal wieder überschnitten...
Ich habe das so verstanden, dass der -l Parameter der Default ist, d.h.
ohne Angabe läuft das Programm in einer Schleife. Nur wenn die
zusätzlichen Parameter für das Format angegeben werden wird extern der
Screenshot getriggert.
Hab ich das so richtig interpretiert?
Hayo
Hayo W. schrieb:
> Mal wieder überschnitten...>> Ich habe das so verstanden, dass der -l Parameter der Default ist, d.h.> ohne Angabe läuft das Programm in einer Schleife. Nur wenn die> zusätzlichen Parameter für das Format angegeben werden wird extern der> Screenshot getriggert.>> Hab ich das so richtig interpretiert?
So meinte ich das.
Falk
Hallo Hayo,
warum nicht, wie schon mal vorgesehen war, ein separates 3-er QP-Menü
mit 3 Tasten ( Color,BW,CSV ) vom Oszi aus? Wenn die PC-SW unterscheiden
kann was kommt... (Hab noch nicht getestet.) Fernbedienung vom PC ist da
für mich zweitrangig.
Jürgen
@Niklas
Ich habe mir erlaubt die .csv Funktion etwas zu ändern, damit die
Ausgabe nicht mehr nach stdout geht sondern direkt in eine Datei
geschrieben wird. Trennzeichen ist dabei (Excelkonform) das Semikolon.
Vielleicht kannst Du das ja mit einfließen lassen?
Hayo
Jürgen schrieb:
> Hallo Hayo,>> warum nicht, wie schon mal vorgesehen war, ein separates 3-er QP-Menü> mit 3 Tasten ( Color,BW,CSV ) vom Oszi aus? Wenn die PC-SW unterscheiden> kann was kommt... (Hab noch nicht getestet.) Fernbedienung vom PC ist da> für mich zweitrangig.
Hi Jürgen, hab mich wohl nicht so deutlich ausgedrückt weiter oben.
Genauso wie Du sagst wird es sein, bzw. ist es sogar schon in der 0.84.
Nur das zusätzlich die Möglichkeit besteht durch schnelles 2fach drücken
des QP-Buttons einen direkten Print anzustoßen.
Hayo
Da sich die 0.84 nicht mehr ändern wird hier schon mal vorab die
Flashdateien für alle die sich die neue QP-Funktionalität mal ansehen
möchten.
Das komplette Paket mit aktualisierter PC-Software wird es auf SFN geben
wenn Niklas soweit ist.
@Niklas
Da kannst Du dann gleich sehen ob die 0.84 mit der PC-Software
harmoniert.
Hayo
Neues vom Vinculum:
Im Anhang Schaltplan und Layout als PDF und Eagle Dateien sowie etwas
Demo Code.
Die Software erstellt alle 2 Sekunden eine Datei nach dem Schema
WELECXXX.TXT mit fortlaufender Nummer von 0 bis 255. Inhalt der Datei
ist "Hallo Welt!"
Jetzt dürfen die Profis ran: Vorhandene Funktionen optimieren, neue
ergänzen, Lauflängendekomprimierung einbauen, Interrupts benutzen...
Ich werde natürlich auch weiter daran arbeiten, nur bei der ganzen
Dekomprimierung usw. blicke ich nicht ganz durch.
Eigentlich sollte es möglich sein eine Byte vom Oszi zu empfangen, es zu
verarbeiten und auf das Vinculum zu schreiben noch bevor das nächste
Byte vom Oszi ankommt. So bräuchte man kaum RAM im µC.
Dafür muss aber die Oszi Firmware entsprechend umgeschrieben werden?
Die Hardware: Ist nicht wirklich zum Nachbau geeignet und versteht sich
nur als Layout Vorschlag. Die Leiterbahnführung ist teilweise etwas
ungünstig, es fehlen Elkos an den USB Buchsen, das Footprint für den
MAX232 ist zu groß, die Steckverbinder sind auf einer einseitigen
Platine kaum zu löten...
Wenn jemand noch einen Prototypen bauen will, kann er gerne die Platine
neu routen. Ansonsten warten wir wie die Softwareentwicklung lauft und
ich entwerfe Version 2.0 sobald die neuen Anforderungen bekannt sind.
Kurt Bohnen schrieb:
> Neues vom Vinculum:> Im Anhang Schaltplan und Layout als PDF und Eagle Dateien sowie etwas> Demo Code.>> Die Software erstellt alle 2 Sekunden eine Datei nach dem Schema> WELECXXX.TXT mit fortlaufender Nummer von 0 bis 255. Inhalt der Datei> ist "Hallo Welt!"
Kannst Du mich mal erleuchten, wie das Ding angeschlossen wird und was
genau es tut?
Falk
Naja, an die DC Buchse kommen 5V.
Der 9-Pol D-Sub Stecker unten links geht zum Oszi.
Die 9-Pol D-Sub Buchse dient für Debug Zwecke und geht zum PC.
Mit dem 10-Pol Wannenstecker wird der AVR programmiert und mit der 5-Pol
SIL Buchsenleiste das Vinculum.
Die linke USB Buchse ist für den Speicherstick.
Und es tut genau das was ich oben geschrieben habe: Alle 2 Sekunden eine
neue Datei erstellen und auf den USB Stick speichern. Das ist absoluter
schwachsinn, zeigt aber wie man mit dem VNC1L kommuniziert und Dateien
anlegen kann.
Oder habe ich deine Frage falsch verstanden?
PS: Der Rest sollte aus dem C-Code und den Datenblättern zum Vinc.
ersichtlich werden. Oder habe ich noch essentielle Infos unterschlagen?
Sinn des ganzen ist es, Screenshots und Speicherdumps (Messdaten als
CSV) erstellen zu können ohne einen PC anschließen zu müssen.
Außerdem kann man bestimmt auch einen Drucker anschließen.
Kurt Bohnen schrieb:
> Sinn des ganzen ist es, Screenshots und Speicherdumps (Messdaten als> CSV) erstellen zu können ohne einen PC anschließen zu müssen.> Außerdem kann man bestimmt auch einen Drucker anschließen.
Ich glaube, ich hab's jetzt auch begriffen.
Damit wäre in der Firmware ja nur wenig zu tun.
Mit dem Drucker sehe ich Probleme. Selbst ein Postscript-File könnte die
Firmware überfordern. Das überlasse ich gerne dem AVR ;-)
Falk
Hallo,
so, zusammengestrickt, einiges geaendert und committed. Im Einzelnen
bekomme ich das jetzt nach dem langen Tag gar nicht mehr alles zusammen.
Bitte SVN Log (und diff) schauen :)
@Hayo:
> Ich habe mir erlaubt die .csv Funktion etwas zu ändern, damit die> Ausgabe nicht mehr nach stdout geht sondern direkt in eine Datei> geschrieben wird. Trennzeichen ist dabei (Excelkonform) das Semikolon.> Vielleicht kannst Du das ja mit einfließen lassen?
Hab' ich gemacht und gleich noch ne Art generisches Framework
(in Ermanglung eines besseren Begriffs) drumrum, so dass man
die Ausgabe spaeter um diverse Formate erweitern kann. Moeglich
derzeit: -t csv (default) und -t ascii (so wie Falk das im Original
gebaut hatte).
Neu ansonsten unter anderem -i (invertieren), -s (Screenshot, Farbe),
-n num (manuelle Startnummer fuer die notwendig geworde
Dateinummerierung),
-o (One-Shot, -l (Loop) ist Default-Verhalten (den Switch gibt's daherE
nicht) und -o wuerde das alte Verhalten (einen Dump empfangen, beenden)
wiederherstellen.
Eigentlich wollte ich noch gerne die Faerbung fuer die Planes mit einer
INI-Datei anpassbar machen, das hab' ich aber wegen der Umstruktierung
nicht mehr geschafft. Wer da bessere Farben raussuchen moechte muss
dies ueber Aenderungen der Sourcefiles tun (gibt oben eine Tabelle,
leicht auch fuer Laien zu machen). Verbesserungen nehmen wir gerne
entgegen.
@Hayo:
Im Moment schreibt das DSO ja noch die 16 Planes raus. Wenn die
drei Memory-Planes raus sollen kann das sehr leicht im Programm
angepasst werden. Das kann ich gerne noch tun. Vllt. kannst
Du auch noch ne ganz kurze LIESMICH.txt oder so dabei tun, fuer Leute,
die nicht so gut Englisch koennen und mit der README.txt nicht klar
kommen.
@Kurt & Hayo:
Der Monochrome-Dump ist mit dem geaenderten RLE ja nun sehr ineffizient
(im Vergleich zu vorher geworden (28k vs. 12-15k)). Konsequenterweise
muessten wir den alten Algo wieder hernehmen dafuer (oder nochmal
verbessern).
duck
Win32 .EXE im Anhang. Bitte nochmal testen.
Niklas
Niklas O. schrieb:
...
> Der Monochrome-Dump ist mit dem geaenderten RLE ja nun sehr ineffizient> (im Vergleich zu vorher geworden (28k vs. 12-15k)).
Huch, ist er das? Werde ich mir ansehen.
> Konsequenterweise> muessten wir den alten Algo wieder hernehmen dafuer (oder nochmal> verbessern).> *duck*
Da gibts nichts zu ducken. Wenn ich was verschlimmbessert habe, hilft
Kritik doch nur, es besser machen zu können.
Der Dump der Rohdaten ist ja auch nicht RLE-komprimiert, weil klar war,
daß kaum jemals mehrere identische Werte aufeinander folgen.
Hat eigentlich mal jemand versucht, die Baudrate zu erhöhen? Es gibt da
ein Element np_uartdivisor in der puart-Struct. In excalibur.h steht
allerdings
1
// Parameters for altera_avalon_uart named uart1
2
// baud = 115200
3
// data_bits = 8
4
// fixed_baud = 1
. Das könnte ein Hinweis sein, daß im FPGA ein fester Teiler ist. Im
USB-UART ist fixed_baud übrigens "0"...
Falk
Hallo Niklas O.,
nach kurzem Test: Funktioniert so recht gut! Sogar der -i - Switch ist
schon da!( Spart viel Tinte :-)
Vielleicht noch das Abräumen der einzelnen Plane-Dateien nach dem
Zusammensetzen der Screenshot-xxx-Datei?
Danke!
Gruß Jürgen
Hi, echt super!
Bin gerade erst wieder zuhause. Werde mal alles einsammeln und als Paket
ins SFN stellen. Zum Dokumentieren und Testen komme ich heute nicht
mehr.
@Niklas
Gibts die Source auf SFN, oder stellst Du die eben noch hier mit ins
Forum?
Hayo
Hallo Jürgen,
> nach kurzem Test: Funktioniert so recht gut! Sogar der -i - Switch ist> schon da!( Spart viel Tinte :-)
Das war die Intention :) Muesste man in zukuenftigen Versionen
egtl. auch erweitern koennen und direkt auf einem Windows-Drucker
drucken.
> Vielleicht noch das Abräumen der einzelnen Plane-Dateien nach dem> Zusammensetzen der Screenshot-xxx-Datei?
Das sollte nur bei dem (default) PPM/PGM-Output passieren und ist
bei BMP mit -b abgeschaltet. Eine programmtechnische Notwendigkeit
dafuer gibt es nicht, die Daten sind im RAM. Gedacht war das primaer
zum Debuggen von Fehlern in der Bildschirmausgabe. Wenn irgendwo ein
Artefakt ist kann man so leicht rausfinden in welchem Plane. In
zukuenftigen Versionen sollte man optional machen, das sehe ich
genauso.
@Falk:
> [Baudrate]
Da wir die Daten ohnehin nur im Schneckentempo verarbeitet bekommen
erreichen wir ja nichtmal 38400 Baud. Nun wissen wir auch, warum
das Datendumping in der Original-Firmware mit der Welec-Software
auch schon ewig dauerte -- und das war via USB. Bzgl. der Baudrate
hab' ich nur mal getestet ob man theoretisch mit dem Nios die
Leitung saturieren koennte, und das ging. >=10kB/s sustained
mit putchar(). Ansonsten haben oben iirc. Crazor und andere schonmal
was zum im FPGA implementierten UART geschrieben.
> [Rohdaten Trace]
Ja, RLE bringt eher nix dort. Hatte wie schonmal ausgefuehrt an
Ausgabe von Delta zwischen Messwert und Messwert n+1 gedacht
(was in der Theorie im Durchschnitt ein geringer Wert sein sollte)
aber die Idee fallen gelassen, da es eh nur max. 4*16kB sind und
jegliche Verarbeitung auf dem Nios die Sache vmtl. langsamer statt
schneller machen wuerde. CSV Ausgabe ueber ZMODEM direkt an
beliebiges Terminalprogramm wuerde ich aber dennoch gerne hinzufuegen.
Niklas
Hallo
Habe die letzten Screenshots mal getestet.
Leider finde ich bei keinem das File, das er wohl schreiben sollte ?
Die älteren Versionen haben das in das gleiche Verzeichnis geschrieben,
in dem das Programm gestartet wurde.
Bei der letzte Version verschwindet das Programm beim auslesen ganz ?!
FFT:
Habe mit dem mal gespielt..
Schaut gut aus aber..
Nach FFT und dann Osci ausschalten (ein paar Stunden), hatte ich nach
dem Wiedereinschalten das FFT im LCD und der ganze FFT-Bereich war
gelb..
Wollte das dann mal nachstellen, ging bis jetzt aber nicht mehr...
Ab und zu beim zurück vom FFT durch "Math" sind die Kanäle
durcheinander...
Wenn ich im FFT das Osci aus schalte und wieder ein, sehe ich das FFT
Display aber die "Math" Taste leuchtet nicht aber die Lampe unter der
Frequenzanzeige (zum Drehen)leuchtet.
Auch die Soft-Tasten sind nicht im FFT-Modus.
Versuche dann rauszukommen mit "Math"-Taste--> Softtasten werden zu FFT.
Dann wieder "Math"-Taste und komme dann aus dem FFT.
Leider sind jetzt alle Kanäle in der Mitte!
Mit "Default Setup" geht dann wieder alles.
l.G. Roberto
Hallo Hayo
0.84 funktioniert bei mir
Von "Quick Print" (Taste) bis zum Menue vergehen leider so ca. 3
Sekunden.
Der Screenshot funktioniert jetzt in ein File :-)
Das aussteigen aus dem FFT funktioniert auch.
Nach dem Aus/Ein schalten vom DSO ist FFT auch weg :-)
Das FFT ist aber die 1er Version (2er ist schöner :-)
Könnte man die Umschaltung der FFT-Versionen im Soft-Menue machen ?
mmhh.. irgendwas spinnt da noch...
Einmal hatte ich wieder den ganzen FFT-Bereich in gelb und einmal nach
FFT wieder die Kanäle durcheinander ?!
Gehe immer in FFT, DSO aus/ein schalten und dann wieder in FFT.
Jetzt hat er sogar die Version 2 vom FFT eingeschalten ?!
(Length auf 1024)
l.G. Roberto
Ok Jungs keine Sorge,
angeregt durch die Diskussion im Hardwarethread habe ich ein wenig mit
Rauschunterdrückung experimentiert. Das funktioniert so gut, das ich
heute noch ein neues Betarelease rausgebe, da ist dann auch Euer Problem
beseitigt.
Hayo
Oh Gott man - geh doch auch mal in den Biergarten (mit Frauchen)...bei
dem Wetter!!
elgodil
PS: Der Tipp dient natürlich nur dazu, deinen Programmierelan über
möglichst lange Zeit zu erhalten ;-)
So, bin soweit. Hier das neue 0.85 beta Release.
Die neue Rauschunterdrückung arbeitet wirklich überzeugend. Dadurch
werden die 2er und 1er Bereiche tatsächlich benutzbar!!! Die
Rauschunterdrückung nutzt die sonst unbenutzten Samples bei
Timebasefaktoren > 1. D.h. der Arbeitsbereich liegt zwischen 100ns und
500ms. Keine Beeinträchtigung der Bandbreite!! Besonders überzeugend
kommt die neue Funktion z.B. im 2V Bereich bei 500ns. Natürlich kostet
die Funktion etwas Performance, aber das liegt denke ich, noch im grünen
Bereich.
Wo kann man die Rauschunterdrückung anschalten?
-> im Acquire Menü.
Ansonsten gibt es für Roberto jetzt einen Button für das FFT-Layout im
FFT-Menü und die undefinierten Startzustände sind beseitigt.
So bin mal gespannt auf die Reaktion.
Hayo
Hayo W. schrieb:
> So bin mal gespannt auf die Reaktion.
Alda!!!!
Plötzlich sieht es genau so aus, wie ich es von Anfang an gern gesehen
hätte. Das ist ein Unterschied wie zwischen Tag und Nacht!
Super Sache!
/Hannes
Kann's ja gar nicht erwarten das morgen früh einzuspielen :)
Wenn ich das vorhin im Hardware-Thread, beim kurzen Überfliegen, richtig
mitbekommen habe, nimmst Du jetzt 5 Samples im einen Wert zu mitteln.
Evtl. wäre es für die Performance hilfreich, einen Wert fallen zu lassen
und mit 4 Werten zu arbeiten; je nachdem wie der Compiler optimiert...
@Stefan
Das war nur der Prototyp. Die jetzige Version ist auf shift optimiert.
D.h. der am wenigsten effektive Bereich ist der 100ns Bereich, da hier
der Faktor nur 2 ist.
die Bereiche mit Faktor 4 und 5 (also die meisten) arbeiten mit 8 Werten
d.h. shift um 3 nach rechts, die TB mit Faktoren >= 10 arbeiten mit 16
Werten d.h. >> 4.
Hayo
Das Ergebnis ist super =)
Ein minor Bug, wenn man die FFT Ansicht ändert, wird das schwarze Layout
hinter dem gelben gezeichnet. Nach nochmaligem de- und aktivieren wird
das Menü richtig gezeichnet.
Hallo Hayo,
die neuen Änderungen, mein letztes aufgespieltes Release war die 0.75,
schauen wirklich sehr interessant aus. Dies bezieht sich auch auf die
Screendump-Funktion. Wirklich gute Arbeit!
"Wie mit dem Lineal gezogen!" kann ich so zwar nicht abkaufen, aber die
Verbesserung ist deutlich zu sehen.
Mal eine Frage anderer Natur. Es wurde ja mal irgendwo schon
angesprochen. Die Welec-Timebasetabelle ist ja etwas merkwürdig mit
ihrem Sprung von 250MS/s auf 25MS/s. Erwarten würde man ja noch die
Zwischenschritte 100MS/s und 50MS/s. Habt ihr dahingehend irgendwie
Zugriff drauf, um eine Änderung zu erzielen?
Falls ja, so würde ich dies ziemlich weit oben in der Prioritätenliste
sehen.
Beste Grüße, branadic
Hallo Hayo,
das sieht wirklich gut aus. Langsam wird das Welec so, wie ich
mir das beim Kauf vorgestellt habe. Fehlt nur noch die USB-
Anbindung für Screendump, und etwas Entwanzung (ich küümmere
mich in den nächsten Tagen um die Pixelfehler, kann ja nichts
Großes sein), dann wird aber die 1.00 fällig :-).
Gruß, Guido
@branadic
Du kennst meine Lineale nicht! ;)
Zugegeben - war leicht übertrieben. Aber die Begeisterung nach dem
Flashen war groß und ist es immmernoch.
Dickes Kompliment an Hayo!
Lothar
@Hayo
Gute Arbeit, ein bisschen beschneidest du mit der Mittelung die
dargestellte Bandbreite (um das zu verhindern duerftest du in jedem
Bereich max. Faktor Werte fuer die Mittelung verwenden), meiner Meinung
nach kann das aber so bleiben, und zudem kann man die Mittelung ja
abschalten.
Wenn du nun auch noch meine andere Idee in betracht ziehen koenntest ;-)
Martin
Wäre jemand so freundlich bei Gelegenheit einen Screenshot mit/ohne
Mittelwertbildung im Vergleich einzustellen. Ich würde diese
Verbesserung auch gerne sehen.
@Martin
Ja, durch die Überlappung gibt es natürlich rein rechnerisch eine
Bandbreitenverringerung. Praktisch ist diese aber außerhalb der
darstellbaren tatsächlichen Signalbandbreite unseres DSO. D.h. bei einem
realen Signal wirst Du beim Umschalten keinen Unterschied bemerken. Wo
man es sehen kann, dass ist beim Testsignal. Da das Rechtecksignal hier
unendlich steile Flanken hat und damit natürlich extrem hohe
Frequenzanteile, sieht man beim Umschalten, dass die Flanken minimal
flacher werden.
> Wenn du nun auch noch meine andere Idee in betracht ziehen koenntest ;-)
Da bin ich schon längst bei. Ich habe aber Schwierigkeiten mir das
vorzustellen wie sich das auswirkt, wenn ich mehrere Werte an eine
X-Position schreibe. Dadurch wird doch eigentlich nur der Linienzug
breiter und damit das Signal unschärfer - oder hab ich das
mißverstanden?
Hayo
@Hayo
Das die Linie breiter wird ist richtig, diese Darstellung hilft aber ein
untersampling zu erkennen (es wird die angezeigte Samplerate dargestellt
und nicht die durch den Faktor reduzierte).
Martin
Guido schrieb:
> Hallo Hayo,>> das sieht wirklich gut aus. Langsam wird das Welec so, wie ich> mir das beim Kauf vorgestellt habe. Fehlt nur noch die USB-> Anbindung für Screendump,
USB für Screendump sollte kein Problem sein. Da hat man aber nur die
halbe Gaudrate und auf der PC-Seite ist USB nicht so trivial wie RS232.
Mit Libusb habe ich schon etwas für Linux, wie das unter Windows
aussieht, weiß ich nicht.
Gruß,
Falk
P.S.: Heute kam mein Scope zurück. Anscheinend wurde das Mainboard
ausgetauscht. Über den Service kann ich mich nicht beklagen!
Ich benutze die neue Screenshotfunktion gerade das erste mal und stelle
fest, dass bei mir immer zwei Screebnshots produziert werden statt einer
(unter Windows getestet). Ist das bei Euch auch so?
Hayo
Hallo Hayo,
also bei mir wird nur ein Screendump erzeugt (screenshot-0000.bmp). Ich
starte mit den Parametern -b-s. Schade allerdings das Screendump.exe
nicht wartet bis ich einen Dump mit Quick Print anfordere, sondern
direkt loslegt. Keine gute Lösung!
Sehr überzeugendes Ergebnis mit der Rauschunterdrückung. Hätte gedacht
das dadurch die Performance stärker leidet, ist aber absolut im grünen
Bereich ;-)
Jetzt müssen wir nur noch das Rauschen in den schnelleren Bereichen in
den Griff bekommen... und die blöde Oszillation... und die Wishlist...
Gruß, brunowe
Andere scheinen das auch (standardmäßig) zu machen - bei meinem OWON
sahen die Kurven bis jetzt deshalb auch besser aus (und ich glaube
nicht, das der eine besonders edle Eingangsstufe hat ;-))
LG,
egberto
@Bruno
-s ist der Parameter für externes Auslösen! Wenn Du den weglässt wartet
das Programm auf das DSO.
Ich hab den Fehler für die "Doppelbelichtung" gefunden und beseitigt,
gibts im nächsten Release.
Ebenso gibt es einen kleinen Bug im neuen Acquire-Menü. Die Buttonlogik
wird beim Neustart hin und wieder durch alte (falsche) Flashwerte aus
dem Tritt gebracht und blockiert dann. Hier hilft erstmal default Setup.
Ist in der nächsten beta beseitigt.
Hayo
Hallo
Hier mal 3 Bilder mit den verschiedenen Einstelleungen.
Kanal 4 =10mV, Kanal 3 =20mV, Kanal 2 =50mV, Kanal 1 = 1kHz Signal
erstes Bild = Normal, zweites mit Averaging, drittes mit Denoising.
Die 1er und 2er Bereiche sind furchtbar, aber durch die neues Funktion
jetzt schon besser :-)
Screenshot:
Beim Screenshot kommen bei mir auch immer zwei Bilder!
Einstellung -c1 -b
Warum kann eigentlich der Photoshop 5.0 das BMP nicht lesen?
Kann das jemand bestätigen ?
FFT:
Funktioniert soweit :-)
Probiert mal:
Default Setup, 1kHz Signal an Kanal1, 500mv und 500us (alle 4 Kanäle
EIN)
dann auf Math,FFT,Settings,Length auf 1024, 3 Sekunden warten, Gerät
AUS/EIN
Dann sehe ich nur mehr Kanal 1 in der Mitte!
Und wieder ein Kompliment und Dankeschön an alle Entwickler :-) :-)
l.G. Roberto
Ich warte auch seit 1.7. auf mein Scope, das mir bis 8.7. zugesagt
wurde. Als es nicht kam wurde es bis gestern zugesagt und kam natürlich
wieder nicht. Langsam bin ich ziemlich genervt, schließlich will ich
hier auch endlich mitmischen können!
Außerdem ist das doch reichlich unprofessionell von den Wittigs, Zusagen
zu machen und dann nicht einzuhalten. Naja, vielleicht ist
Unprofessionalität ja ihre Firmenphilosophie? Dann müsste man zumindest
große Konsequenz bei der Umsetzung in allen Bereichen bescheinigen.
Hat das bei euch auch so lang gedauert?
Gruß, Michael
Hallo zusammen,
zum Export von Samples in ein CSV oder ASCII File hätte ich noch ein
paar Anregungen. Beim Tek gibt es die Möglichkeiten:
- Save Samples xxx to xxx
- Save Samples between Cursors
- Save Samples in Zoom Area (entspräche wahrscheinlich den Daten im
Delayed-Fenster)
- Save All
wobei die Anzahl der aufgezeichneten Samples explizit angezeigt wird.
Darüber hinaus lässt sich auswählen, welcher Kanal exportiert werden
soll:
- Channel 1 2 3 / 4
- Math 1 2 3 / 4
- Ref 1 2 3 / 4
Als Data Destination stehen zur Auswahl:
- Spreadsheet CSV
- Spreadsheet TXT
- Mathcad
- Matlab
Die Mathcad und Matlab Daten werden in einer .dat-Datei abgespeichert.
In den ersten 5 oder 6 Zeilen stehen die aktuellen Oszi-Einstellungen,
danach folgen mit Tabulator getrennt x-Werte [s] und y-Werte [V].
Ein Export der Daten mit Tabulatortrennung und in einer x-y-Auflistung
wäre sicherlich auch in unserem Falle hilfreich. Als x-Wert wird der
Triggerzeitpunkt zu NULL gesetzt, x-Werte vor dem Triggerereignis
entsprechen dann negativen Zeitpunkten und x-Werte nach dem
Triggerereignis entsprechend positiven.
Einen ähnlichen Datenexport gab es ja seinerzeit schon in der originalen
FW. Hier wurden alle Werte der aktiven Kanäle folgendermaßen exportiert
Zeitpunkt - Samplewert CH1 - Spannungswert CH1 - Samplewert CH2...
Der Vorteil wäre, dass sich ein Ereignis zeitlich besser eingrenzen
ließe.
Bezüglich des Aquisition Modes. Am Tek stehen hier ebenfalls
verschiedene Einstellung zur Verfügung:
- Samples (schätzungsweise entspricht das der übereinander gezeichneten
Darstellung von Samples, wie weiter oben schon erbeten, denn das
vermeintliche Rauschen ist hier extrem hoch)
- Peak Detect
- High Resolution
- Average
- Envelope
Als weitere Anregung möchte ich noch die Window-Types der FFT aufzählen:
- Rectangular
- Hamming
- Hanning
- Black-Harris
- Gaussian
- FlatTop2
- KaiserBessel
Ich bin natürlich gern bereit euch mit weiteren Info's vom Tek zu
versorgen, sofern dies gewünscht oder erfragt wird. Schaden kann es
meiner Meinung nach nicht zu schauen, was andere Geräte können. Ob sich
sowas dann auch im Welec realisieren lässt sein mal dahingestellt.
Nächste Woche bekomme ich übrigens eine Vorführung bei uns im Hause.
Dann werden mir ein Tek der 4000er-Serie und ein vergleichbares Agilent
vorgestellt. Nach Aussagen des Außendienstmitarbeiters heute arbeitet
Agilent mit einer Aquisition von 100000, Tek dagegen nur mit der Hälfte.
Hameg ist mittlerweile wohl von einem namenhaften Hersteller aufgekauft
worden.
Nach wie vor bin ich übrigens der Meinung, dass der Triggerlevel nicht
auf einen Pixelwert auf dem TFT eingestellt werden soll, sondern auf
einen Spannungswert. Sobald ich also den Spannungsbereich meines
Signales umstelle sollte der Triggerlevel nach wie vor auf den gleichen
Spannungswert des Signales triggern.
Vielleicht lassen sich hier ja auch beide Möglichkeiten implementieren,
dann wäre es für jeden individuell einstellbar.
Soweit erst einmal von hier.
Beste Grüße, branadic
branadic schrieb:
> Nach wie vor bin ich übrigens der Meinung, dass der Triggerlevel nicht> auf einen Pixelwert auf dem TFT eingestellt werden soll, sondern auf> einen Spannungswert. Sobald ich also den Spannungsbereich meines> Signales umstelle sollte der Triggerlevel nach wie vor auf den gleichen> Spannungswert des Signales triggern.> Vielleicht lassen sich hier ja auch beide Möglichkeiten implementieren,> dann wäre es für jeden individuell einstellbar.
Das finde ich auch, allerdings wirst du kleinere Sprünge in der zu
triggernden Spannung hinnehmen müssen, da ja (vermutlich auch im
Originaldesign; definitiv aber bei mir) auf ADC-Rohwerte getriggert
wird.
Hallo Roberto,
> Screenshot:> Beim Screenshot kommen bei mir auch immer zwei Bilder!> Einstellung -c1 -b> Warum kann eigentlich der Photoshop 5.0 das BMP nicht lesen?> Kann das jemand bestätigen ?
Das Problem zum ersten Punkt hat Hayo ja schon gefunden und
ist Firmware-seitig.
Letzteres habe ich in der englischen README beschrieben.
Es haengt damit zusammen, dass die Standardvariante, die Pixel
im BMP Format abzuspeichern, entgegen der konventionellen
Reihenfolge geht. Statt von oben links Zeilenweise bis unten
rechts geht's da von unten links bis oben rechts. Aber es
ist durch Angabe einer negativen Hoehe auch vorgesehen in
"normaler" Reihenfolge abzuspeichern. Wie sich fuer mich
erst nach Implementation heraus stellte ist dies anscheinend
manchen Bibliotheken und/oder Programmen nicht bekannt und
wollen mit der Datei nichts anfangen.
Niklas
@ Hayo,
ich hab da noch einmal ein paar prinzipielle Frage zu deiner FFT:
1.) Wenn ich auf Gauss bzw. Kais.-Bess. schalte wird mein ganzer
Bildschirm gelb/ bzw. grün- übersteuert- alle anderen Fensterfkt. sind
ok. --known Bug?
2.) die Anzeige rechts bedeutet?
df = kleinster Frequenzauflösung bei der FFT- Berechnung (man erkennt
schön wie bei Übergang von 512 zu 1024 dieser Wert halbiert wird)
_fn_: Hälfte der oben angezeigten Samplingfrequenz- wobei hier der TB-
Faktor nicht berücksichtigt wird- Was bringt diese Anzeige also dann?
_div_: ??? das erschließt sich mir jetzt leider nicht.
Wenn ich das richtig sehe, dann stellt die FFT- Funktion immer die
Frequenzen bis fn dar? (Obwohl der obere Bereich ggf. wg. dem TB- Faktor
gar nicht nutzbar ist und nur zu Fehlinterpretation führt)
Falls ich das soweit richtig verstanden habe, sollte man dann den
angezeigten Frequenzbereich nicht auf den sinnvollen Wertebereich
einschränken?
Das hatte ich oben schon mal angeregt, hatte mich diesbzgl. aber wohl
missverständlich ausgedrückt.
Gruß, brunowe
@Branadic
- Der Punkt mit dem Triggerlevel steht auch in meiner ToDo liste im
Beipackzettel des Paketes. Wie so of gibt es allerdings so viele Punkte
dass wir da nur Prioritäten sortieren können.
- Die FFT-Fenster stimmen ja schon fast überein, allerdings wollte ich
noch einige hinzufügen (z.B. Flat Top ist noch in Arbeit, Hamming steht
auch in der Pipeline und zu Poisson und Kaiser-Bessel hab ich noch
Versionen mit anderen Koeffizienten parat).
- Der Datendownload ist nur ein erster Prototyp. Deine Anregungen sind
schon mal sehr gut. An diesem Thema werden wohl Niklas und Falk (jetzt
wieder mit Oszi) dran sein.
Hayo
Sehr schöne FFT. Hut ab!
Auch die Unterordnung des Screenshot-Verzeichnisses unter die Firmware
finde ich gut.
Zur Baudrate: Beim RS232-UART ist die anscheinend nicht zu ändern. Das
könnte beim USB-UART anders sein. Das aber wäre nur sinnvoll, wenn man
auch die des Cypress ändern könnte, und davon verstehe ich nix.
Bei mir dauert der BW-Screenshot übrigens 12s...
Bezüglich der CSV-Dumps halte ich es für sinnvoll, Auflösung, Zeitbasis
und alle anderen Parameter in einem Header mitzusenden. Das kann ja
nicht allzuviel sein.
Falk
Hallo branadic,
> zum Export von Samples in ein CSV oder ASCII File hätte ich noch ein> paar Anregungen. Beim Tek gibt es die Möglichkeiten:>> - Save Samples xxx to xxx> - Save Samples between Cursors> - Save Samples in Zoom Area (entspräche wahrscheinlich den Daten im> Delayed-Fenster)> - Save All
Mhm. Wahrscheinlich hat das Tek eine wesentlich groeszere
Samplingtiefe,
oder? Jedenfalls sind das IMHO bissl viel Einstellungsmoeglichkeiten.
Die Cursor-Werte usw. koennen wir mituebermitteln, so dass diese
entsprechend gekennzeichnet werden koennen.
Einbau von selektiver Speicherung ist sicherlich nicht schwierig, die
Frage ist, was da bei unserem Geraet sinvoll ist und die Bedienung
nicht unnoetig verkompliziert. Cursor, Screen und All z.B.. Bei nem
Delayed-Fenster waere Screen dann der untere "gezoomte" Teil.
> wobei die Anzahl der aufgezeichneten Samples explizit angezeigt wird.
Siehe oben, bringt bei uns nicht so viel.
> Darüber hinaus lässt sich auswählen, welcher Kanal exportiert werden> soll:>> - Channel 1 2 3 / 4> - Math 1 2 3 / 4> - Ref 1 2 3 / 4
Mhm, was ist denn Ref da? Koennte man statt da nochmal die Kanaele
auszuwaehlen die ungewollten nicht einfach fuer den Export ausschalten?
Waere intuitiver.
(Vorrausgesetzt natuerlich, man hat das Sampling bereits gestoppt.)
> Als Data Destination stehen zur Auswahl:>> - Spreadsheet CSV> - Spreadsheet TXT> - Mathcad> - Matlab> [Textuelle Beschreibung]
Kannst Du uns da mal fuer alle Moeglichkeiten reale Ausgaben
vom Tek zukommen lassen?
Niklas
@Bruno
> 1.) Wenn ich auf Gauss bzw. Kais.-Bess. schalte wird mein ganzer> Bildschirm gelb/ bzw. grün- übersteuert- alle anderen Fensterfkt.> sind ok. --known Bug?
Äh nein, war mir noch nicht aufgefallen - ist notiert
> 2.) die Anzeige rechts bedeutet?
df -> delta frequency - ist die spectrale Auflösung der FFT (Bandbreite
einer Linie)
fN -> Nyquistfrequenz, entspricht der maximal darstellbaren Frequenz der
FFT
div -> frequenzteilung des Grid, Bandbreite eines Gridrasters
> Wenn ich das richtig sehe, dann stellt die FFT- Funktion immer die> Frequenzen bis fn dar? (Obwohl der obere Bereich ggf. wg. dem TB- Faktor> gar nicht nutzbar ist und nur zu Fehlinterpretation führt)
Der TB-Faktor wird bei der FFT nicht berücksichtigt. Entscheidend ist
daher für die FFT nicht die TB in Zeit/div sondern die angezeigte
Samplerate und dementsprechend auch der halbe Kehrwert nahmlich die
Nyquistfrequenz
Hayo
Noch einer zur Datenübertragung:
Der Math-Channel enthält nur redundante Daten, die zudem auch nur für
den angezeigten Fensterausschnitt berechnet werden. Da diese Daten auch
problemlos extern (in einem Excelsheet oder einem Programm)
rekonstruiert werden können, muß man die nicht auch noch durch die
Strippe quetschen.
Hayo
Hallo,
@Falk:
> Bei mir dauert der BW-Screenshot übrigens 12s..
Falls Du Dich auf meine "Kritik" von zuvor beziehst:
Ich meinte nicht eine verschlechterte Zeit sondern
die Verdopplung der Datenmenge :)
@Hayo:
Wo ich gerade am Testen bin: Wir hatten mal das Thema
Save/Recall, was in unserer FW nicht mehr funktionierte.
Du meintest glaube ich, dass es an den geaenderten
Speicherstellen laege. Hattest Du das schon gefixt?
Bin gerade zufaellig wieder drauf gekommen als branadic
die Ueberlagerung/den Vergleich von Samples erwaehnte.
Bei mir funktioniert Save/Recall bei 0.85 jedenfalls
noch nicht.
Ich hatte glaub' ich auch angeregt, fuer solche Vergleiche
unbenutzte Planes herzunehmen. Wie sieht das aus technischer
Sicht aus, ist da was "hart verdrahtet" im FPGA oder koennen
wir auch eigene Planes fuer diese Zwecke erzeugen?
Niklas
Hi,
kann man zu der FFT nicht noch 'ne Möglichkeit hiinzufügen, um das
Originalsignal (meinetwegen auch skaliert) mit darzustellen? Hab hier
mal einen Screenshot eines anderen scopes gefunden...
(nur so eine Idee, nicht das Hayo noch auf den Gedanken kommt, ein Bier
trinken zu gehen...)
;-)
Hallo Falk,
> Bezüglich der CSV-Dumps halte ich es für sinnvoll, Auflösung, Zeitbasis> und alle anderen Parameter in einem Header mitzusenden. Das kann ja> nicht allzuviel sein.
Ja, so hatte ich mir das urspruenglich auch vorgestellt.
Sag mal, wo Du ja auch noch Deine QT-GUI ins SVN Repository stellen
wolltest, sollten wir nicht gleich aus dem vorhanden Auslesecode
eine Library machen, die dann sowohl GUI und Konsolenprogramm
benutzen?
Wie sieht Dein Plan aus? Wenn uns branadic die Beispielausgaben
liefert wuerde ich mich gerne daran machen das umzusetzen.
Du wolltest ja auch die Firmware handlicher machen.
(Ich habe die btw. die naechsten Tage wieder Zeit.)
Wir sollten uns da mal abstimmen, auch bzgl. der Reorganisation
des Repositories durch Daniel/crazor.
Niklas
@Niklas
An der Save/Recall-Sache war ich noch nicht dran, da ich erst mal unsere
Organisatorische Pause abwarten wollte, das Release gestern war nur eine
Spontane Sache. Ich könnte allerdings die minor Fixes von heute noch
reinstellen bevor wir dichtmachen, soll ich?
@Michael
Ist machbar, erfordert aber eine neue bzw. stark überarbeitete
Zeichenroutine. Daher wird das wohl kurzfristig nichts (bin in zwei
Wochen erstmal im Urlaub zum Biertrinken ;-))
Ist aber im Hinterkopf.
Hayo
Niklas O. schrieb:
> Hallo,>> @Falk:>> Bei mir dauert der BW-Screenshot übrigens 12s..> Falls Du Dich auf meine "Kritik" von zuvor beziehst:> Ich meinte nicht eine verschlechterte Zeit sondern> die Verdopplung der Datenmenge :)
"Size does not matter" ;-)
Ich kann mit 12s/30s gut leben, also lasse ich das vorerst so.
Interessanter finde ich ja ohnehin die Rohdaten. Die kann man
schließlich auf dem PC beliebig weiterverarbeiten, während ein
Screenshot nur ein Bild darstellt.
Die Übertragung der Daten aller vier Kanäle dauert ca. 7s, die ganzen
Parameter sollten in unter einer Sekunde zu übertragen sein.
Dann hat man alle Informationen, um auf dem PC ein Bild zu malen, zu
Drucken, Mathcad/Matlab-Files zu schreiben, wildeste Analysen
anzustellen oder automatisiert einen Twitter-Eintrag zu schreiben ;-)
Als sinnvolle Verbesserung sehe ich eher, die Einstellungen zu
übertragen und nur die ausgewählten Kanäle.
Eine Fernsteuerung mit dem PC könnte auch noch interessant sein.
Meine 2¢,
Falk
Niklas O. schrieb:
> Hallo Falk,> Sag mal, wo Du ja auch noch Deine QT-GUI ins SVN Repository stellen> wolltest,
Das will ich noch an die geänderte Firmware anpassen. Das kommuniziert
genauso mit dem Scope, wie das screendump-Programm.
> sollten wir nicht gleich aus dem vorhanden Auslesecode> eine Library machen, die dann sowohl GUI und Konsolenprogramm> benutzen?
Ok, mach' ich.
> Wie sieht Dein Plan aus? Wenn uns branadic die Beispielausgaben> liefert wuerde ich mich gerne daran machen das umzusetzen.> Du wolltest ja auch die Firmware handlicher machen.> (Ich habe die btw. die naechsten Tage wieder Zeit.)
Im ersten Schritt fände ich es gut, die PC-Kommunikationsfunktionen in
eine getrennte Datei auszulagern, also "Display::DUMPCSV",
"Display::SCREENSHOT", Display::SCREENSHOT_BW, und "rle_enc" in
pc_comm.cpp/h.
> Wir sollten uns da mal abstimmen, auch bzgl. der Reorganisation> des Repositories durch Daniel/crazor.
Mein Vorschlag: Irgendwo unterhalb /
- firmware/FW1.2.BF.X.yy/src
- firmware/FW1.2.BF.X.yy/Screenshot_X.Y/
etc.
Aber soll Daniel doch einfach einen Vorschlag machen (oder hatte er das
nicht schon?)
Falk
Mal ne Frage an die Spezis:
Die USB-Verbindung zum Rechner ist doch im Scope auch "nur" ne UART. Wie
geht es denn ab dem FX1 dann weiter zum Rechner? Zumindest bei einem
schnellen Test konnte ich nicht ausmachen, dass die Originalsoftware
(+Treiber) einen virtuellen COM-Port anlegt, über den dann die
Kommunikation erfolgt.
Irgendwer hatte doch auch schonmal angefangen, das USB-"Protokoll" zu
reversen, wo gab's denn noch die Infos dazu? Ich frage mich, ob
eventuell ohne allzugroße Änderungen doch noch eine UART-Verbindung über
USB machbar ist...
Habe etwas zu frueh geschumpfen: Das W2024A ist heute bei mir
eingetroffen (und scheint auch in gutem Zustand zu sein), wieder
erwarten sogar mit 4 Sonden!
Auf die Wittigs ist noch verlass.
Martin
Daniel H. schrieb:
> Mal ne Frage an die Spezis:
...
> Irgendwer hatte doch auch schonmal angefangen, das USB-"Protokoll" zu> reversen, wo gab's denn noch die Infos dazu? Ich frage mich, ob> eventuell ohne allzugroße Änderungen doch noch eine UART-Verbindung über> USB machbar ist...
Ich hatte mit "usbmon" getraced und dann mit der "libusb" verschiedene
Kommandos ausprobiert.
Das Ergebnis steht hier:
http://groups.google.com/group/welec-dso/web/usb-commands?hl=en
Das scheint nicht einfach USB-RS232 zu sein, sondern etwas
Capress-spezifisches. Deswegen nehme ich auch an, daß man per USP auch
die Baudrate des Chips ändern kann.
Falk
Der Cypress ist im Grunde ein um den USB erweiterter 8051er.
Es gibt auf der Cypress Seite Tools und Code. Hatte mich im Zusammenhang
mit dem ByteBlaster mal ein wenig eingelesen. Die beste Lösung wäre die:
Einen rudimentären Treiber zu schreiben, der dann im Zusammenhang mit
der PC-Software die entsprechende Funktionalität in den Cypress nachlädt
(ByteBlaster, UART, ... was auch immer).
Leider bin ich als 'Hochsprachler' noch nicht viel weiter gekommen und
habe jobmäßig auch arg viel zu tun... Bin froh, wenn ich diese Woche die
ersten Taschen raushauen kann ;-)
Michel
Hab's nicht verstanden... was genau spricht gegen die momentan
schnellere serielle Schnittstelle (?) evtl. der erforderliche
usb-to-serial dongle für 3-4 Euro ?
Meiner Meinung nach gibt es noch so viele Baustellen, bei denen es keine
funktionierende Alternative gibt.
Falk Willberg schrieb:
> Niklas O. schrieb:>> Hallo Falk,>>> Sag mal, wo Du ja auch noch Deine QT-GUI ins SVN Repository stellen>> wolltest,>> Das will ich noch an die geänderte Firmware anpassen. Das kommuniziert> genauso mit dem Scope, wie das screendump-Programm.
Ok, ich hatte es ja angedroht. Das tar-Archiv ist angehängt. Es
kompiliert unter Linux, funktioniert aber nicht mit irgendeiner
Firmware. Betrachtet es bitte als Qt-Übung.
Leider habe ich im SVN völlig die Übersicht verloren, daher hier als
Anhang.
Jeder, der sich mit Qt auskennt, ist herzlich eingeladen, Verbesserungen
einzubauen.
Falk
Stefan schrieb:
> Hab's nicht verstanden... was genau spricht gegen die momentan> schnellere serielle Schnittstelle (?)
IMO nichts. Wenn wir es schaffen sollten, die Baudrate da zu
vervierfachen (223400), könnte es sinnvoll sein...
Falk
Michael W. schrieb:
> Der Cypress ist im Grunde ein um den USB erweiterter 8051er.>> Es gibt auf der Cypress Seite Tools und Code. Hatte mich im Zusammenhang> mit dem ByteBlaster mal ein wenig eingelesen. Die beste Lösung wäre die:> Einen rudimentären Treiber zu schreiben, der dann im Zusammenhang mit> der PC-Software die entsprechende Funktionalität in den Cypress nachlädt> (ByteBlaster, UART, ... was auch immer).
Genau soetwas habe ich im Gespräch mit Hans auch schon ausgeheckt. Hans
hat sich daraufhin auch schon mit der Materie auseinandergesetzt. Unsere
Idee ist, die ByteBlaster-Firmware dahingehend zu erweitern, dass sie
eben auch als virtueller COM-Port fungieren kann. Falls das nicht
zeitgleich möglich ist, dann sollte die Umschaltung von der Seite des
Softprozessors im FPGA aus realisiert werden. Man könnte dann ein
kleines Powerup-Protokoll implementieren, das bei Ausbleiben einer
Meldung von Seiten des FPGA einfach die ByteBlaster-Firmware startet,
damit man den Zugriff auf den FPGA nicht verlieren kann.
Falls du oder jemand anderes mehr Erfahrungen mit den EZ-USB's hat,
mache ich dich/euch gern mit Hans bekannt.
Edit: Bei der Gelegenheit sollte man den Humbug mit der "ReNumeration"
auch sein lassen und solch eine Firmware direkt in das EEPROM packen,
das am FX1 (gnädigerweise) dranhängt. Habe da momentan fest die
ByteBlaster-Firmware drin, da es so keine Probleme mehr mit Quartus
gibt.
Hallo Niklas,
ich habe mal die vier Datenexportformate im Anhang. Signal ist das
1kHz-Probesignal vom Oszi selbst. Exportiert habe ich in CSV, TXT,
Mathcad und Matlab. Bei dem Mathcad-Export wird zusätzlich noch eine
x_hdr.dat erzeugt, beim Matlab-Export ist es direkt eine x.hdr
> - Save Samples xxx to xxx> - Save Samples between Cursors> - Save Samples in Zoom Area (entspräche wahrscheinlich den Daten im> Delayed-Fenster)> - Save All> Mhm. Wahrscheinlich hat das Tek eine wesentlich groeszere Samplingtiefe,> oder? Jedenfalls sind das IMHO bissl viel Einstellungsmoeglichkeiten.
Ich denke das ein Export der Werte zwischen den Cursorn bspw. sehr
sinnvoll sein kann. Reduziert schließlich die Anzahl der zu
exportierenden Daten.
Auch die erste Möglichkeit ist so abwägig nicht. Angenommen man hat
500.000 Samples, dann besteht die Möglichkeit bspw. Sample 12.000 -
120.000 zu exportieren. Auch diese Möglichkeit reduziert die Anzahl der
zu übertragenden Daten.
Bei der Zoom Area liegen wir beide richtig, das entspricht den im
Delayed-Fenster dargestellten Daten. Auch dies hat eine Datenreduktion
zur Folge.
Save All bezieht sich lediglich auf den gewählten Kanal und bedeutet,
dass die gesamten Samples, also die volle Fensterbreite an Daten,
übertragen wird. Diese Einstellung bezieht sich allerdings beim Tek
ebenfalls wieder nur auf einen gewählten Kanal, nicht auf alle.
Als Grafikformate stehen übrigens
24-bit Bitmap (*.bmp)
JPEG (*.jpg)
PCX (*.pcx)
Portable Network Graphic (*.png)
Tagged Image File Format (*.tif)
zur Verfügung.
Was es mit dem Ref 1 - 4 auf sich hat muss ich mal noch in Erfahrung
bringen, hab ich bisher selbst noch nicht genutzt. Könnte aber ein
früher abgespeichertes und zum Vergleich mit einem Signal herangezogenes
Signal sein. Könnte bei uns dem Recall-Signal entsprechen. Das ist aber
Spekulation meinerseits.
Beste Grüße, branadic
So, es hat mir gerade keine Ruhe gelassen und ich hab am Oszi mal etwas
näher nachgeschaut.
Es ist so wie schon von mir spekuliert wurde. Man kann Signale
aufzeichnen und abspeichern, um sie anschließend als Referenzsignal
wieder hereinzuladen. Das Oszi kann dabei bis zu vier gespeicherte
Referenzsignale gleichzeitig mit vier Messsignalen und vier
mathematischen Signalen verarbeiten. Schon heiß, sag ich mal ;)
Das heißt auch, dass das Referenzsignal unserem Recall-Signal
entspricht. Also alles genau so wie vermutet korrekt.
Beste Grüße, branadic
Hallo,
ich hab' Falks Qt-GUI ins SNV importiert unter /pc/w2000a-qtgui/
(Namen koennen wir ja spaeter nochmal aendern) und einen Ordner
/pc/libw2000a/ fuer gemeinsam genutzten Code angelegt.
Wer sich dem Code annehmen moechte aber nicht mit SVN klarkommt
kann natuerlich auch die Aenderungen hier senden.
@branadic:
Danke fuer die Files.
@Hayo:
> [SVN Repository, Strukturierung, Firmware handlicher machen]> Ich könnte allerdings die minor Fixes von heute noch> reinstellen bevor wir dichtmachen, soll ich?
Ja waere vllt. nicht schlecht. Stefan hat ja das Repository
bereits auf den Stand 0.84 und dann 0.85 gebracht. Fehlt also
wirklich nur heute.
Der egtl. angedachte Platz von Daniel fuer die Firmware waere
dann unter /fpga/nios/, z.B. also /fpga/nios/blueflash und
/fpga/nios/welec fuer die 1.2.
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"
@Falk:
> Mein Vorschlag: Irgendwo unterhalb /> - firmware/FW1.2.BF.X.yy/src> - firmware/FW1.2.BF.X.yy/Screenshot_X.Y/
Das widerspraeche etwas dem Konzept von Versionssystemen :)
Was Du meinst kann man durch Tagging erreichen, also
einen bestimmten Versionsstand z.B. als "Release-FW1.2.BF.0.85"
auszeichnen. Wenn jemand dann genau den Stand moechte kann
er diesen explizit auschecken.
Aber da muss ich bei SVN leider passen, wie das dort geschieht
muesste ich selber nachlesen.
> Aber soll Daniel doch einfach einen Vorschlag machen> (oder hatte er das nicht schon?)
Ja hatte er, Link ist paar Zeilen hierueber. Wenn also einer
der versierten SVN Nutzer des Amtes walten wuerde und das in
die Tat umsetzt :)
Niklas
Niklas O. schrieb:
> Der egtl. angedachte Platz von Daniel fuer die Firmware waere> dann unter /fpga/nios/, z.B. also /fpga/nios/blueflash und> /fpga/nios/welec fuer die 1.2.> Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"
Super!
> @Falk:>> Mein Vorschlag: Irgendwo unterhalb />> - firmware/FW1.2.BF.X.yy/src>> - firmware/FW1.2.BF.X.yy/Screenshot_X.Y/>> Das widerspraeche etwas dem Konzept von Versionssystemen :)> Was Du meinst kann man durch Tagging erreichen, also> einen bestimmten Versionsstand z.B. als "Release-FW1.2.BF.0.85"> auszeichnen. Wenn jemand dann genau den Stand moechte kann> er diesen explizit auschecken.>> Aber da muss ich bei SVN leider passen, wie das dort geschieht> muesste ich selber nachlesen.
Wie ich oben schonmal geschrieben habe: SVN unterscheidet nicht zwischen
Copy-, Branch- und Tag-Operationen. Wenn man in ein Tag-Verzeichnis den
aktuellen Trunk kopiert, dann ist der Inhalt des Ordners einfach nur
eine Referenz auf den aktuellen Stand. Arbeitet man am Trunk weiter,
dann sind die Dateien im Tag-Verzeichnis quasi Zeiger auf die Versionen,
von denen beim Erstellen des Tags kopiert wurde. SVN verhindert
allerdings nicht, dass im Tag-Ordner herumgebastelt wird. Da ist dann
die Disziplin der Nutzer gefragt. Falls es dennoch mal passiert, sieht
man das schnell am Log und man kann mit nem Rückwärts-Diff die Lage
wieder richten.
Branchen geht genau wie Taggen, nur ist anschließend das Modifizieren
ausdrücklich erlaubt ;)
Ok, die 0.86 beta ist jetzt auch auf SFN verfügbar.
Ich habe die heute gemeldeten Bugs gefixed und noch eine neue Kanalwahl
für die FFT spendiert - man kann jetzt die Source auch direkt über die
Kanalknöpfe anwählen.
Hayo
Bevor es jemand anderes meldet: Eine Kleinigkeit hab ich jetzt bei der
Nachlese noch gefunden, die Kanalanzeige oben in der Statuszeile wird
nicht umgeschaltet wenn man die Source über das Menu einstellt. Da das
nich wirklich wehtut werde ich das mal bis zum nächsten Release
offenlassen.
Hayo
Ach ja, ich mach jetzt erstmal Entwicklungsstop. Wenn Ihr also
Organisatorisch oder Sourcemäßig was ändern wollt ist jetzt der richtige
Zeitpunkt. Die Sourcen sind noch nicht mit SVN eingepflegt, da ich mich
mit dem Teil noch nicht angefreundet habe. Vielleich kann das jemand für
mich übernehmen - danke!
Hayo
Hayo W. schrieb:
> Ok, die 0.86 beta ist jetzt auch auf SFN verfügbar.>> Ich habe die heute gemeldeten Bugs gefixed
......
Ich habe mal angefangen, eine neue Klasse PCComms mit
Sodala,
SF ist jetzt abgeändert. Sourcen liegen unter fpga/nios/oss
Die aktuelle Version ist die .86
Wo finde ich die original Sourcen? Nur der vollständigkeit halber.
@Hayo
wenn du eine persönliche Einführung in subversion willst, dann kannst ja
mal eine PM schreiben.
Gruß,
Stefan
Stefan E. schrieb:
> hab mal Nägel mit Köpfen gemacht und das angepasst. Langsam werde ich> war mit subversion
Wunderbar, wir haben einen Repository Manager ;-)
Nur, wo finde ich die aktuelle Version?
Das sieht ja shconmal gut aus im SVN Repo. Ein Hinweis noch: SVN bietet
auch einen Move-Befehl, der macht dann Copy&Delete in einem Schritt, mit
dem Vorteil, dass alle Repository-Browser das dann korrekt darstellen.
Hallo,
@Stefan:
> Wo finde ich die original Sourcen? Nur der vollständigkeit halber.
Ich bin erst seit kurzem dabei aber so wie ich das verstanden habe
hat Bruno urspruenglich
http://welec-dso.googlegroups.com/web/W2000A+Firmware+V1.2-+Sourcecode.zip
von Wittig erhalten.
Das sind aber nur ein paar C++ Dateien, es fehlt mind. die
Buildumgebung.
(Das war auch bis r129 im SVN Repository unter /fpga/welec/original/,
habe ich dann etwas uebereilig geloescht da es fuer mich unvollstaendig
aussah.)
Da muessten die "alteingesessenen" Bruno, Hayo und Co. was zu sagen. In
alten Threads habe ich Verweise auf Sourceforge gefunden die aber leider
nicht mehr funktionieren.
@Falk:
> Nur, wo finde ich die aktuelle Version?
Ich gehe mal davon aus, dass Du schon "svn update" gemacht hast.
Es sollte dann /fpga/firmware/ bis auf Deine lokalen Aenderungen
freigeraeumt sein. Die musst Du dann noch manuell uebernehmen.
Die aktuell gueltige Location ist nun wie Stefan schon schreibt
/fpga/nios/oss/. In /fpga/welec/improved/ wurde u.a. an
QuickMeasure gearbeitet und der Pfad wird momentan nicht
(mehr) verwendet.
Niklas
Niklas O. schrieb:
> @Falk:>> Nur, wo finde ich die aktuelle Version?
...
> Die aktuell gueltige Location ist nun wie Stefan schon schreibt> /fpga/nios/oss/.
Da bin ich jetzt dran. Ich habe die Behandlung von Zeichen vom UART in
die Klasse PCComms ausgelagert, ebenso unsere Screenshot-Funktionen.
Nach dem commit, werde ich diese Dateien auch wieder unlocken.
Damit ist praktisch alles, was mit der PC-Kommunikation zu tun hat, in
PC-comms.cpp/h.
Wenn ich das richtig sehe, haben wir nur einen Trunk, in dem gearbeitet
wird, aber keine Tags mit benutzbaren Zwischenreleases....
Falk
Ok, weg mit dem Ordner. Soll ich, wenn wir schon beim umstellen sind,
dass ganze noch um eine Ordner-Ebene erweitern, so dass unter 'oss'
erstmal nur 'tags','branches' und 'trunk' erscheint?
Stefan E. schrieb:
> Ok, weg mit dem Ordner. Soll ich, wenn wir schon beim umstellen sind,> dass ganze noch um eine Ordner-Ebene erweitern, so dass unter 'oss'> erstmal nur 'tags','branches' und 'trunk' erscheint?
Wegen mir gerne. Gearbeitet wird dann in Trunk? Und wenn ein Oberguru
"OK" sagt, macht er daraus einen Tag?
Falk, nix offen momentan
Hi, die Origanalsource hab ich natürlich noch rumliegen, besteht aber
nur aus fünf Dateien - schön unübersichtlich.
Die jetzige Aufteilung und das komplette Build mit SDK auf das meine
Entwicklungen aufbauen stammt von Andreas Fellnhofer, der das Ganze
freundlicherweise ausgetüftelt und zur Verfügung gestellt hat.
Zur Abschreckung und als Museumsstück kann man das ja mit reinstellen.
Der FFT-Ordner kann weg, sind nur Test und Beispielsourcen aus meinem
damaligen Projekt.
Hayo
Hayo W. schrieb:
> Hi, die Origanalsource hab ich natürlich noch rumliegen, besteht aber> nur aus fünf Dateien - schön unübersichtlich.
Hehe, die habe ich auch. Ich denke, über den Namen des Autors sollten
wir angesichts der unbekannten Umstände den Mantel des Schweigens
lassen.
Ich habe das mit dem SVN move auch mal probiert.
Wenn Du jetzt, statt ein ZIP-File zu bauen, "svn commit" eintippst, hat
unser CRO (Chief Repository Officer) auch weniger Arbeit ;-)
Schönen Abend,
Falk
P.S.: "Real Hackers don't do backups. They upload their sources and let
the others do backups." Frei nach Linus Torwalds
EDIT: Hoffentlich hat's noch keiner gesehen...
EDIT2: Wie machst Du die RAM-Version? Könntest Du das ins Makefile
einbauen?
Stefan E. schrieb:
> Nach dem wir die einzigen momentan sind, nutze ich gleich mal die> Chance...
Mhhh.... Wo sind meine Änderungen PC-comms.cpp aus r150 hin?
Falk
Hi Jungs, noch ein Vorschlag zur Aufteilung der Sourcen: Ich würde das
gesamte Signalprocessing in eine eigene Klasse auslagern - als da wären:
Die Hauptsignalprozessorroutine, die Mathfunktionen, FFT, Interpolation,
Filterroutinen und USTB-Routinen.
Dann wird die Display-Klasse etwas schlanker.
Hayo
Just btw:
Das trac welches auf dem Sourcefrosch angeboten wird, lässt sich auch
sehr gut zum Projektmanagement (Bugs, Features, etc) nutzen und spielt
auch sehr nett mit svn (subversion). Ein Beispiel ist (neben anderen):
http://trac.macports.org
@Hayo: Kommst Du aus HH? Dann könnten wir ggf. auch mal eine direkte
Einführung in Subversion/Trac machen ;)
Grüße,
Danke für die tolle Arbeit!
rowue
Wollte die Dateien gerade nachtragen. Warst ne Minute schneller. Ich
habe irgendwie den falschen Status kopiert. Vielleicht hat ein "svn
updte" gefehlt.
Sorry...
Stefan E. schrieb:
> Wollte die Dateien gerade nachtragen. Warst ne Minute schneller. Ich> habe irgendwie den falschen Status kopiert. Vielleicht hat ein "svn> updte" gefehlt.> Sorry...
Passiert.... Mit
hatte ich sie wieder und nach nochmaligem commit sind sie jetzt wieder
da. EDIT: Im Trunk, wo die hingehören.
Zum editieren meines Beitrages war es schon zu spät.
Manchmal wäre IRC nicht schlecht ;-)
Falk
Hallo Zusammen,
ich hatte gerade wieder ein Gespräch mit Crazor, um das neue FPGA-Design
weiter voran zu treiben. Dabei haben wir uns auch kurz über den
aktuellen Code von euch unterhalten.
Daniel hatte da kurz erwähnt, dass es vielleicht hilfreich sein könnte,
den Code komplett auf C anstatt C++ umzustellen. Besteht hier vielleicht
noch Potential für Geschwindigkeitsoptimierungen?
Beste Grüße, branadic
branadic schrieb:
> Hallo Zusammen,
...
> Daniel hatte da kurz erwähnt, dass es vielleicht hilfreich sein könnte,> den Code komplett auf C anstatt C++ umzustellen. Besteht hier vielleicht> noch Potential für Geschwindigkeitsoptimierungen?
Im Grunde ist das doch reinrassiges C zuzüglich Klassen.
Ob es einen Vorteil brächte, alles auf C-Syntax umzuschreiben,
bezweifele ich. Die zeitkritischen Sachen sind sowieso schon ziemlich
optimiert.
Mir würde es eher helfen, wenn ich einen Überblick hätte, welche
Variablentypen und Operationen wieviel Zeit kosten.
Falk
branadic schrieb:
> ich hatte gerade wieder ein Gespräch mit Crazor, um das neue FPGA-Design> weiter voran zu treiben. Dabei haben wir uns auch kurz über den> aktuellen Code von euch unterhalten.> Daniel hatte da kurz erwähnt, dass es vielleicht hilfreich sein könnte,> den Code komplett auf C anstatt C++ umzustellen. Besteht hier vielleicht> noch Potential für Geschwindigkeitsoptimierungen?
Vielleicht nicht der Riesenbringer in Sachen Geschwindigkeit, aber da
der Code ohnehin offenbar 95% C ist, könnte man sich zumindest die
Laufzeitbibliothek von C++ schenken, was sicher einigen Gewinn in Sachen
Codegröße bringen könnte. Eventuell werden Funktionen wie printf() oder
so auch schneller, wenn kein C++-Quatsch mehr unterstützt werden muss...
Guido schrieb:
> @ Hayo: damit das hier nicht untergeht:>> Schönen Urlaub, ich bin sehr, sehr neidisch!> Und das Notebook ist doch sicher dabei?
Also Urlaub geht erst in 2 Wochen los - dann aber für 3 Wochen in die
Toskana. Notebook ist natürlich dabei, kann ich locker damit
rechtfertigen dass wir die Urlaubsbilder Abends ansehen können ;-).
Vielleicht finde ich ja den einen oder anderen WLAN-Spot, dann melde ich
mich mal und schau mal was so abgeht...
@Wolle
> ..und nicht vergessen, das Oszi mit in die Tasche zu schmuggeln .....
Das wird schon schwieriger, ist mir aber auch schon durch den Kopf
gegangen...
@rowue
> Kommst Du aus HH?
Jupp!
> Dann könnten wir ggf. auch mal eine direkte Einführung in> Subversion/Trac machen ;)
Nettes Angebot. Ich wollte mir das jetzt mal in der Zwischenzeit zu
Gemüte führen. Ich hab gesehen, dass es auch eine KDE-Version gibt, die
wollte ich mal ausprobieren. Ansonsten komme ich gerne auf das Angebot
zurück.
Hayo
@Falk
In der aktuellen c't ist eine Einsteigeranleitung für Qt drin, die hab
ich heute morgen auf dem Weg zur Arbeit mal angelesen. Ich werde das mal
ausprobieren, dann kann ich da PC-seitig auch mit behilflich sein. Wär
ja ganz nett wenn wir irgendwann vom Kommandozeilengewerkel wegkämen
(auch wenn es bislang schon echt hilfreich ist). Ab einem bestimmten
Alter legt man halt Wert auf Komfort ;-)...
Hayo
Hayo W. schrieb:
> @Falk>> In der aktuellen c't ist eine Einsteigeranleitung für Qt drin, die hab> ich heute morgen auf dem Weg zur Arbeit mal angelesen.> Ich werde das mal> ausprobieren, dann kann ich da PC-seitig auch mit behilflich sein. Wär> ja ganz nett wenn wir irgendwann vom Kommandozeilengewerkel wegkämen> (auch wenn es bislang schon echt hilfreich ist). Ab einem bestimmten> Alter legt man halt Wert auf Komfort ;-)...
Naja, ich finde bspw. svn auf der Kommandozeile sehr komfortabel.
Aber ich finde die Möglichkeit angenehm, alle Funktionen des DSOs am PC
steuern zu können.
Und mit Qt kann man das auch für Windows kompilieren.
Eine Frage: Wie veranlasse ich das Scope dazu, eine neue Zeitbasis auch
anzuzeigen? Ändern tue ich die mit
Die Timebase ändert sich auch, aber die Statusanzeige nicht.
Sobald dieser erste Punkt funktioniert, werde ich einen commit im trunk
machen.
Gruß,
Falk
Hi Falk,
setzen der Timebaseeinstellung geht so:
timebase_reg = tb_value[Selected_Timebase];
Display_Timebase = Selected_Timebase + SIGNALFaktor_idx;
if (Selected_Timebase > 7)
{ adc_change12_reg |= 0x01000000; }
else
{ adc_change12_reg &= 0xFEFFFFFF; }
ändern der Anzeige geht so:
Display::StatusUpdate();
Wie sieht es denn jetzt mit der Aufteilung aus? Entwickelst Du schon
wieder? Oder teilst Du noch auf? Eine Info über den Stand der Dinge wäre
ganz hilfreich. Desweiteren, macht dann jemand ein neues Build mit
angepasstem Makefile und den neuen Sourcen, oder bleibt das jedem selbst
überlassen?
Hayo
Hayo W. schrieb:
> Hi Falk,>> setzen der Timebaseeinstellung geht so:>> timebase_reg = tb_value[Selected_Timebase];> Display_Timebase = Selected_Timebase + SIGNALFaktor_idx;>> if (Selected_Timebase > 7)> { adc_change12_reg |= 0x01000000; }> else> { adc_change12_reg &= 0xFEFFFFFF; }>> ändern der Anzeige geht so:>> Display::StatusUpdate();
Ok, werde ich mir mal ansehen.
> Wie sieht es denn jetzt mit der Aufteilung aus? Entwickelst Du schon> wieder? Oder teilst Du noch auf?
Ich hatte zunächst den Teil für die PC-Kommunikation in eine neue
Klasse/Datei verlagert.
Daran bastele ich auch gerade. (Und am GUI)
> Eine Info über den Stand der Dinge wäre> ganz hilfreich. Desweiteren, macht dann jemand ein neues Build mit> angepasstem Makefile und den neuen Sourcen, oder bleibt das jedem selbst> überlassen?
Ich werde meine Änderungen committen, sobald die Änderung der Timebase
funktioniert, damit auch andere Qt-Spezialisten einen Ansatz haben.
Dann werde ich weiter aufteilen. Dazu werde ich mit Sicherheit einige
Fragen haben. Bevor ich damit anfange, gebe ich Laut.
Falk
Hayo W. schrieb:
> Ok, hattest Du meinen Vorschlag von gestern zur Auslagerung des> Signalprocessing zur Kenntnis genommen?
Ja, damit könnte ich anfangen.
Falk
Übrigens, ich weiß nicht ob Du das bemerkt hast, es gibt zwei
Steuervariablen für die Timebase
- Selected_Timebase ist die führende Variable und läuft nicht linear
hoch, sondern macht Sprünge! Die Werte kann man meiner Timebasetabelle
entnehmen.
- Display_Timebase dient nur als Index bei Arrayzugriffen und Ähnlichem,
läuft aber linear hoch.
Wozu diese inhomogenität gut ist? Keine Ahnung! Da sollte man lieber
nicht allzulange drüber nachgrübeln. Das wollte ich beizeiten auch mal
vernünftig implementieren, ist allerdings recht aufwändig, da die
Variablen in diversen Berechnungen mit drinstecken.
Hayo
Hayo W. schrieb:
> Übrigens, ich weiß nicht ob Du das bemerkt hast, es gibt zwei> Steuervariablen für die Timebase>> - Selected_Timebase ist die führende Variable und läuft nicht linear> hoch, sondern macht Sprünge! Die Werte kann man meiner Timebasetabelle> entnehmen.
Danke für den Tip...
Jetzt tritt mir die langsame Verarbeitungsgeschwindigkeit des Teils auf
die Füße: Mal eben sechs Bytes mit 115200 Baud zu schicken, geht einfach
nicht. Dazu müßte diese Verarbeitung in der ISR stecken, und die wollte
ich nicht anfassen.
Ich werde aber wohl nicht drumherumkommen.
Jetzt probiere ich erstmal mit einem ACK, das das Scope nach jedem
empfangenen Zeichen nach Erkennung eines GUI-Kommandos sendet.
Jetzt weiß ich auch wieder, warum ich das GUI damals hingeschissen hatte
;-)
Keine Atempause, es geht voran,
Falk
Wolle schrieb:
>> GUI damals hingeschissen hatte>>> Wie sagte schon mein Opa:>> Was ist das wichtigste beim schweißen?? - das W!!!!
Naja, das war ein echter Freud'scher Verbrecher. Erst habe ich es
hingesch^Wzusammengestoppelt, dann hingeschmissen.
@Hayo:
Ich werde das doch über die ISR machen. Da wird ein kleiner
Kommandopuffer gefüllt und ein Flag gesetzt, wenn der richtig gefüllt
ist.
Die übrigen Funktionen wird das nicht beeinflussen.
Jetzt fange ich mal an, aufzuräumen. Alles im Trunk, mit Deinem
Vorschlag werde ich anfangen.
Falk
Ach ja, noch ein kleiner Nachschlag zum Setzen der Timebase, ich hatte
da noch was vergessen:
Setzen der Variablen:
timebase_reg = tb_value[Selected_Timebase];
Display_Timebase = Selected_Timebase + SIGNALFaktor_idx;
if (Selected_Timebase > 7)
{ adc_change12_reg |= 0x01000000; }
else
{ adc_change12_reg &= 0xFEFFFFFF; }
Neuberechnung der abhängigen Variablen:
Recalc_Vars();
config_changed = 1;
Setzen der Hardwareregister:
SetupADC();
Danach ist dann die neue Timebase angeschaltet. Du solltest aber
berücksichtigen das je nach aktuellen Einstellungen noch weitere
Konfigurationen nötig sind.
Zum Beispiel die automatische Aktivierung des USTB-Modus, bei
FFT-Betrieb, bei aktivierten Cursor.
Das findest Du alles im Timebasehandler ON_Timebase()
Am besten einfach nach der Umstellung den Timebasehandler aufrufen, dann
must Du das nicht neu programmieren.
Hayo
So, ich habe display_t.cpp mal aufgeteilt. Ich habe keine neue Klasse
angelegt, nur .cpp-Dateien und das Makefile entsprechend angepasst.
Ich habe versucht, das möglichst sinnvoll aufzuteilen. In den Fällen, in
denen das nicht passt, ist es aber kein Problem, die entsprechende
Funktion in die passendere Datei zu schieben.
Das Verzeichnis sieht jetzt so aus:
Falk Willberg schrieb:
> So, ich habe display_t.cpp mal aufgeteilt. Ich habe keine neue Klasse> angelegt, nur .cpp-Dateien und das Makefile entsprechend angepasst.>> Ich habe versucht, das möglichst sinnvoll aufzuteilen. In den Fällen, in> denen das nicht passt, ist es aber kein Problem, die entsprechende> Funktion in die passendere Datei zu schieben.
Ich weiß ja nicht so genau auf welcher Basis die Sachen entstanden sind,
aber das sieht mir so aus als wäre da eines meiner Builds die Vorlage
gewesen. Da waren aber einige Sachen drin die nicht hier in die Struktur
gehören.
> Das Verzeichnis sieht jetzt so aus:
Hayo W. schrieb:
> Falk Willberg schrieb:> Ich weiß ja nicht so genau auf welcher Basis die Sachen entstanden sind,> aber das sieht mir so aus als wäre da eines meiner Builds die Vorlage> gewesen. Da waren aber einige Sachen drin die nicht hier in die Struktur> gehören.>> Das Verzeichnis sieht jetzt so aus:>> src/floatprintf.cpp>> src/CALCPRETRIGGER.cpp>> src/RenderText.cpp>> src/display_t_bak.cpp>> src/display_t_bitop.cpp
Sind weg.
Dann werde ich man die UART-Sachen aus der hardware_t.cpp auslagern.
Falk
Ich würde es begrüßen, wenn auch der Nios-Compiler im SVN abgelegt
werden würde. Ich schffe es gerade leider nicht den von google groups zu
laden...
Es wäre dann möglich die ganze Buildumgebung aus dem Projektarchiv zu
beziehen.
Gruß
Sebastian
Sebastian B. schrieb:
> Ich würde es begrüßen, wenn auch der Nios-Compiler im SVN abgelegt> werden würde. Ich schffe es gerade leider nicht den von google groups zu> laden...
Sowas gehört in die Download-Sektion. Überhaupt sind glaube ich noch
einige sinnvolle Daten von GGroups zu "retten"...
Nimmst Du den!
Ist der aktuellste Build vor der Aufteilung. Wenn Du das SDK installiert
hast reicht ein "make all" und alles geht von selbst.
Kann meinetwegen auch ins SFN Repository falls das Sinn macht.
Hayo
Danke! Ich binn der Meinung, dass die Build-Umgebung genauso in die
Versionsverwaltung gehört, um auf einen definierten Stand umschalten zu
können. der Compiler könnte ja auch im laufe der Zeit geändert werden.
Sebastian
Die eigentliche Entwicklungsumgebung gibt es in unterschiedlichen
Varianten für die einzelnen Distributionen. Ich hab hier die
Suse-Version, ist aber etwas zu groß um es hier reinzustellen (10 MB).
Must also auf Google warten, da hab ich das auch alles reingestellt.
Hayo
@Sebastian
Sehe ich auch so. Es muß für Neueinsteiger möglichst leicht sein sich
das einzurichten und die ersten Schritte zu machen. So kriegen wir eine
größere Menge an Mitentwicklern und Interessierten.
Hayo
Daniel H. schrieb:
> Sebastian B. schrieb:>> Ich würde es begrüßen, wenn auch der Nios-Compiler im SVN abgelegt>> werden würde. Ich schffe es gerade leider nicht den von google groups zu>> laden...>> Sowas gehört in die Download-Sektion. Überhaupt sind glaube ich noch> einige sinnvolle Daten von GGroups zu "retten"...
Ich habe vorerst nicht vor, die Gruppe zu löschen. Nur als weitere
Diskussionsplattform war sie überzählig.
Falk
Hayo W. schrieb:
> Guido schrieb:>> @ Hayo: damit das hier nicht untergeht:>>>> [...]>> @rowue>>> Kommst Du aus HH?> Jupp!
Jarrestadt/Kampnagel ;)
>>> Dann könnten wir ggf. auch mal eine direkte Einführung in>> Subversion/Trac machen ;)>> Nettes Angebot. Ich wollte mir das jetzt mal in der Zwischenzeit zu> Gemüte führen. Ich hab gesehen, dass es auch eine KDE-Version gibt, die> wollte ich mal ausprobieren. Ansonsten komme ich gerne auf das Angebot> zurück.
Ack - ich persönliche bevorzuge RapidSVN/svnX (OS X), aber da hat jeder
seine Präferenz (http://subversion.tigris.org/links.html#clients hat
eine
nette Übersicht)
Wenn Du möchtest, setzte ich Dir 'nen Repository auf meiner Kiste auf.
Mit dem kannst Du dann "rumspielen" ohne auf SourceForge "Rücksicht
nehmen" zu müssen ;)
>> Hayo
Grüße,
schönen Urlaub,
rowue
Ich habe gerade eine Firmware und die erste Version des GUI committed,
mit der zumindest die Timebase verändert werden kann.
Freue mich über jede Kritik.
Damit sind meine größeren Änderungen vorläufig abgschlossen.
Jetzt werde ich ein wenig am GUI und an PCComms.cpp schrauben.
Falk
Für alle die noch kein Nios compiler haben, hab ich den Compiler (unter
Windows) als portable gepackt (cygwin + nios-gnupro + Hayo .86beta). Auf
rar file 25MB. Er kann auch direkt in einer USB-Stick laufen.
Weis jemand wo ich hochladen könnte ohne Registrierung?
Gruß, Ben
xCometz schrieb:
> Für alle die noch kein Nios compiler haben, hab ich den Compiler (unter> Windows) als portable gepackt (cygwin + nios-gnupro + Hayo .86beta).
Welche Variante von Hayos 0.86 ist das? Aus dem SVN oder eine ältere?
> Auf> rar file 25MB. Er kann auch direkt in einer USB-Stick laufen.>> Weis jemand wo ich hochladen könnte ohne Registrierung?
Ich weiß nicht, ob ich ausführbare Programm da herunterladen würde, wo
das ohne jede Registrierung hochzuladen geht...
Falk
xCometz schrieb:
> Für alle die noch kein Nios compiler haben, hab ich den Compiler (unter> Windows) als portable gepackt (cygwin + nios-gnupro + Hayo .86beta). Auf> rar file 25MB. Er kann auch direkt in einer USB-Stick laufen.>> Weis jemand wo ich hochladen könnte ohne Registrierung?>> Gruß, Ben
Das ist nicht übel, wäre was für meinen Urlaubsrechner! Wo Du allerdings
25MB so einfach hochladen kannst weiß ich auch nicht. Eine Registrierung
braucht man eigentlich immer. Notfalls könnte ich meinen Server
anwerfen, da könntest Du das dann draufspielen und ich reiche das dann
weiter.
Hayo
xCometz schrieb:
> Ja richtig, ich hab 2 mal hochgeladen falls ein error hätte.> Hat funktioniert?>> Ben
Hi Ben,
hat hervorragend funktioniert. Prima Beschreibung. Auspacken, zweimal
klicken, fertig. Echt super!
Man muß nur drauf achten das nicht in ein Verzeichnis mit Sonderzeichen
im Namen zu kopieren.
Danke
Hayo
Rolf Würdemann schrieb:
> Hi Falk, (@all)>> es wäre nett, wenn bei einer Release ein Compilat bei wäre ;)
Kein problem: make; gzip TomCat.flash; svn add TomCat.flash
"svn: This client is too old to work with working copy '.'; please get a
newer Subversion client"
Watt? Die Version des Versionshandlingtools passt nicht zur aktuellen
Version des Versionshandlingtools? Was eine %$&%@€&§$ !!
Während ich also die Sourcen hole und mir ein neues svn baue, verschicke
ich's mal im Anhang.
> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.
Geht hier. Seltsam. Im Moment sitze ich am Notebook mit i586 unter'm
Sonnenschirm, (dafür geht subversion nicht) aber auf dem Büro-PC ist
SuSE 11.0 x86_64 (AMD) installiert und da läuft das NIOS-CDK.
Gruß,
Falk
P.S.: Du kannst nicht zufällig QT ;-)
P.P.S.: Die Version für's RAM kann ich nicht kompilieren, da fehlt mir
das Makefile. Wenn Hayo wieder im Lande ist, kann er das ja mal
schicken.
die Makefile mit ram support steht weiter oben in diesem Thread
Autor: Günter Jung (gjung)
Datum: 16.05.2009 00:28
Dateianhang: Makefile.zip (3,9 KB, 52 Downloads)
eventuell geht auch:
http://www.mikrocontroller.net/attachment/50963/Makefile.zip
hat jetzt das angepasste Makefile, TomCat.flash.gz und TomCat.ram.gz.
Falk
P.S.: Falls es jemanden interessiert: Subversion lies sich nicht
übersetzen, weil es irgendeine Indianer-Lib (Apache Portable Runtime)
haben wollte.
Ein Tritt in den Allerwertesten (rm -rf FW1.2.BF.087beta; svn co ...; vi
Makefile; make; svn add ....; svn commit) hat subversion dazu gebracht,
ein commit zu machen.
Falk Willberg schrieb:
> P.S.: Falls es jemanden interessiert: Subversion lies sich nicht> übersetzen, weil es irgendeine Indianer-Lib (Apache Portable Runtime)> haben wollte.> Ein Tritt in den Allerwertesten (rm -rf FW1.2.BF.087beta; svn co ...; vi> Makefile; make; svn add ....; svn commit) hat subversion dazu gebracht,> ein commit zu machen.
Deine Meldung von oben deutet auf ein Downgrade deines SVN-Clients hin
oder zumindest auf das Vorhandensein mehrerer Versionen auf deinem
System. Ich würde mal eventuelle grafische Clients durchchecken, ob die
nicht in der Lage sind, den Standard-Client deines Systems zu verwenden
anstatt ihrer eigenen Executables.
Daniel H. schrieb:
...
"svn: This client is too old to work with working copy '.'"
> Deine Meldung von oben deutet auf ein Downgrade deines SVN-Clients hin> oder zumindest auf das Vorhandensein mehrerer Versionen auf deinem> System.
Ich habe zwei Systeme. Einen PC im Büro und ein Notebook im Garten.
Subversion-Versionen 1.4 und 1.5. (OpenSuSE 10.3 bzw. 11.0)
> Ich würde mal eventuelle grafische Clients durchchecken...
Ich mag die "Kommandozeile" lieber. Die Klickerei in GUIs ist nicht so
mein Ding.
Ich müßte nur SuSE 10.3 auf 11.0 updaten.
Falk
Hallo Falk,
ich habe mal ein paar Ideen zu den Sourcen der aktuellen FW
aufgeschrieben. Sieh es einfach als Anregungen und übernimm, was dir
sinnvoll erscheint....
- Ich nehme an, das die Aufteilung der Sourcen noch weiter betrieben
wird. Der Übersichtlichkeit halber würde ich *.cpp und *.h auf zwei
Verzeichnisse aufteilen. /inc und /src bieten sich an. Wenn man für die
Dateinamen der Scope-FW noch einen Prefix (z.B. ala 'TC_') einführt,
könnte eine übersichtliche Aufteilung z.B. wie in der angehängten Datei
dargestellt aussehen.
(/lib beinhaltet ja keine libraries und könnte daher auch aufgelöst
werden.)
- Die Versionsnummer in 'Screenshot_0.4' widerspricht dem Gedanke, der
hinter einem Versionsverwaltungssystem steht.
- Die History sowie die netten Orginalkommentare von Wittig Technologies
würde ich aus 'tc_vars.cpp' rausnehmen und z.B. in eine /changelog.txt
auslagern.
Wenn man das Verschieben bzw. Umbenennen in Verbindung mit Subversion
richtig macht, bleibt auch die Historie der Dateien erhalten. Falls ich
irgendwo aktiv werden soll, bitte Bescheid sagen.
Beste Grüße,
Odic
PS: Zu deinem Subversion-Problem: ich nehme an, dass du versuchst, ein
und die selbe working-copy mit unterschiedlichen Clients zu bearbeiten.
Da sind leider alle SVN-Clients die ich kenne nicht sonderlich
kompatibel in sich. Einfach auf beiden Systemen getrennt auschecken,
dann funktioniert es auch ohne ein Update.
@Falk: Ok, ich hatte irgendwie im Hinterkopf, dass du auf Windows
unterwegs bist. Da ist das gern mal etwas unübersichtlich mit SVN.
@Hayo: Bei der 0.85 ist mir aufgefallen, dass der Status im
A(c)quire-Menü nicht über einen Neustart des Systems hinweg gerettet
wird. Stellt man also z.B. auf Denoising, schaltet das Gerät aus und
wieder an, dann ist Denoising zwar aktiv (kann man schön an der leichten
Schräglage der Flanken das Comp-Signals sehen), aber im Menü ist Normal
mit einem Haken versehen. Man muss dann auch schon auf Averaging oder
Denoising und dann wieder auf Normal drücken, um wirklich auf Normal zu
kommen.
Falk Willberg schrieb:
> Rolf Würdemann schrieb:>>> Hi Falk, (@all)>>>> es wäre nett, wenn bei einer Release ein Compilat bei wäre ;)>> Kein problem: make; gzip TomCat.flash; svn add TomCat.flash> "svn: This client is too old to work with working copy '.'; please get a> newer Subversion client"> Watt? Die Version des Versionshandlingtools passt nicht zur aktuellen> Version des Versionshandlingtools? Was eine %$&%@€&§$ !!
Das reicht danach, als ob da einmal mit einer aktuelleren Version
ausgecheckt wurde. Sprich: entweder bearbeitest Du den gleichen
Check-Out von zwei Seiten aus, oder Du hattest einmal ein aktuelleres
Svn auf dem System (kenne ich z.B. von OS X (10.5) und MacPorts, wo
letzteres aktueller ist)
>> Während ich also die Sourcen hole und mir ein neues svn baue, verschicke> ich's mal im Anhang.>>> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.>> Geht hier. Seltsam. Im Moment sitze ich am Notebook mit i586 unter'm> Sonnenschirm, (dafür geht subversion nicht) aber auf dem Büro-PC ist> SuSE 11.0 x86_64 (AMD) installiert und da läuft das NIOS-CDK.
o.k. - dann versuche ich es mal mit "-f" ;)
>> Gruß,> Falk
Grüße,
rowue
> P.S.: Du kannst nicht zufällig QT ;-)
Ne (habe mal etwas unter perl mit gtk gespielt), aber a) kann ich es mir
mal ansehen und b) kenne ich Leute (http://qucs.sourceforge.net/) die
schon länger was mit Qt (3) machen (und die mensch mal fragen kann
wenn es Probleme gibt ;)
> P.P.S.: Die Version für's RAM kann ich nicht kompilieren, da fehlt mir> das Makefile. Wenn Hayo wieder im Lande ist, kann er das ja mal> schicken.
Rolf Würdemann schrieb:
> Falk Willberg schrieb:
...
>>> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.>>>> Geht hier.
...
> o.k. - dann versuche ich es mal mit "-f" ;)
Bei mir ist
1
cdk-nios-binutils-3.1-20040329
2
cdk-nios-libstdc++-3.1-20040329
3
cdk-nios-gcc-c++-3.1-20040329
4
cdk-nios-base-0.3-20031111
5
cdk-nios-libgloss-3.1-20040329
6
cdk-nios-newlib-3.1-20040329
7
cdk-nios-gcc-3.1-20040329
8
cdk-nios-related-tools-3.1-20040329
installiert. OpenSuSE 11.0 x86_64. Die NIOS-binaries sind aber für
32-Bit kompiliert.
Falk
Falk Willberg schrieb:
> Rolf Würdemann schrieb:>> Falk Willberg schrieb:>> ...>>>>> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.>>>>>> Geht hier.> ...>> o.k. - dann versuche ich es mal mit "-f" ;)>> Bei mir ist[c]cdk-nios-binutils-3.1-20040329> [...]
Das Problem lag zwischen den Ohren - ich hätte einfach
dpkg --force-architecture -i PACKET
aufrufen müssen - so hat er (natürlich) rumgenörgelt, dass
die Packete nicht zu meinem System (Debian Lenny) passen.
Installiert, compiliert sauber durch ;)
Evtl. 'nen kleinen Kommentar in's Readme für die Debian
Packete (dann stolpert kein anderer drüber ;)
Btw: Könntest Du die Änderung des Makefiles (für das
RAM Image) noch in den Trunk übernehmen? Dann braucht
beim nächsten Release keiner dran zu denken ;)
>> Falk
rowue
Rolf Würdemann schrieb:
> Falk Willberg schrieb:> Evtl. 'nen kleinen Kommentar in's Readme für die Debian> Packete (dann stolpert kein anderer drüber ;)
Nur zu ;-)
> Btw: Könntest Du die Änderung des Makefiles (für das> RAM Image) noch in den Trunk übernehmen? Dann braucht> beim nächsten Release keiner dran zu denken ;)
Erledigt. Dabei habe ich auch die angezeigt Version auf 0.87 gesetzt.
Dabei fällt mir ein, daß der Trunk ja mal eine 0.88 wird.
Falk
Odic X. schrieb:
> Hallo Falk,>> ich habe mal ein paar Ideen zu den Sourcen der aktuellen FW> aufgeschrieben. Sieh es einfach als Anregungen und übernimm, was dir> sinnvoll erscheint....
Danke für die Anregungen. Vorläufig beschäftige ich mich mit der
PC-Kommunikation, wenn Zeit ist.
> - Ich nehme an, das die Aufteilung der Sourcen noch weiter betrieben> wird. Der Übersichtlichkeit halber würde ich *.cpp und *.h auf zwei> Verzeichnisse aufteilen. /inc und /src bieten sich an. Wenn man für die> Dateinamen der Scope-FW noch einen Prefix (z.B. ala 'TC_') einführt,> könnte eine übersichtliche Aufteilung z.B. wie in der angehängten Datei> dargestellt aussehen.> (/lib beinhaltet ja keine libraries und könnte daher auch aufgelöst> werden.)> - Die Versionsnummer in 'Screenshot_0.4' widerspricht dem Gedanke, der> hinter einem Versionsverwaltungssystem steht.
Ich weiß. Ich meine aber, daß irgendwo ein Stand gespeichert werden
sollte, bei dem die PC-Clients mit der zugehörigen Firmware
zusammenspielen.
> - Die History sowie die netten Orginalkommentare von Wittig Technologies> würde ich aus 'tc_vars.cpp' rausnehmen und z.B. in eine /changelog.txt> auslagern.
Ok.
> Wenn man das Verschieben bzw. Umbenennen in Verbindung mit Subversion> richtig macht, bleibt auch die Historie der Dateien erhalten. Falls ich> irgendwo aktiv werden soll, bitte Bescheid sagen.
Bescheid ;-) Ich erhebe keinen Anspruch auf ein Monopol auf
Hausmeistertätigkeiten im Repository.
Ich hoffe nur, daß niemand größere Änderungen an veralteten Sourcen aus
irgendwelchen .zip-Files vornimmt.
Falk
Daniel H. schrieb:
> @Hayo: Bei der 0.85 ist mir aufgefallen, dass der Status im> A(c)quire-Menü nicht über einen Neustart des Systems hinweg gerettet> wird. Stellt man also z.B. auf Denoising, schaltet das Gerät aus und> wieder an, dann ist Denoising zwar aktiv (kann man schön an der leichten> Schräglage der Flanken das Comp-Signals sehen), aber im Menü ist Normal> mit einem Haken versehen. Man muss dann auch schon auf Averaging oder> Denoising und dann wieder auf Normal drücken, um wirklich auf Normal zu> kommen.
Passiert auch bei der 0.86. Die lag noch aufm Desktop herum, ganz
vergessen einzuspielen schäm
Odic X. schrieb:
> Hmmm.... was muss ich anstellen, um aufs Repository commiten zu können??> (SF-Account habe ich)
Theoretisch: einfach bei Deinem SVN-Client "commit" sagen (svn ci) und
Dir eine möglichst kurze und passende Beschreibung dessen, was Du getan
hast überlegen und diese eingeben.
Praktisch kann es aber sein, dass Du erstmal die Write-Permissions auf
das Repository brauchst ;)
Ansonsten gäbe es noch die Möglichkeit (wäre aber vorher zu
diskutieren), ob Du mit svn diff einen Diff erstellst und dieses an
ein Ticket im Trac hängst. So wird das z.B. bei MacPorts gemacht, wo
nicht alle Port-Maintainer auf das Repository committen können. (Die,
die es können, machen das dann direkt ;)
Grüße,
rowue
PS: Der Diff kann dann mit "patch" einfach eingefügt und von berufener
Seite committed werden ;)
Rolf Würdemann schrieb:
> Odic X. schrieb:>> Hmmm.... was muss ich anstellen, um aufs Repository commiten zu können??>> (SF-Account habe ich)
Mit dem subversion-Cli (Linux):
In das künftige Arbeitsverzeichnis wechseln,
> Theoretisch: einfach bei Deinem SVN-Client "commit" sagen (svn ci) und> Dir eine möglichst kurze und passende Beschreibung dessen, was Du getan> hast überlegen und diese eingeben.>> Praktisch kann es aber sein, dass Du erstmal die Write-Permissions auf> das Repository brauchst ;)
Hat die nicht jeder?
Ich fand http://svnbook.red-bean.com/nightly/de/index.html hilfreich.
Falk
Checkout ist anonym möglich, aber checkin nur mit SF.net Account und
Freischaltung der Schreibrechte. Wenn einer der Oberbastler grünes Licht
gibt (und ich den SF.net handle von Odic X. erfahre), kann ich das
entsprechend einrichten.
Entschuldigt, hab mich etwas unklar ausgedrückt...
Da SVN zu meinen täglichen Arbeitswerkzeugen gehört, ist die Bedienung
des Clients nicht das Problem. Vielmehr verweigert mir das Repository
den Zugriff, zumindest wenn ich mich mit meinem SF-Account zu
authentisieren versuche. Wer ist denn für die Vergabe der Zugriffsrechte
zuständig?
Beste Grüße,
odic
PS: Prinzipiell halte ich den Vorschlag von Rolf für eine sehr sinnvolle
Lösung. Allerdings würde ich so eine Einschränkung immer erst einführen,
wenn die Disziplin der beteiligten Entwickler nicht ausreicht oder es zu
Missbrauch kommt.
Wo m.E. allerdings die Rechte ganz eindeutig auf wenige Personen
begrenzt gehören, ist bei der Erstellung von tags.
Hallo allerseits,
war leider eine ganze Zeit nicht online, daher die Funkstille.
Allerdings war ich nicht untätig.
Ich bin mit der neuen Aufteilung von Falk nicht so recht glücklich, da
diese einerseits etwas unübersichtlich und andererseits nicht konsequent
genug ist. Also hab ich mich einige Stunden hingesetzt und hab das
nochmal neu aufgeteilt, und zwar nicht nur die Dateien, sondern auch auf
neue Klassen.
Basis ist die 0.86. Zusätzlich habe ich in der Tomcat.cpp die
Objektaufrufen in statische Aufrufe geändert.
Seht Euch das mal an und überlegt mal ob Ihr das so übernehmen wollt.
Gruß Hayo
Hayo W. schrieb:
> Hallo allerseits,
Hallo,
> war leider eine ganze Zeit nicht online, daher die Funkstille.> Allerdings war ich nicht untätig.>> Ich bin mit der neuen Aufteilung von Falk nicht so recht glücklich, da> diese einerseits etwas unübersichtlich und andererseits nicht konsequent> genug ist.
Mein Ziel war zunächst mal, diese riesigen Klötze von Dateien
aufzuteilen. Ich mag keine Dateien bearbeiten, die etliche tausend
Zeilen lang sind.
Ich kenne SVN noch nicht so gut, aber ich denke, daß es eine gute Idee
ist, wenn wir vermeiden können, daß mehrere Personen an der gleichen
Datei arbeiten.
> Also hab ich mich einige Stunden hingesetzt und hab das> nochmal neu aufgeteilt, und zwar nicht nur die Dateien, sondern auch auf> neue Klassen.
Die Aufteilung in Klassen ist gut!
> Basis ist die 0.86. Zusätzlich habe ich in der Tomcat.cpp die> Objektaufrufen in statische Aufrufe geändert.>> Seht Euch das mal an und überlegt mal ob Ihr das so übernehmen wollt.
Leider sind meine Änderungen da nicht drin. Wie willst Du das ins SVN
einpflegen?
Wir sollten uns darauf einigen, ob wir mit SVN arbeiten oder.... ja,
welche Alternative gibt es dazu? Lokale Kopien bearbeiten und ein
.zip-File veröffentlichen führt zu Durcheinander. Es ist schon
abzusehen...
Falk
Und vor allem sollten zwei Releases mit der selben Versionsnummer
vermieden werden, da diese immer ein-eindeutig sein sollten. Notfalls
lieber mit RCs oder weiteren Versionsnummern arbeiten....
Ich glaube ich warte mit dem Umbenennen und Verschieben von Dateien
noch, bis die gröbsten Aufteilungen feststehen.
Beste Grüße,
odic
Falk Willberg schrieb:
>> Leider sind meine Änderungen da nicht drin. Wie willst Du das ins SVN> einpflegen?>> Wir sollten uns darauf einigen, ob wir mit SVN arbeiten oder.... ja,> welche Alternative gibt es dazu? Lokale Kopien bearbeiten und ein> .zip-File veröffentlichen führt zu Durcheinander. Es ist schon> abzusehen...
Hi Falk, pfleg doch Deine Änderungen da manuell ein und übernimm es dann
ins SFN, dann ist doch alles paletti. Die eigentlichen Methoden haben
sich ja nicht geändert, sondern sind nur in anderen Klassen. Das ist
doch noch überschaubar.
Durch die neue Klassenstruktur ist das Coding auch besser lesbar, da die
Funktionalität besser zuzuordnen ist.
Gruß Hayo
Hayo W. schrieb:
> Falk Willberg schrieb:>>>>> Leider sind meine Änderungen da nicht drin. Wie willst Du das ins SVN>> einpflegen?>>>> Wir sollten uns darauf einigen, ob wir mit SVN arbeiten oder.... ja,>> welche Alternative gibt es dazu? Lokale Kopien bearbeiten und ein>> .zip-File veröffentlichen führt zu Durcheinander. Es ist schon>> abzusehen...>> Hi Falk, pfleg doch Deine Änderungen da manuell ein und übernimm es dann> ins SFN, dann ist doch alles paletti.
Bis hier die nächste Release als zip-file auftaucht.
Ich schlage vor, daß wir uns zunächst auf ein Werkzeug einigen, daß es
mehreren Leuten ermöglicht, gleichzeitig an den Sourcen zu arbeiten.
Ich bin für Subversion (SVN).
Wenn eine Alternative (die unter Linux nutzbar ist) bevorzugt wird, bin
ich gerne dabei.
Wenn wir uns geeinigt haben, kann jemand, der Subversion besser
beherrscht als ich, Deine Version mit dem aktuellen Release
zusammenführen und ggfs. in ein anderes Format überführen.
Falk
Bernd O. schrieb:
...
> Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt> ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der> Wert "1" gemerkt/übertragen.
...
> Das Bild, das übertragen wird, entspricht dann 1:1 dem auf dem Oszi> dargestellten Bild und die zu übertragende Datenmenge reduziert sich auf> ein Viertel, da nun pro Pixel (bei 16 Planes) statt bisher 16 Bits (1> pro Plane) nur noch vier Bits (2^4 == 16 Planes) übertragen werden> müssen.
Das habe ich eben ausprobiert: Farbiger Screenshot in 14s.
Ich habe allerdings auch die Memory-Planes weggelassen.
Mit diesem Verfahren können nur 14 Planes plus die Information, daß kein
Pixel in irgendeiner Plane gesetzt ist, übertragen werden.
Wie man sieht, muß noch an der Reihenfolge der Planes gearbeitet werden.
...
> Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben,> aber schnelle Screenshots sind noch schöner.
Sehe ich auch so.
Falk
Nabend ;)
Zur Versionsverwaltung kenne ich vier Systeme:
* cvs (Krampf im Gesäß)
* subversion
* git
* mercury
CVS ist das älteste System und an einigen Stellen etwas unfreundlich
zu bedienen. Subversion besticht durch seine einfache Bedienung und
eine hohe Anzahl von Clients, hat aber die Nachteile, dass immer zwei
Kopien des Checkouts auf der Platte sind (10MB Source-Code benötigen
also ca. 20MB Plattenplatz) und dass für Check-In's eine zentrale Stelle
definiert ist (lokale Platte oder zentraler Server).
git und mercury sind dezentrale Versionskontroll-Systeme, git wird
z.B. auch für den Linux-Kernel verwendet, bei Mercury soll der Übergang
von Subversion zu Mercury eher einfach ist.
Mein Voting wäre hier Subversion.
Zur der Frage der parallel bearbeiteten Dateien: Es ist möglich mittels
SVN auch Dateien gegen den schreibenden Zugriff zu sperren (svn lock,
svn unlock).
Wg. des Schreibzugriffs auf das Repository: diesen würde ich auch die
"Haupt-Entwickler" (+ggf einige "Helfer") beschränken. Dies mit dem
Hintergrund, dass diese auch die Auswirkungen kleinerer Patches (welche
von anderen Leuten eingebracht werden können) einschätzen können.
(Sprich: wenn jmd. sich besser mit dem Code auskennt, kann er auch
direkt schreiben, sonst über den Umweg des Diffs und eines Tickets)
Sonst könnte es irgendwann viel Spass bei der Fehlersuche geben.
Grüße,
rowue
PS: vielleicht schaffe ich die Tage den Append zum "ReadMe" ;)
Falk Willberg schrieb:
> Ich bin für Subversion (SVN).>> Wenn eine Alternative (die unter Linux nutzbar ist) bevorzugt wird, bin> ich gerne dabei.>> Wenn wir uns geeinigt haben, kann jemand, der Subversion besser> beherrscht als ich, Deine Version mit dem aktuellen Release> zusammenführen und ggfs. in ein anderes Format überführen.>> Falk
Hi, ja ich bin auch für SVN nach allem was ich bislang gehört habe. Da
ich mich aber jetzt erst einarbeite, möchte ich nur ungern an der
Struktur im SFN rumfuhrwerken, da wäre es mir lieber dass das jemand
macht der sich schon etwas auskennt. Ist denn die Struktur die ich
vorgeschlagen habe soweit in Ordnung oder gibt es noch Änderungswünsche?
Hayo
Rolf Würdemann schrieb:
> Zur der Frage der parallel bearbeiteten Dateien: Es ist möglich mittels> SVN auch Dateien gegen den schreibenden Zugriff zu sperren (svn lock,> svn unlock).
Meine Erfahrung zeigt dass das meistens nicht notwendig ist. Wenn
wirklich umfangreiche Änderungen anstehen, wie z.B. die aktuelle
Neuaufteilung des Codes, dann reicht es, sich zu koordinieren. Nur wenn
die Entwicklergruppe groß genug ist, dass nicht alle solche Absprachen
zeitnah entdecken, sollte man locken, es sei denn es betrifft wirklich
den kompletten Source und jegliche Änderungen anderer Leute wären
komplett sinnlos. Also lieber 3x überlegen ob man locked und vorallem
nur in Absprache, sonst sind die anderen recht schnell genervt ;)
Auch ohne Locks kann man mit mehreren Leuten problemlos in einer Datei
arbeiten. Solange die Edits sich nicht zeilenweise überschneiden, merged
SVN die Änderungen fehlerfrei (das erkennt man an einem G vor der Datei
beim Updaten). Überschneiden sich Änderungen (oder kommen sich so nahe,
als dass diff nicht mehr einwandfrei zuordnen könnte, wie alles
zusammenpasst), dann bekommt man einen Konflikt (C vor der Datei) und
drei Versionen der konfliktbehafteten Datei. Einmal die *.mine mit den
eigenen Änderungen, dann die *.r??? mit der Version aus dem Repository
und die eigentliche Datei, die Konfliktmarker enthält. Einfach so eine
Datei nach "<<<<<" oder ">>>>>" oder "=====" durchsuchen, wenn man mal
einen Konflikt hat, dann wird schnell klar wie das gemeint ist. Wenn man
die Datei dann manuell gemerged hat, einmal svn resolved auf der datei
aufrufen und dem Commit steht nix im Weg. Ist eigentlich total simpel
und hält (im Gegensatz zu Locks) niemanden von der Arbeit ab =)
Hallo zusammen,
ich sehe das Ganze ähnlich wie rowue. Subversion wäre optimal. Es gibt
viele Clients, für alle möglichen Betriebssysteme. So kommt sich niemand
ausgeschlossen vor. Außerdem gibt's viele Infos und HowTos dazu im Netz.
Damit sollte wirklich jeder zumindest einen Checkout hinbekommen.
Bzgl. der Menge an Schreibberechtigten wäre ich auch eher für einen
kleinen Kreis. Ich habe schon bei mehreren OpenSource Projekten Patches
eingereicht. Einige wurden akzeptiert, andere nicht (Nebenwirkungen,
nicht gut genug, etc.). Hatte nie ein Problem damit, meine Änderungen in
ein Diff zu packen, zu erklären und an ein Ticket anzuhängen.
Ich denke das hier einige "Gurus" - die genau wissen was sie tun und was
der Code im Detail macht - die Patches prüfen sollten, bevor zu viele
Leute schreibrechte haben und am Schluss jedes zweite Build in die Hose
geht.
Entscheiden müssen dass aber diejenigen die hier die Arbeit machen...
wofür ich an dieser Stelle auch mal Danke sagen möchte.
Gruß
Daniel
Hayo W. schrieb:
...
> Hi, ja ich bin auch für SVN nach allem was ich bislang gehört habe. Da> ich mich aber jetzt erst einarbeite, möchte ich nur ungern an der> Struktur im SFN rumfuhrwerken, da wäre es mir lieber dass das jemand> macht der sich schon etwas auskennt.
Nur Mut ;-) Ich habe Dir ein Repository eingerichtet, in dem Du Dich
unabhängig von SFN austoben kannst: http://falk-willberg.de/svn/repos/
Zugangsdaten zum Schreiben hast Du per Mail bekommen.
> Ist denn die Struktur die ich> vorgeschlagen habe soweit in Ordnung oder gibt es noch Änderungswünsche?
Wie gesagt, ich bin ein Freund kleiner Dateien...
Falk
Falk Willberg schrieb:
>> Wie gesagt, ich bin ein Freund kleiner Dateien...>
Da habe ich versucht zwischen Dateigröße und logischem Zusammenhang
einen Kompromiss zu finden. Dazu kommt, dass man sonst bei Entwicklungen
die in mehrere Bereiche fallen, so viele Datein gleichzeitig offen hat,
dass man da schnell den Überblick verliert. Thematisch fiel mir auch
weiter keine sinnvolle aufteilung mehr ein. Die größten Brocken sind
auch wie schon gehabt weiterhin die Displayklasse und die
Hardwareklasse. Die anderen Klassen würde ich eher als schlank
bezeichnen.
> Nur Mut ;-) Ich habe Dir ein Repository eingerichtet, in dem Du Dich> unabhängig von SFN austoben kannst: http://falk-willberg.de/svn/repos/
Das ist eine gute Idee, da kann ich mal ausprobieren obs richtig
hinhaut. Es ist auch eher weniger eine Mutfrage als vielmehr eine
Zeitfrage.
Ich denke ich werde mal mit KDE-SVN meine ersten Versuche starten.
Obwohl ich als Urgestein hier mit der Kommandozeile groß geworden bin,
habe ich doch die GUI-Bedienung schätzen gelernt (den guten alten Atari
Mega ST hab ich noch!).
Die Lochkarten fristen bei mir mittlerweile ein Dasein als Lesezeichen
und Kommandozeilenarien gehören, wenn möglich, auch der Vergangenheit
an, bin halt bequem geworden ;-)
Gruß Hayo
Hayo,
nur als Anmerkung und Tipp,
wenn es Klassen wie "Display" gibt, die einfach zu groß sind.
Dann wäre es vielleicht überlegenswert das mit Unterklassen und einem
Unterverzeichnis aufzuteilen.
Hallo zusammen
nachdem heute mein Scope endlich angekommen ist habe ich erstmal eine
Weile mit der originalen 1.4er Firmware gespielt und dann zum Vergleich
eure 0.86 beta geladen.
Ein großes Kompliment und ein noch größeres Dankeschön an die
Entwicklergemeinde! Ohne eure Arbeit hätte ich das Ding auf jeden Fall
zurückgeschickt - schon allein aufgrund des schrecklichen DAC Abgleichs,
der mehrere Divs danebengehaut hat. So ist es für das Geld schon jetzt
ein wirklich nettes Gerät und wenn ihr so weiter macht kann es sich
sogar noch mit etablierten Marken messen. Klasse!
Ich hoffe, dass ich in Zukunft in irgendeiner Form etwas zur Entwicklung
beitragen kann.
Viele Grüße
Michael
Hallo,
ein paar Kleinigkeiten habe ich schon für die lange Liste:
- wenn ich einen Screenshot mache (klappt super, tolle Sache!) ist
danach immer QickMeasure eingeschaltet auch wenn es vorher aus war
- wenn ich bei QuickMeasure Duty Cycle wähle, steht die Schrift bei
Select und Measure über die Buttons raus
- wenn man einen Kanal wählt und dort den Teilerfaktor des Tastkopfes
wählt leuchtet nicht mehr wie in der Original Firmware die LED beim
Drehknopf
Sagt mir bitte gleich wenn ich euch mit solchen Lappalien nerve,
ansonsten poste ich halt alles was mir so auffällt...
Gruß
Michael
Hallo zusammen,
ich hab gerade mal auf SF nachgesehen, dort ist der Bug-Tracker aktuell
deaktiviert. Würde es nicht Sinn ergeben, diesen zu aktivieren, damit es
eine zentrale Sammlung der aktuell offenen Probleme gibt? Hier im Forum
wird es sonst wohl schnell unübersichtlich.
Im übrigen überlege ich gerade, ob eine Art Auto-Updater für die Scopes
interessant wäre. Das Programm könnte alle verfügbaren Firmware-Dateien
aus dem Internet ziehen und per Mausklick im Ram oder Flash einspielen.
Ich würde das Ganze in C# schreiben. Dann wäre es über mono auch
multi-plattform.
Besteht Bedarf/Interesse an einem solchen Tool. Oder kann ich mich
anders nützlich machen?
Gruß
Daniel
@Michael
Testberichte und Fehlermeldungen sind völlig ok und erwünscht,
allerdings sollten wir tatsächlich bei dem jetzt entstandenen Umfang der
ganzen Sache überlegen wie wir solche Meldungen zentral erfassen
(Tickets etc.).
@Daniel
Hört sich echt gut an. Da sind mit Sicherheit auch die Anderen dran
interessiert.
Gruß Hayo
Hallo schon wieder,
ist schon jemandem aufgefallen, dass der "Denoise" Modus nicht mit
QuickMeasure kompatibel ist?
Wenn ich (Kanal 1, 500mV/div, 500us/div) das Kompensationsrechtecksignal
darstelle, kriege ich teilweise am rechten Bildschirmrand eine komische
Linie, die so gar nicht stimmen kann - siehe Screenshot.
Mit dem Screenshot habe ich auch Probleme wie ihr sehen könnt, auf dem
Scope sah das jedenfalls nicht so aus: der Ausreißer sollte am rechten
Bildschirmrand sein usw. Hat jemand eine Idee was da los ist? Vorhin
waren die Shots noch ok, das einzige was ich geändert habe ist die
Horizontalposition.
Gruß,
Michael
So, ich habe den Ordner des Screenshot Tools gelöscht und nochmal neu
entpackt und jetzt funktioniert es wieder. Der korrekte Screenshot zum
beschriebenen Fehler ist im Anhang.
Keine Sorge, heute werde ich euch nicht weiter in Anspruch nehmen und
morgen bin ich mit zwei Prüfungen gut beschäftigt :)
Gruß
Michael
Nabend ;)
anbei das Diff für das Readme zum NIOS zum Reinpatchen in den
trunk und committen ;)
Oder soll ich dies als Ticket im Trac eintüten? (Zumindest bekomme
ich nach dem Login auf dem SF trac mit der Ticket-Maske angezeigt)
Vorschlag bzgl. der informationskanalisierung:
Anregungen/Bug-Reports: Trac-Tickets
Allg./Spezielle Infos: Trac-Wiki
Bei der Verwendung von Trac-Tickets können wir dies sehr gut
einem Komponenten (nios-firmware?) und Meilensteinen zuordnen ;)
(Trac und SVN spielen sehr gut miteinander - incl. Verweisen in der
Commit-Message auf ein entsprechendes Ticket und vis-versa ;)
Grüße,
rowue
PS: Könnte der Committer das Keyword "Id" auf das File setzen?
guten abend,
wollte euch mal loben, ihr macht echt gute arbeit! ohne euch hät ich das
oszi wieder zurück geschickt! ich denk ihr seid eine große hilfe für
viele leute!
ich hab mir auch gleich mal die BlueFlash_Build_0_86 firmware drauf
getan. als ich die das screenshot(0.3) programm testen wollte(hab
übrigens windows), hat es nie wirklich geklappt.
ich öffne ganz normal das prog, drücke im oszi auf save to csv (oder
auch pgm, pgm bw) dann läd es auch die daten runter, aber wenn ich mir
dann die bilder anschaue, kommt entweder nur ein komplett schwarzes bild
oder ein schwarzer hintergrund mit grauen linien bzw balken. was mach
ich falsch?
hoff ihr hab die lösung für mich ;-)
großes dankeschön an euch!
Amazz schrieb:
> guten abend,> wollte euch mal loben, ihr macht echt gute arbeit! ohne euch hät ich das> oszi wieder zurück geschickt! ich denk ihr seid eine große hilfe für> viele leute!>> ich hab mir auch gleich mal die BlueFlash_Build_0_86 firmware drauf> getan. als ich die das screenshot(0.3) programm testen wollte(hab> übrigens windows), hat es nie wirklich geklappt.
Die Firmware-Version muß zum Screenshot-Tool passen.
Am besten ist es, die tags aus Sourceforge zu nehmen:
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios
Falk
Falk Willberg schrieb:
> Bernd O. schrieb:> ...>> Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt>> ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der>> Wert "1" gemerkt/übertragen.>> ...>>> Das Bild, das übertragen wird, entspricht dann 1:1 dem auf dem Oszi>> dargestellten Bild und die zu übertragende Datenmenge reduziert sich auf>> ein Viertel, da nun pro Pixel (bei 16 Planes) statt bisher 16 Bits (1>> pro Plane) nur noch vier Bits (2^4 == 16 Planes) übertragen werden>> müssen.>> Das habe ich eben ausprobiert: Farbiger Screenshot in 14s.> Ich habe allerdings auch die Memory-Planes weggelassen.
Faktor 2 - nicht schlecht!
> Mit diesem Verfahren können nur 14 Planes plus die Information, daß kein> Pixel in irgendeiner Plane gesetzt ist, übertragen werden.
Eigentlich müssten es 15 Planes + "leer" sein, da mit den 2^4 Bits ja 16
Zustände dargestellt werden können, also beispielsweise 0 = "leer", 1 =
Plane_1, 2=Plane_2, ... 15=Plane_15.
Ich hab' mir die bisher implementierte RLE nicht angesehen, aber wenn
man der "sagt", dass die Symbole nun 4 Bits breit sind anstatt wie
früher 1 Bit oder sie gar selbst nach der optimalen Symbollänge suchen
muß (was aber wohl aufgrund der begrenzten Rechenleistung nicht der Fall
sein dürfte), dann ist hier noch einiges an Potential drin.
Wenn beispielsweise 20 Pixel der Plane 1 hintereinander kommen und Plane
1 den Wert 1, also binär 0001 hat, dann wird die RLE mit Symbollänge 4
Bits erkennen, dass 20x 0b0001 übertragen werden soll und optimalerweise
nicht viel mehr als die Anzahl, also 20 und den Wert, also "1"
übertragen, macht (geschätzte) 2-3 Bytes. Wenn die RLE von 1 Bit
ausgeht, wird so etwas wie 3 x "0", 1 x "1", 3 x "0", 1 x "1", 3 x "0"
übertragen - und mit diesen (geschätzten) 6 Bytes sind erst die ersten
drei der 20 Pixel aus dem Beispiel übertragen.
Vielleicht lässt sich so die 10-Sekunden-Marke noch knacken?
Gruß,
Bernd
Bernd O. schrieb:
...
>> Mit diesem Verfahren können nur 14 Planes plus die Information, daß kein>> Pixel in irgendeiner Plane gesetzt ist, übertragen werden.> Eigentlich müssten es 15 Planes + "leer" sein, da mit den 2^4 Bits ja 16> Zustände dargestellt werden können, also beispielsweise 0 = "leer", 1 => Plane_1, 2=Plane_2, ... 15=Plane_15.
Stimmt....
> Ich hab' mir die bisher implementierte RLE nicht angesehen, aber wenn> man der "sagt", dass die Symbole nun 4 Bits breit sind anstatt wie> früher 1 Bit oder sie gar selbst nach der optimalen Symbollänge suchen> muß (was aber wohl aufgrund der begrenzten Rechenleistung nicht der Fall> sein dürfte), dann ist hier noch einiges an Potential drin.
Die Rechenleistung ist das Problem.
[Vorschlag]
> Vielleicht lässt sich so die 10-Sekunden-Marke noch knacken?
Ich habe gerade die Version committed. Sieh Dir das doch mal an,
vielleicht sind meine Kommentare ja verständlich ;-)
Leider kämpfe ich noch mit einem seltsamen HW-Problem bei meinem Scope,
deswegen kann ich im Moment nichts testen.
Falk
Daniel G. schrieb:
> ich hab gerade mal auf SF nachgesehen, dort ist der Bug-Tracker aktuell> deaktiviert. Würde es nicht Sinn ergeben, diesen zu aktivieren, damit es> eine zentrale Sammlung der aktuell offenen Probleme gibt? Hier im Forum> wird es sonst wohl schnell unübersichtlich.
Wie rowue erwähnte, bitte die Ticket-Funktion vom Trac verwenden!
Edit: Kann in der 0.87 keine Tomcat.flash finden... =(
Daniel H. schrieb:
> Daniel G. schrieb:>> ich hab gerade mal auf SF nachgesehen, dort ist der Bug-Tracker aktuell>> deaktiviert. Würde es nicht Sinn ergeben, diesen zu aktivieren, damit es>> eine zentrale Sammlung der aktuell offenen Probleme gibt? Hier im Forum>> wird es sonst wohl schnell unübersichtlich.>> Wie rowue erwähnte, bitte die Ticket-Funktion vom Trac verwenden!>> Edit: Kann in der 0.87 keine Tomcat.flash finden... =(https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/FW1.2.BF.087beta/TomCat.flash.gz
Was erlaube komprimieren die Flash ;-)
Daniel H. schrieb:
> Daniel G. schrieb:>> ich hab gerade mal auf SF nachgesehen, dort ist der Bug-Tracker aktuell>> deaktiviert. Würde es nicht Sinn ergeben, diesen zu aktivieren, damit es>> eine zentrale Sammlung der aktuell offenen Probleme gibt? Hier im Forum>> wird es sonst wohl schnell unübersichtlich.>> Wie rowue erwähnte, bitte die Ticket-Funktion vom Trac verwenden!
Bitte vorher
* diese Firmware als "Component" anlegen
* entsprechende Versionsnummern (für Bugs) anlegen
* entsprechende Milestones (für Planungen) anlegen
Das kann nur jmd. der entsprechende (Admin-) Rechte beim Trac hat, wir
sollten das aber jetzt machen, sonst gibt das irgendwann Probleme mit
dem FPGA-Design resp. anderen Teilprojekten ;)
>> Edit: Kann in der 0.87 keine Tomcat.flash finden... =(
Daniel H. schrieb:
> Wie rowue erwähnte, bitte die Ticket-Funktion vom Trac verwenden!>> Edit: Kann in der 0.87 keine Tomcat.flash finden... =(
Alles klar, danke für den Hinweis. Das hatte ich überlesen.
Die 0.87 enthält (fast) keine funktionalen Veränderungen, sondern war
nur als Vorschlag für eine neue Source-Struktur gedacht. Daher auch
keine .flash files.
Natürlich kann man sie in der Cygwin-Umgebung oder unter Linux CDK
compilieren. Für Cygwin kann ich übrigens die Version von Ben empfehlen
die er freundlicherweise bei einem Freehoster zur Verfügung gestellt hat
(siehe weiter oben). Läuft bei mir problemlos auf dem USB-Stick. Cygwin
mag allerdings keine Ordner mit Space im Namen.
Die nächsten Versionen werde ich aber wieder wie gewohnt als
Komplettpaket zur Verfügung stellen, damit sich nicht immer alle die
Einzelteile zusammensammeln müssen.
@Michael
> Wenn ich (Kanal 1, 500mV/div, 500us/div) das Kompensations-> Rechtecksignal darstelle, kriege ich teilweise am rechten> Bildschirmrand eine komische Linie, die so gar nicht> stimmen kann - siehe Screenshot.
Danke für den Tip. Da stimmt wohl die Berechnungslänge nicht ganz. Ist
in Arbeit!
Hayo
Ach ja, noch einer,
wenn ich das richtig mitbekommen habe, dann hat sich das
Screenshotprogramm geändert. Kann jemand ein aktuelles Windows-exe
kompilieren und zur Verfügung stellen?
Hayo
Hallo Hayo,
Anbei aktuelles Kompilat fuer Win32 fuer das Screenshot-Programm,
ungetestet.
(BTW: Ich bin noch da, hab' aber ein paar Privatprojekte angenommen/
angefangen ;))
Ich muss mal schauen ob ich die naechsten Tage einen Nightly-Build
(wie ich das schonmal angedeutet habe) eingerichtet bekomme.
Niklas
Hayo W. schrieb:
...
> Die nächsten Versionen werde ich aber wieder wie gewohnt als> Komplettpaket zur Verfügung stellen,
Auf welcher Basis wird die entstehen? Werden die Änderungen an den
Screenshot-Routinen enthalten sein?
Entschuldige, daß ich so mit Subversion nerve, aber das sich
abzeichnende Sammelsurium an Quellen will mir einfach nicht gefallen:
- SVN,
- hiesige ZIP-files,
- ein SDK inclusive Sourcen mir unbekannter Herkunft...
> damit sich nicht immer alle die Einzelteile zusammensammeln müssen.
Muß jetzt schon niemand:
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/
Falk
Falk Willberg schrieb:
> Auf welcher Basis wird die entstehen? Werden die Änderungen an den> Screenshot-Routinen enthalten sein?
Die habe ich gerade eben mal mit in meine Sourcen eingepflegt, da ich
aber gerade in der Firma bin kann ich nur kompilieren aber nicht testen.
> Entschuldige, daß ich so mit Subversion nerve, aber das sich> abzeichnende Sammelsurium an Quellen will mir einfach nicht gefallen:> - SVN,> - hiesige ZIP-files,
Ich kann die Sourcen sonst auch weglassen, da sie ja eine andere
Aufteilung haben.
> - ein SDK inclusive Sourcen mir unbekannter Herkunft...
Ich vermute Du meinst das Cygwin-Paket von Ben.
Die Sourcen dieses SDKs sind nur als Template zu sehen und sollten
entsprechend ausgetauscht werden. Enenso wie das Makefile angepasst
werden muß. Aber das SDK funktioniert wirklich gut.
>> damit sich nicht immer alle die Einzelteile zusammensammeln müssen.>> Muß jetzt schon niemand:> https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/> https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/
Die Links kannte ich noch nicht.
- Sind die auch über die SFN-Page erreichbar?
- Wer kompiliert denn die FW-Pakete und wann bei welchem Zwischenstand?
- Wenn die FW nicht von mir kompiliert wurde ist es vieleicht besser
statt des BF in der Bezeichnung die des Kompilierers zu verwenden.
Also in diesem Fall vermutlich 1.2.FW.0.87, dann läßt sich die Herkunft
besser zuordnen.
Hayo
Also ich sehe hier überhaupt nicht mehr durch.........
Meine Bitte:
wenn ihr das entflochten habt, dann
a) gebt hier bitte die richtigen Links bekannt und
b) kennzeichnet alles alte bitte als ungültig/unbenutzbar/obsolet oder
was auch immer
Aber ich denke auch, diese Umstrukturierung musste irgendwann mal sein..
LG, egberto
Hayo W. schrieb:
> Falk Willberg schrieb:
...
>> Entschuldige, daß ich so mit Subversion nerve, aber das sich>> abzeichnende Sammelsurium an Quellen will mir einfach nicht gefallen:>> - SVN,>> - hiesige ZIP-files,>> Ich kann die Sourcen sonst auch weglassen, da sie ja eine andere> Aufteilung haben.
Das halte ich für eine gute Idee...
>> - ein SDK inclusive Sourcen mir unbekannter Herkunft...>> Ich vermute Du meinst das Cygwin-Paket von Ben.
Genau.
> Die Sourcen dieses SDKs sind nur als Template zu sehen und sollten> entsprechend ausgetauscht werden.
Ich hoffe, das beherzigen alle...
>>> damit sich nicht immer alle die Einzelteile zusammensammeln müssen.>>>> Muß jetzt schon niemand:>> https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/>> https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/>> Die Links kannte ich noch nicht.> - Sind die auch über die SFN-Page erreichbar?> - Wer kompiliert denn die FW-Pakete und wann bei welchem Zwischenstand?
Wer auch immer ins repository schreiben darf.
> - Wenn die FW nicht von mir kompiliert wurde ist es vieleicht besser> statt des BF in der Bezeichnung die des Kompilierers zu verwenden.
Na, ich nehme doch nicht einfach den Namen desjenigen heraus, der mit
Abstand am meisten beigetragen hat.
> Also in diesem Fall vermutlich 1.2.FW.0.87, dann läßt sich die Herkunft> besser zuordnen.
Die Herkunft ist da immer aus Sourceforge. Wer's kompiliert hat, ist
ja egal. Ich schlage den Namen FW-W20xxA-1.2-XX vor. Die Release ergibt
sich ja aus Subversion.
> Hayo
Gruß,
Falk
Hallo,
bei Gelegenheit wäre es gut, wenn jemand das mit den Tickets kurz
erläutern könnte. Ich möchte jedenfalls gern gefundene Fehler melden
bzw. Vorschläge einbringen, hatte aber noch nie Kontakt mit euren
Entwicklungshilfen und dementsprechend keine Ahnung wie das läuft.
Gruß
Michael
Hallo,
ich lese ja regelmäßig diesen Thread und wundere mich, daß ihr die
langen response Zeiten hier auf eure Posts nicht langsam satt habt?!
Ich kann euch, den aktiven 4-5 FW Entwicklern, wirklich nur empfehlen
sich sich auf dem kurzen Weg via skype oder einen ähnlichen Dienst
auszutauschen. Auf dem HW und dem VHDL Sektor läuft das, mit inzwischen
bis zu 8 Leuten, absolut problem- und vor allem verzugslos!
gruß, brunowe
Hallo Michael,
> bei Gelegenheit wäre es gut, wenn jemand das mit den Tickets kurz> erläutern könnte. Ich möchte jedenfalls gern gefundene Fehler melden> bzw. Vorschläge einbringen, hatte aber noch nie Kontakt mit euren> Entwicklungshilfen und dementsprechend keine Ahnung wie das läuft.
ist egtl. ziemlich einfach und funktioniert auch ohne Sourceforge
Account. Da fuer unser Welec Projekt der Bug-Tracker leider
noch deaktiviert ist kann ich Dir das leider nur anhand eines
anderen Projekts zeigen.
Wenn Du auf einer Projektseite den Reiter "Develop" anklickst erscheinen
nun weitere Reiter daneben. Wenn das Bug-Tracking System aktiviert
ist gibt es einen Reiter "Tracker". Wenn Du mit der Maus drueber
"hoverst" erscheint ein Menue mit verschiedenen Optionen, u.a.
Bugs, Feature Requests und Search. Klickt man z.B. Bugs an, koennte
das so aussehen:
http://sourceforge.net/tracker/?group_id=145591&atid=762476
Mit "Add new" (oben unter Summary bei mir) kannst Du einen neuen Bug
eintragen. Es gibt ein Feld Summary und ein Feld Description und man
kann noch ein paar weitere Optionen auswaehlen sowie Dateien anhaengen.
Nicht viel anders als hier im Forum.
Auf Seite der Admins und Developer koennen die Bugs einem Developer
zugewiesen und Stati geaendert werden (ueblicherweise sind das "Open",
"Closed", "Nofix", "Duplicate" usw., egtl. selbsterklaerend). So kannst
Du dann auch sehen was mit Deinem Bug passiert. Zudem koennen andere
Nutzer (oder auch Devels) Kommentare hinzufuegen, wenn bei denen z.B.
das Problem nicht reproduzierbar ist oder noch weitere Informationen
benoetigt werden. Vergleichbar mit einem Forumsthread.
Schau Dich einfach mal ein wenig um unter der URL oben.
Niklas
Bruno We schrieb:
> Hallo,>> ich lese ja regelmäßig diesen Thread und wundere mich, daß ihr die> langen response Zeiten hier auf eure Posts nicht langsam satt habt?!> Ich kann euch, den aktiven 4-5 FW Entwicklern, wirklich nur empfehlen> sich sich auf dem kurzen Weg via skype oder einen ähnlichen Dienst> auszutauschen.
Den Gedanken hatte ich auch schon.
Ich lausche jetzt mal auf irc.freenode.org:6667, Kanal #welec.
Wenn jemand eine andere Idee hat....
Falk
Habe heute einen "Bug" bei der 0.85 gefunden.
Drückt man, während das Oszi im Roll-Mode ist (z.B. Zeitbasis 1sec.),
auf >>Autoscale<<, dann schlägt das jedesmal schief. Offenbar wird hier
der Rollmode nicht wieder deaktiviert.
Deaktiviert man den Rollmode vorher (z.B. Zeitbasis 200ms) geht's dann
wieder problemlos.
Gruß,
Michael
Niklas O. schrieb:
> Da fuer unser Welec Projekt der Bug-Tracker leider> noch deaktiviert ist kann ich Dir das leider nur anhand eines> anderen Projekts zeigen.
Ich hätte schwören können, dass ich die Tage schonmal geschrieben habe:
Bitte benutzt die Ticket-Funktion vom Trac. Die ist viel besser mit dem
Trac-Codebrowser, dem Wiki, der Timeline, der Roadmap und eigentlich
allem anderen integriert.
Hallo Daniel,
sorry, ich merke erst gerade das Trac was ganz anderes ist als
die Standard-Oberflaeche und verstehe nun erst richtig was Du
und rowue meinen...
(Falls ich nicht der einzige bin der zu daemlich ist
das richtige Ticketsystem zu finden:
http://sourceforge.net/apps/trac/welecw2000a/report )
Koennt ihr das so schalten das man neue Eintraege ins
Trac-Ticketsystem auch als unangemeldeter User bei SF
erstellen kann?
Abgesehen davon: bitte Kurzbeschreibung wie wir Tickets
mit SVN verbinden sollen.
Niklas
Niklas O. schrieb:
> Koennt ihr das so schalten das man neue Eintraege ins> Trac-Ticketsystem auch als unangemeldeter User bei SF> erstellen kann?
Also prinzipiell geht das natürlich, aber zwei Punkte sprechen für eine
(sehr einfache, schmerzfreie) Registrierung (man bekommt auch keinen
Spam von SF.net oder so, sind ja keine bösen Jungs):
1) Spam wird vermieden und
2) Man kann mit den Ticket-Erstellern kommunizieren.
Punkt 2 ist unmöglich, wenn alle Leute ihre Tickets anonym posten...
> Abgesehen davon: bitte Kurzbeschreibung wie wir Tickets> mit SVN verbinden sollen.
Ich empfehle die Lektüre von
https://sourceforge.net/apps/trac/welecw2000a/wiki/TracGuide
Da steht eigentlich alles drin, was man über Trac wissen muss.
Prinzipiell greifen z.B. in Commit-Nachrichten viele der
Wiki-Formatierungen von Trac, so auch die Referenzierung von Tickets
(mittels #Ticketnummer). Umgekehrt kann man im Trac-Wiki und in Tickets
(und überall anders) mit "rNUMMER" Revisionen referenzieren, die dann
direkt zum Code Browser verlinkt werden usw. Siehe auch unter
https://sourceforge.net/apps/trac/welecw2000a/wiki/WikiFormatting
(Abschnitt Trac Links)
Hallo Daniel,
kann es sein, dass die Möglichkeit, Bugs etc über Tickets einzutragen
momentan deaktiviert ist?
"Error - The Tracker has been disabled for this group"
Gruß,
Michael
Michael H. schrieb:
> Hallo Daniel,> kann es sein, dass die Möglichkeit, Bugs etc über Tickets einzutragen> momentan deaktiviert ist?>> "Error - The Tracker has been disabled for this group">> Gruß,> Michael
Das ist der SF.net tracker. Der ist deaktiviert, weil doch das Trac
verwendet werden soll. Die SF.net Apps sind alle ziemlich schlecht.
https://sourceforge.net/apps/trac/welecw2000a/newtickethttps://sourceforge.net/apps/trac/welecw2000a/report
Guten Morgen.
Ok das mit den Tickets verstehe ich jetzt soweit, denke ich.
Wer war denn nochmal der Screenshot-Guru?
Da keine Reaktion kam, wurde mein Post oben vielleicht übersehen?
Das klappt ja eigentlich sehr gut aber wenn man die Horizontalposition
verstellt, fliegt alles durcheinander - hier nochmal ein Shot dazu. Es
ist dann ziemlich schwierig, das wieder zurückzudrehen und natürlich
wäre es schön, wenn man in jeder Position Screenshots machen könnte.
Gruß,
Michael
Michael H. schrieb:
> Guten Morgen.> Ok das mit den Tickets verstehe ich jetzt soweit, denke ich.> Wer war denn nochmal der Screenshot-Guru?
Der Niklas ;-)
> Da keine Reaktion kam, wurde mein Post oben vielleicht übersehen?
Leider kann ich gerade nichts ausprobieren :-(
Falk
Hallo,
ich habe gerade ein wenig mit den Messfunktionen gespielt und hätte eine
Frage.
Wenn man ein Rechtecksignal vermisst wird bei RMS schön ein Vielfaches
der Periode betrachtet, bei Average allerdings immer X,5 Perioden, also
hinten noch eine halbe dran. Da sich das Ergebnis auch deutlich von
meinem anderen Oszi unterscheidet nehme ich an, dass das ein Bug ist?
Alle anderen bisher getesteten Messfunktionen liefern tadellose
Ergebnisse - wenn ich mich richtig entsinne, muss man einen Stefan dafür
loben? Wer auch immer: gut gemacht!
Gruß,
Michael
Nabend ;)
a) Anbei noch mal der diff mit der Bitte zum Reinpatchen in den
Trunk ;)
b) Zum Thema trac:
i) bitte die Tickets in Englisch abfassen - dann können das auch
Leute lesen, die nicht deutsch sprechen ;)
ii) Es wäre sehr hilfreich, wenn jmd. mit "Admin"-Rechten im Trac
entsprechende Bezeichnungen für "Component", "Version" und ggf.
Milestone (vorher absprechen?) einrichtet - sonst wird es
irgendwann etwas unübersichtlich ;)
Grüße,
rowue
Rolf Würdemann schrieb:
> ii) Es wäre sehr hilfreich, wenn jmd. mit "Admin"-Rechten im Trac> entsprechende Bezeichnungen für "Component", "Version" und ggf.> Milestone (vorher absprechen?) einrichtet - sonst wird es> irgendwann etwas unübersichtlich ;)
Für Vorschläge bin ich ganz Ohr -- oder fühlt sich jemand zum
Ticket-Admin berufen? =)
Hallo Hayo,
ich hätte einen Punkt für die Wishlist:
Eine Kombination aus Roll und Shiftmode.
Das Ganze läuft wie folgt ab: Am Anfang wird der Bildschirm von links
her mit neuen Daten beschrieben, also genau so, wie aktuell der Rollmode
am Welec auch funktioniert. Ist der Bildschirm komplett gefüllt, dann
wechselt das Ganze in einen Shiftmode und die neuen Daten werden von
rechts her in das Display geschoben. Bei Tek heißt eben diese
Kombination gerade Rollmode. :)
Beste Grüße, branadic (der sein TDS5104B immer mehr zu schätzen lernt)
Hallo,
ich bin ja immer noch dabei, nach und nach alles am neuen Oszi
durchzuprobieren.
Heute habe ich mal die I2C Kommunikation eines Bastelprojektes
betrachtet und dabei festgestellt, dass es noch ein paar Probleme mit
dem Trigger gibt.
Der stand auf normal und ich habe ein wenig an der Zeitbasis gedreht
während SDA dargestellt wurde. Dabei kam es immer wieder vor, dass der
Trigger nicht mehr reagierte, erst nach zweimal Run/Stop drücken lief
die Sache wieder. Komischerweise passiert es nicht immer, aber doch
recht oft, wie gesagt immer beim Wechseln der Zeitbasis. Achja, wenn man
nochmal weiter an der Zeitbasis dreht, reagiert der Trigger teilweise
auch wieder.
2V/div, Kanal 4, Acquire=Normal waren meine Einstellungen falls es
jemand nachstellen möchte.
Irgendwie ist es hier erschreckend still geworden...hoffentlich ändert
sich das wieder. Naja, liegt wohl an der ganzen Umstellerei.
Gruß,
Michael
Daniel H. schrieb:
> Rolf Würdemann schrieb:>> ii) Es wäre sehr hilfreich, wenn jmd. mit "Admin"-Rechten im Trac>> entsprechende Bezeichnungen für "Component", "Version" und ggf.>> Milestone (vorher absprechen?) einrichtet - sonst wird es>> irgendwann etwas unübersichtlich ;)>> Für Vorschläge bin ich ganz Ohr -- oder fühlt sich jemand zum> Ticket-Admin berufen? =)
Ach, ich bin ganz froh, wenn das jmd. anderes macht ;) - Zu viele
Projekte verderben den Brei ;)
Vorschläge:
Component:
firmware-nios
pc-screenshot
Version:
ab 0.80Beta die veröffentlichten Versionen.
Am besten bei/kurz nach der Veröffentlichung.
Milestone:
1.0
(1.1 / oder 2.0)
alternativ: schöne Codenamen für die
"endgültigen" (nicht Beta) Releases ;)
Guten Abend/Morgen,
mir ist heute eine seltsame Geschichte beim Messen von einem Signal
aufgefallen. Ich hab dieses Problem dann anhand eines
2MHz-Rechtecksignales nachgestellt und möchte davon berichten, weil ich
nicht weiß, ob das bekannt ist und vielleicht ein weiterer Hinweis zu
den berühmten Schwingungen ist.
Gemessen wurde mit dem Tastkopf 10:1 und weiterhin ist BW für eine
bessere Beurteilung des Unterschiedes angeschaltet.
Aufgenommen habe ich (siehe Bild oben links) ein 2MHz Rechtecksignal mit
1GS/s bei 100ns/div.
Danach habe ich dann auf 2µs/div gestellt, Stopp gedrückt, auf 100ns
zurück gestellt und eine erneute Messung durchgeführt. Dabei bleibt die
Samplerate von 500MS/s bei 100ns/div erhalten. Bis hierhin nicht
unbedingt verwunderlich. Nun habe ich aber das 2MHz-Rechtecksignal
erneut aufgenommen, mit besagten 500MS/s (siehe Bild oben rechts).
Was auffällt: Der Trigger triggert statt von steigender plötzlich auf
fallende Flanke und man erkennt auf einmal seltsame Schwingungen, die da
nicht hingehören.
Ist das einfach nur ein Problem in der Ausgabereihenfolge der Daten oder
steckt hier ein Indiz für ein Problem im Downsampler/FPGA allgemein?
Beste Grüße, branadic
Vielleicht noch ein kleiner Nachtrag. Ich habe die Daten zur besseren
Analyse im CSV-Format abgespeichert, es ist aber zu spät, als dass ich
noch die Ursache für diese Problematik finde.
Eine geringere Samplerate bei gleicher Timebase sollte eigentlich eine
Tiefpasswirkung haben, eigentlich.
Bei Interesse für eine genauere Analyse stelle ich die Daten auch gern
zur Verfügung. Hab sie mir mal mit Octave angeschaut.
Dabei ist mir auch ins Gesicht gestochen, dass nur ein Bruchteil der
tatsächlich im Datenspeicher befindlichen Daten auf dem Bildschirm
angezeigt wird.
Vielleicht doch eine Möglichkeit der DPO-Implementierung? :)
Grüße und gute Nacht, branadic
Hallo Zusammen,
auch auf die Gefahr hin, dass das hier ein Monolog wird, ich habe heute
noch mal ein wenig mit den exportierten CSV-Dateien der gestern
gezeigten Bilder gespielt. Dabei ist mir noch etwas aufgefallen.
Zunächst einmal ein Bild der komplett gespeicherten Daten, die im
Samplespeicher liegen, einmal mit 1GS/s aufgezeichnet und einmal mit
500MS/s.
Geht man nun her und lässt sich die ersten 250 Samples beider
Aufzeichnungen plotten, dann sieht man ein Schwingen innerhalb der
ersten 25 Samples.
Kann sich das jemand erklären? Ist doch auch irgendwie seltsam oder?
Gruß, branadic
branadic schrieb:
> Geht man nun her und lässt sich die ersten 250 Samples beider> Aufzeichnungen plotten, dann sieht man ein Schwingen innerhalb der> ersten 25 Samples.> Kann sich das jemand erklären? Ist doch auch irgendwie seltsam oder?>> Gruß, branadic
Sieht mir aus wie das "Zerrissene-Flanke-Phänomen", das wir hier
schonmal diskutiert haben. Sind wir da eigentlich auf eine Ursache
gestoßen?
Wenn man sich die Bilder genau anschaut, dann sieht man im unteren Bild,
also mit 500MS/s, dass sich dieses Schwingen nach einer Weile
wiederholt, nämlich auf der Flanke. Dort ist es jedoch eine Überlagerung
zusammen mit der fallenden Flanke.
Kann das mal irgend jemand nachstellen, um herauszufinden ob das nur bei
mir so ist? Vielleicht ist dieser Effekt auch Hardware-Version abhängig?
Gruß, branadic
Hallo.
Ich habe mich noch ein wenig mit der Screenshot Problematik beschäftigt:
die einzige Möglichkeit, wieder einen sauberen Screenshot zu erhalten,
nachdem man etwas verstellt hat, scheint zu sein den Ordner des
Screenshot Programmes zu löschen und neu aus dem beta Archiv zu
entpacken. Dabei ist das seltsame, dass ich keine Datei entdecke, die
sich von den jungfräulichen aus dem Archiv unterscheidet - versteht das
jemand?
Gruß,
Michael
Hallo branadic,
das sieht doch wieder nach einem Schwingen des Eingangsverstärkers
aus. Ich habe dem letzten Videoverstärker ja 2 mal 22 Ohm
nachgesetzt, damit wurde es besser aber das Problem nicht gelöst.
Ich wollte noch einen abschlusswiderstand an die A/D-Wandler
setzen, das ist bei mir aber in Vergessenheit geraten, weil dann
das Phänomen der Schwebung auftrat, das ja auch noch nicht geklärt
ist.
Ich fürchte, dass wir hier nicht ein Problem haben, sondern
mehrere zusammenkommen.
Gru0, Guido
Hallo Guido,
durchaus möglich, dass die Schwinger tatsächlich schon vor den ADC
anliegen und Bruno sie seinerzeit nur nicht messen konnte.
Ich hab jetzt mal ein 3kHz Sinussignal mit BW und 500MS/s aufgezeichnet.
Interessant ist, dass auch hier zumindest der erste Schwinger innerhalb
der ersten 25 Samples wieder auftaucht.
Ich werde noch weitere Signalformen testen, vielleicht findet sich ein
Zusammenhang. Das bringt uns letztlich wieder darauf zurück, dass man
das Ausgangssignal der Eingangsstufe noch einmal genauer untersuchen
sollte.
Klar ist, dass bei einem Rechtecksignal natürlich recht hohe Frequenzen
auftreten. Vielleicht liegt hier wirklich das Problem.
Gruß, branadic
Hallo branadic, Guido,
Ich glaube nicht dass es sich da um ein Schwingen in analogen teil des
DSO handelt. (sonst waehre das Schwingen auch bei 1Gs sichtbar).
Vielmehr vermute ich ein Problem im FPGA code (Zum Beispiel eine falsche
phasenlage der 4 PLL's).
branadic: Hast du den effekt auf allen kanaelen?
Und tritt das immer auf oder nur in einer speziellen sequenz?
Ich kann leider das Problem erst Montags nach stellen.
Martin
Hallo Martin,
meine Befürchtung ist halt, dass mehrere Fehler vorhanden sind.
Das Schwingen ist im Eingang ganz sicher da. Ich habe das im
Hardware-Thread schon mit Bildern gezeigt. Du findest das dort,
wenn du nach "22 ohm" suchst.
Gruß, Guido
So, schon wieder ich.
Es scheint ganz egal zu sein, was ich für ein Signal anlege, in den
ersten 25 Samples stecken immer diese Schwinger drin.
Jedoch zeigt sich, dass scheinbar wirklich nur bei Rechtecksignalen
diese Schwinger dann immer wieder an den Flanken auftreten.
Das macht aber für mich keinen richtigen Sinn, denn angenommen es ist
wirklich die Eingangsstufe, woher kommt dann der erste Schwinger, egal
welches Signal ich anlege? Denn der sieht bei Rechtecksignalen an den
Flanken von der Form her genauso aus. Da ist guter Rat teuer. Jemand
eine Idee?
Gruß, branadic
Hallo Martin,
ja, das Problem taucht so auf allen Kanälen auf. Und richtig, bei 1GS/s
scheint es diese Effekte, bis auf diesen seltsamen Schwinger innerhalb
der ersten 25 Samples, nicht zu geben. Damit liegt der Verdacht nahe,
dass es nicht die Eingangsstufe sein kann und es sich um ein Problem ab
dem ADC handeln muss.
Gruß, branadic
Naja vllt. kommt der Dezimator im FPGA mit starken Amplitudenhüben (und
damit natürlich mit hohen Frequenzen) nicht klar. Bei Dreieck bzw.
Sinussignal sind die übergänge von einem zum nächsten Sample ja eher
gering. Außer natürlich am Anfang wenn das erste Sample kommt. Ich weiß
nicht wie genau der Dezimator im FPGA läuft, ob dieser ständig läuft
oder bei jedem Speicher befüllen neu initialisiert wird. Jedoch könnte
ich mir durchaus dort den Fehler vorstellen. Vllt sollte man mal
nachschauen ob bei Rechtecksignalen mit minimalem Spannungshub auch die
beobachteten Schwingung auftauchen. Just my 2 cent...
Gruß
Sebastian
Um das Problem weiter einzugrenzen:
Mit 200ns/div lässt sich ein Signal mit 250MS/s, 500MS/s und 1GS/s
wunderbar aufzeichnen. Das hab ich im obigen Bild mal gemacht und die
ersten 1000 Samples geplottet. Man möchte eigentlich annehmen, dass das
Rauschen kleiner werden sollte, also das Signal immer glatter. Dem ist
aber offensichtlich nicht so.
Man erkennt aber eindeutig einen systematischen Fehler bei 500MS/s und
noch besser bei 250MS/s im Bild.
Ganz nebenbei ist mir aufgefallen, dass mit der Screenshot0.4.exe leider
nur Kanal 1 als CSV ausgegeben wird. Das Drucken in eine Bilddatei
funktioniert dagegen bei mir bisher tadellos für alle Kanäle. Vielleicht
kann man dieses Manko in der Screenshot0.5 beseitigen?
Beste Grüße, branadic
Ich denke mal etwas laut...
Kann es sein, dass uns hier ein digitales Filter im FPGA o.ä. zum
Nachteil wird? Falls ja, bestünde die Möglichkeit dieses abzuschalten?
Gruß, branadic
Hallo branadic,
Also meiner Meinung nach ist da nur die Reihenfolge der Samples von den
4 AD-Convertern vertauscht! (siehe
http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument)
Wenn ich richtig zaehle sind das immer 25 zacken alle 100 Messwerte
(1/4).
Martin
Nein Martin, dem stimme ich so nicht zu.
Ich denke und hoffe, dass bei 250MS/s nur noch ein ADC aktiv ist und
dann dürfte das nicht so auftauchen.
Beste Grüße, branadic
Hallo branadic,
suche mal im Hardwarethread nach Schwebung. Damit müsstest du
meine damalige Tomcat.ram finden, mit der nur ein Wandler
ausgewertet wird. Screenshot ging damals halt noch nicht, aber
du kannst vergleichen.
Gruß, Guido
Hallo Guido,
ich hab dein RAM-File jetzt mal reingeladen. Was ich mich gerade frage,
bei 500MS/s laufen da noch zwei ADC oder sind das noch vier? Woran
erkenne ich, welche ADC wirklich arbeitet? Muss ich dir da einfach blind
vertrauen?
Bei 250MS/s, sicher dass da nur noch ein ADC arbeitet? Wenn ich mir das
so anschaue, dann scheint da auch irgendein Quark zu passieren. Ich
versuch das mal irgendwie festzuhalten, damit jeder sehen kann, was ich
meine.
Ein wenig schade, dass sich in Moment so wenige Leute beteiligen.
Beste Grüße, branadic
So, ich hab mal zwei Video's gemacht, damit man sehen kann, worauf ich
hinaus will.
Das Signal ist wieder mein 2MHz-Sinus, im ersten Video hab ich mehrfach
Singleshot gedrückt, ich zweiten dann eine kurze, kontinuierliche
Aufnahme. Diese Effekte der Treppchenbildung kommt mir etwas seltsam
vor. Zumal sie mal auftaucht und mal nicht.
Wie wäre es, um dem Problem mal genauer auf die Schliche zu kommen, wenn
man in die Firmware die Reihenfolge der ADC-Werte in einem Untermenu
verstellen könnte, meinetwegen auch via RS232 einstellbar? Nur damit ein
für alle mal geklärt wäre, ob die ADC-Reihenfolge vertauscht ist oder
nicht.
Irgendwie fehlt es in der Beta an Umstellmöglichkeiten, um den Problemen
besser auf die Schliche kommen zu können.
Gruß, branadic
Hier mal noch ein paar Bilder verschiedener Aufnahmezeitpunkte mit
250MS/s.
Unterstellt man den Bildern mit Treppenstufe eine falsche
ADC-Reihenfolge und vertauscht immer zwei Samples, dann würde das Signal
stimmen.
Welcher Effekt könnte jedoch dafür sorgen, dass die Sample-Reihenfolge
mal stimmt und mal nicht?
Gruß, branadic
Hm. Clockjitter?
Was könnte denn sonst noch dazu führen, dass sich das ständig
gegeneinander verschiebt?
Übrigens finde ich dein Engagement hier Klasse - Hayos Arbeit hat für
jeden unmittelbaren Nutzen aber deine "Grundlagenforschung" wird das
Welec vielleicht noch auf ein ganz anderes Niveau heben.
Gruß,
Michael
Hey Guido,
wäre es dir möglich auf Basis der aktuellen FW-Version noch einmal eine
Sonderversion zu schreiben, bei der man absolut sicher sein kann, dass
bei 250MS/s auch wirklich nur ein ADC läuft und bei 500MS/s nur zwei?
Warum?
Ganz einfach, auf dem Bildschirm sehe ich nur einen Bruchteil der
Samples einer Periode, alle Aussagen die ich treffe sind also eher
spekulativer Natur. Wenn man die Daten nun aber exportieren könnte (CSV)
und dann komplett analysieren würde, dann ließe sich vielleicht eher ein
Zusammenhang erkennen.
Wenn es deine Zeit also hergeben würde, dann wäre es großartig eine
solche Sonderversion mal zu testen.
Beste Grüße, branadic
Hallo Michael,
danke für die Blumen, aber hier sei mal erwähnt, dass erst die Arbeiten
an der Screenshot-Funktion und damit der Export der Daten dazu geführt
haben, dass man nun die Daten auf Plausibilität hin untersuchen kann.
Denn wie schon erwähnt, was auf dem Bildschirm angezeigt wird ist das
Eine, was tatsächlich noch an Samples zwischen zwei Angezeigten
vorhanden ist und wie die aussehen ist uns bislang ja verborgen
geblieben.
Daher muss an dieser Stelle das Lob an die entsprechenden Leute geleitet
werden, ohne die diese Untersuchungen überhaupt erst möglich werden.
Beste Grüße, branadic
sorry...
Daher muss an dieser Stelle das Lob an die entsprechenden Leute geleitet
werden, DURCH die diese Untersuchungen überhaupt erst möglich werden.
Beste Grüße, branadic
Ach Mist du hattest dich ja extra auf einen ADC beschränkt, da fällt es
allerdings schwer, sich eine Ursache für einen eventuellen Sampledreher
zu denken der nicht permanent auftritt.
Hallo branadic,
zur alten .ram: Da wird unabhängug vom Sampling immer 4 mal
hintereinander der Wert des 1. ADC auf dem Schirm abgebildet.
Allerdings nur in den schnellen Bereichen.
Mit der neuen Firmware will ich das schon noch machen, bin
aber bei der schnellen Entwicklung in letzter Zeit kaum noch
mit dem Downloaden nachgekommen :-(. Es wir etwas mehr Arbeit,
ich schau mal, wann ich dazu komme. Jetzt sehe ich mir erst mal
deine Aufnahmen an.
Gruß, Guido
Ah branadic,
jetzt sehe ich, dass du in den langsamen Bereichen misst. Da
habe ich mich noch garnicht darum gekümmert und habe keine
Ahnung wieviele ADCs jeweils verwendet werden. Ich probiere mal
das rauszufinden und eine Testversion zu kompilieren. Vor
heute Abend werde ich aber nicht dazu kommen.
Gruß, Guido
Und nochmal ich:
@ branadic: In diesen Bereichen solltest du das eigentlich auch mit
der aktuellen Beta sehen können. Nach meiner Vermutung samplen da
alle 4 ADCs. Die Daten werden dann umgeschaufelt, so dass nur die
Werte von ADC0 angezeigt werden. Das ergibt 4 kBytes. Wenn per
Screenshot 16 kBytes übertragen werden, findest du die Daten von
ADC1 im 2. 4-kB-Block, die von ADC2 im 3. und die von ADC3 im
vierten Block.
Das ist bei einer Timebase kleiner 5 µs/div so. In den schnelleren
Bereichen geht es mit meiner alten .ram. Ich probiere es heute abend
mit der Aktualisierung.
Hey Guido,
mein Wunsch wäre im Prinzip eine (Sonder-)Firmware auf Basis der
aktuelle FW mit folgenden Funktionen:
- umschaltbare Samplingrate in den verschiedenen Zeitbasen, wobei
wirklich nur echte Samples angezeigt werden sollten und nicht ein und
dasselbe Sample mehrfach
- verstellbare ADC-Reihenfolge, wobei hier geklärt/untersucht werden
müsste, ob die Samples auch wirklich vom korrekten ADC kommen
- die Möglichkeit bei 250MS/s, wo ja nur ein ADC laufen sollte, zwischen
einem der vier ADC manuell wählen zu können, dessen Daten zur Anzeige
kommen sollen
- die Möglichkeit bei 500MS/s, wo ja zwei ADC laufen sollten, zwischen
zwei der vier ADC manuell wählen zu können, deren Daten zur Anzeige
kommen sollen. Vielleicht werden hier ja momentan die falschen ADC
verwendet?
Wie gesagt, dass alles auf der aktuellen FW-Basis um die Daten
exportieren und analysieren zu können. Nur dann kann man wirklich echte
Aussagen zu den tatsächlichen Samples treffen. Was auf dem TFT angezeigt
wird ist dann noch mal eine ganz andere Geschichte. Solange aber schon
Müll im Speicher liegt, brauchen wir nicht neue Funktionen
implementieren und verbessern.
Die Devise lautet also, erst einmal an der Wurzel zu schauen, bevor wir
dem Bäumchen Blätter verpassen :)
Beste Grüße, branadic
@ Guido,
also wenn ich mir die CSV anschaue, dann sehe ich wie du sagst vier
Blöcke, jedoch mit jeweils 16k und nicht 4k.
Vielleicht kann uns Niklas mal sagen, in welcher Reihenfolge da was
exportiert wird?
Gruß, branadic
branadic schrieb:
> @ Guido,>> also wenn ich mir die CSV anschaue, dann sehe ich wie du sagst vier> Blöcke, jedoch mit jeweils 16k und nicht 4k.> Vielleicht kann uns Niklas mal sagen, in welcher Reihenfolge da was> exportiert wird?
Ganz einfach: Es wird der Datenbuffer von 0 aufsteigend ausgelesen:
1
for(idx=0;idx<16384;idx++){
2
putchar(SIGNAL1[idx]);
3
putchar(SIGNAL2[idx]);
4
putchar(SIGNAL3[idx]);
5
putchar(SIGNAL4[idx]);}
Könnte es sein, daß die N ADC nicht in der Reihenfolge 1-2-3-4
schreiben, sondern 4-3-2-1 oder sowas?
Falk
P.S.: Ich nehme mir jetzt mal die Aufteilung der Sourcen von Hayo vor
und sehe mal, wie ich das in SVN eingebaut bekomme. Und wenn dann
nächste Woche mein Scope wieder da ist, kann es weitergehen....
Hallo branadic,
das wird unendlich kompliziert, ist aber doch auf dem PC mit den
gesendeten Daten leicht zu realisieren.
Schau mal in Hayos Programming-Maps: bis 250 MS/s werden immer alle
vier ADCs verwendet, nur bei der Anzeige auf dem Dispaly werden
Werte übersprungen ("Faktor"), wodurch die SamplingTiefe immer
kleiner wird. Die Anordnung der Daten im Speicher ist dann:
ADC0, ADC1, ADC2, ADC3, ADC0 ..., und so müsste sie doch die
Screenshotfunktion auch senden, oder? Dann kannst du die
Daten ja auf dem PC nach Belieben umsortieren, filtern, ...
Ab 25 MS/s werden die Daten aller vier ADCs gesampled und dann
umgeschaufelt, wie oben beschrieben.
Gruß, Guido
Hallo Falk,
also ist es tatsächlich so, dass ich die Daten in der Form:
Kanal 1; Kanal 2; Kanal 3; Kanal 4;
Kanal 1; Kanal 2; Kanal 3; Kanal 4;
Kanal 1; Kanal 2; Kanal 3; Kanal 4;
Kanal 1; Kanal 2; Kanal 3; Kanal 4;
sehe?
Je nach Samplerate sind das dann die Daten von:
--> 1GS/s
Reihe 1: ADC0
Reihe 2: ADC1
Reihe 3: ADC2
Reihe 4: ADC3
--> 500MS/s (hier wäre zu prüfen ob das wirklich so ist!!!)
Reihe 1: ADC0
Reihe 2: ADC2
bzw.
Reihe 1: ADC1
Reihe 2: ADC3
--> 250MS/s (hier wäre zu prüfen ob das wirklich so ist!!!)
Reihe 1: ADC0 oder ADC1 oder ADC2 oder ADC3
Ist das so korrekt?
Gruß, branadic
Hey Guido,
pass auf, ich stelle mal meine CSV-Daten zur Verfügung, dann kann jeder
nach Belieben damit herumexperimentieren, wir haben aber alle die
gleiche Ausgangssituation.
Schaue ich mir die Daten an, dann ist kein systematisches Vertauschen
erkennbar, denn dann müssten immer vier Werte eine Systematik bilden!
Aber schaut doch einfach mal selbst.
Beste Grüße, branadic
@ Falk
Ich glaube es müssen immer 8 Byte auf einmal weggeschrieben werden, da
der FPGA <8ns Zugriffzeit hat. D.h. es gibt mehr als 4 Möglichkeiten bei
einem Dreher in der Reihenfolge.
Jürgen
Hallo branadic,
ich glaube nicht dass es so korrekt ist. Die Kanalzuordnung
stimmt aber es müssten im CSV auch bei 500 MS/s und 250 MS/s
alle vier ADCs abwechselnd sein. Wie kommst du auf die Idee,
dass da ADCs abgeschaltet sind, steht das irgendwo?
Ja, stell mal Daten ein und schreib dazu wie du die
visualisierst.
Gruß, Guido
Hey Guido,
siehe meinen Beitrag oben, da sind die Daten mit den drei verschiedenen
Sampleraten.
Ich importiere die Daten in Octave/Matlab und plotte sie mir dann
einfach. Meinetwegen die ersten 1000 Samples oder so.
Beim Import erhalte ich eine 16384x1 Matrix. In dieser steht dann immer
der erste Wert einer jeden Zeile.
Octave ignoriert bei mir alle Werte die nach dem ";" kommen. Daher wäre
ein Export mit "Komma" statt "Semicolon" wohl korrekter.
Immerhin heißt es ja Comma-Separated Values und nicht
Semicolon-Separated Values. ;)
Gruß, branadic
Ganz einfach Guido, schau dir die drei Dateien an. Du wirst feststellen,
dass vier Blöcke à 16k vorhanden sind.
Plottest du nun den ersten Block mit den drei unterschiedlichen
Sampleraten, dann wirst du feststellen, dass du bei 250MS/s x
Signalperioden hast, bei 500MS/s sind es 2*x Signalperioden und bei
1GS/s sind es 4*x Signalperioden.
Es können also unmöglich die Werte aller vier ADC sein.
Gruß, branadic
Ganz einfach Guido, schau dir die drei Dateien an. Du wirst feststellen,
dass vier Blöcke à 16k vorhanden sind.
Plottest du nun den ersten Block mit den drei unterschiedlichen
Sampleraten, dann wirst du feststellen, dass du bei 250MS/s x
Signalperioden hast, bei 500MS/s sind es 2*x Signalperioden und bei
1GS/s sind es 4*x Signalperioden.
Es können also unmöglich immer die Werte aller vier ADC sein, egal
welche Samplerate ich einstelle.
Gruß, branadic
Wenn ich mir die 250MSa/s und 500MSa/s Daten ansehe, dann ist ja
auffällig, dass die Ausreißer eine Periode von 8 Samples haben. Das kann
ich mir mit einem einfachen Vertauschen von Samples eigentlich nicht
erklären aber bis jetzt kann ich leider auch noch kein vernünftiges
Muster erkennen.
Es sieht so aus, als würden von 8 Samples jeweils drei saftig
danebenliegen. An der steigenden Flanke sind es immer 2 Ausreißer nach
oben, einer nach unten, an der fallenden Flanke sieht es genau andersrum
aus, also 2 nach unten und einer nach oben. Das kann man auch so sehen:
vier Samples passen, von den nächsten vieren hauen drei daneben, die
nächsten vier passen wieder.
Sieht jemand ein Muster, dessen Ursache man sich erklären könnte?
Gruß,
Michael
Mir ist gerade noch eine Idee gekommen. Ob und wie sie sich umsetzen
lässt ist mal ein anderer Punkt.
Angenommen man zeichnet mit Kanal 1 ein Signal mit 1GS/s im
Singleshot-Modus auf und speichert diese Daten im Speicher. Nun nimmt
man die Daten und tut so, als hätte man diese Daten auf Kanal 2 mit
500MS/s aufgezeichnet und speichert die Daten entsprechend im Speicher
für Kanal 2. Dann führt man das gleiche für 250MS/s ebenfalls durch und
speichert die Daten auf Kanal 3.
Das hätte den Vorteil, dass man genau schauen könnte, was mit den Daten
im FPGA/ in der FW passiert, weil sich die Daten direkt miteinander
vergleichen ließen.
Wäre soetwas realisierbar? Selbst wenn das mit einigem Aufwand verbunden
wäre, so ließen sich daraus doch sehr wertvolle Erkenntnisse gewinnen
und die Ursache für die seltsamen Werte extrahieren.
Meinungen von den FW-Experten sind gefragt.
Beste Grüße, branadic (der sich schon wie ein Monolog führender Epiker
vorkommt :D )
Guido schrieb:
> ich glaube nicht dass es so korrekt ist. Die Kanalzuordnung> stimmt aber es müssten im CSV auch bei 500 MS/s und 250 MS/s> alle vier ADCs abwechselnd sein. Wie kommst du auf die Idee,> dass da ADCs abgeschaltet sind, steht das irgendwo?
Um das Sampling äquidistant zu halten, muss es so sein wie André sagt.
Bei 1GSa/s sind die Samples in der Reihenfolge:
1-2-3-4-1-2-3-4-,
bei 500MSa/s in:
1---3---1---3---
und bei 250MSa/s:
1-------1-------
Zusätzlich zu diesem 1, 2, 4-Downsampler gibts noch eine zweite
Downsampling-Stage, die die Teilungen 1, 10, 100, 1000... ermöglicht,
indem sie den Output des ersten Downsamplers als Input verwendet.
Alles in allem sollte bei allen sampling rates <250MSa/s nur noch ein
ADC aktiv sein.
So, ich möchte noch ein wenig mehr zu Verwirrung beitragen.
Ich hatte ja oben meine CSV-Daten zur Verfügung gestellt. Plottet man
bei 1GS/s jeden 16. Wert, bei 500MS/s jeden 8. Wert und bei 250MS/s
jeden 4. Wert, dann sehen sich die drei Kurven sehr ähnlich, um nicht zu
sagen sie passen sauber überein.
Führt man den gleichen Plot nun mit jedem 8. Wert vom 1GS-Signal, jeden
4. Wert vom 500MS-Signal und jeden 2. Wert vom 250MS-Signal durch, dann
bekommt man wieder ein mysteriöses Schwingen, das mit kleiner werdender
Samplerate steigt.
Doch eine Systematik?
Hier sind mal noch weitere 8 Plots mit verschiedenen Ploteinstellungen
und jeweils 1000 Werten.
Plot 1-4 zeigen, was passiert, wenn ich von 1GS jeden 16. Wert nehme,
bei 500MS jeden 8. Wert und bei 250MS jeden 4. Wert beginnend von 1.
Sample, 2. Sample, 3. Sample und 4. Sample.
Plot 5-8 zeigen, was passiert, wenn ich von 1GS jeden 8. Wert nehme, bei
500MS jeden 4. Wert und bei 250MS jeden 2. Wert beginnend von 1. Sample,
2. Sample, 3. Sample und 4. Sample.
Die Darstellung passt nur für die Verwendung 16 8 und auch nur, wenn
ich mit dem ersten Sample beginne.
Sieht darin irgend jemand einen Zusammenhang? Insbesondere in Verbindung
mit dem FW-Code?
Gruß, branadic
branadic schrieb:
> Guten Abend/Morgen,>> [...]>> Aufgenommen habe ich (siehe Bild oben links) ein 2MHz Rechtecksignal mit> 1GS/s bei 100ns/div.> Danach habe ich dann auf 2µs/div gestellt, Stopp gedrückt, auf 100ns> zurück gestellt und eine erneute Messung durchgeführt. Dabei bleibt die> Samplerate von 500MS/s bei 100ns/div erhalten. Bis hierhin nicht> unbedingt verwunderlich. [...]
Naja, für mich klingt das eher so, als würde die Sample-Rate bei
einer Umschaltung während die Stop-Taste gedrückt ist, nicht angepasst.
Das riecht für mich nach einem Bug.
Wenn es dann noch zwei Variablen sind, die da geändert werden müssen
und nur eine geändert wird, dürfte es nette Effekte geben.
>> Beste Grüße, branadic
Grüße,
rowue
Rolf Würdemann schrieb:
> Daniel H. schrieb:>> Rolf Würdemann schrieb:>>> ii) Es wäre sehr hilfreich, wenn jmd. mit "Admin"-Rechten im Trac>>> entsprechende Bezeichnungen für "Component", "Version" und ggf.>>> Milestone (vorher absprechen?) einrichtet - sonst wird es>>> irgendwann etwas unübersichtlich ;)>>>> Für Vorschläge bin ich ganz Ohr -- oder fühlt sich jemand zum>> Ticket-Admin berufen? =)>> Ach, ich bin ganz froh, wenn das jmd. anderes macht ;) - Zu viele> Projekte verderben den Brei ;)>> Vorschläge:>> Component:>> firmware-nios> pc-screenshot>> Version:> ab 0.80Beta die veröffentlichten Versionen.> Am besten bei/kurz nach der Veröffentlichung.>> Milestone:> 1.0> (1.1 / oder 2.0)>> alternativ: schöne Codenamen für die> "endgültigen" (nicht Beta) Releases ;)
+Type: Feature-Request
(Um ein "Enhancement" im Sinne eines Patches von einer
Bitte um ein weiteres Feature abzugrenzen ;)
Daniel: Ich habe hier einige Bugs (+Feature-Requests), die ich
gerne mal filen würden ;) - hättest Du Lust, die Vorschläge
oben zu übernehmen, oder möchtest Du noch andere Vorschläge
abwarten? - Die Umstellung auf das Trac-Ticket-System würde
da m.E. einiges übersichtlicher machen ;)
Grüße,
rowue
@branadic
Mich würden mal die dazugehörigen ADC Offsets interessieren, könnte es
sein dass da bei der Zuordnung zu den ADCs was durcheinander gerät, wenn
nicht alle vier benutzt werden? Im Prinzip könnten solche Zacken dann
schon zustandekommen, auch die Periodizität wäre dann denkbar...
Hallo branadic,
ich fange mal mit Spekulationen an; bei 500 MS/s ist die Sache
klar. Mit jedem 4, Wert nimmst du abwechselnd Daten von ADC1 und
ADC3 und da keine Offsetkorrektur stattfindet (?) schwanken die
Werte etwas.
Bei 250 MS/s gibt es nach Daniels Erklärung keine solche Begründung.
Wisst ihr sicher, dass statt Downsampling nicht einfach die
Abtastrate runtergesetzt wird (würde ich so machen, hat ja aber
nicht viel zu sagen)?
Gruß, Guido
@ Rolf
Also, ich habe mir jetzt noch mal für alle Sampleraten die Daten
exportiert. Soll heißen, 1µs/div mit 1GS/s, 2µs mit 500MS/s und 5µs mit
250MS/s, eben so wie es original im Oszi auch hinterlegt ist.
Am Effekt der auf die Daten wirkt ändert sich aber nichts. Das heißt,
meine obigen Messungen sind glaubhaft. Kannst du gern selbst nachprüfen.
Das heißt also auch, dass es kein Scheineffekt ist, sondern ein
ernstzunehmendes Problem ;)
Gruß, branadic
@ Michael
Du wirst lachen, aber genau den Gedanken hatte ich vorhin auch schon und
hab ihn mit den Jungs in Skype diskutiert.
ADC-Korrekturwerte für meinen Kanal 1:
ADC1 = 3
ADC2 = 0
ADC3 = 1
ADC4 = 1
Beste Grüße, branadic
@ branadic und Michael: Oops, Michaels Post habe ich übersehen.
Aber das ist nach meinem Gefühl absolut korrekt. Ich schau später
noch nach, aber nach meiner Erinnerung werden alle Werte so wie
sie vom FIFO reinkommen in der Reihenfolge 1-2-3-4 offsetkorrigiert.
D.h. so, als ob alle 4 ADCs verwendet werden.
Gruß, Guido
Damit sind die Offsets wohl eindeutig zu klein, um die hässlichen
Sprünge zu erklären. Schade, aber dem kommen wir schon noch auf die
Spur!
Ich brauche unbedingt mal einen Signalgenerator, leider sind die Dinger
halt auch gebraucht noch ziemlich teuer wenn man auf einen einigermaßen
anständigen Sinus Wert legt.
Ist es eigentlich eine Tatsache, dass die Anzahl der verwendeten ADCs
abhängig von der Timebase variiert, also hat das jemand überprüft? Bei
nur einem verwendeten ADC bei 250MSa/s kann ich mir einfach nicht
vorstellen, dass sowas dabei rauskommen kann!
Gruß
Michael
branadic schrieb:
> @ Rolf>> Also, ich habe mir jetzt noch mal für alle Sampleraten die Daten> exportiert. Soll heißen, 1µs/div mit 1GS/s, 2µs mit 500MS/s und 5µs mit> 250MS/s, eben so wie es original im Oszi auch hinterlegt ist.> Am Effekt der auf die Daten wirkt ändert sich aber nichts. Das heißt,> meine obigen Messungen sind glaubhaft. Kannst du gern selbst nachprüfen.> Das heißt also auch, dass es kein Scheineffekt ist, sondern ein> ernstzunehmendes Problem ;)
Dann könnten wir evtl. zwei Probleme haben:
a) Das Problem mit den Rückschalten der Sample-Rate
(Siehe z.B. auch das Quick-Measurement-Problem nach dem
Quick-Print (habe hier noch zwei weitere in der Queue ;)
b) Das Abtast-Problem - aus Deinen Datenfiles würde ich schon
schliessen, dass da beim Auslesen der ADC's was vertauscht
ist.
>> Gruß, branadic
Grüße,
rowue
So, ich habe eben Revision 172 commited. Die enthält die neue Aufteilung
der Dateien und Klassen von Hayo und meine schonmal committeten
Änderungen am screenshot.
Meine Pöbelei im Log auf deutsch: "Das hat mich jetzt drei Stunden
gekostet. Wenn nochmal jemand, SVN ignorierend, aus einer lokalen Kopie
ein Release baut, tue ich mir diese Überflüssige Arbeit nicht nochmal
an. Dann haben wir eben eine Release im SVN, die Screenshots und
GUI-Fernbedienung unterstützt und eine, die irgendetwas anderes kann. Es
sei denn, jemand anderes popelt das zusammen."
Gruß, Falk
Hallo Falk,
das ist schön. Ist jetzt also das SVN soweit fertig? Vorher mache
ich an der Firmware nichts mehr (mir gehen mit jeder neuen Version
halt alle Bookmarks flöten...).
@ branadic: Ich habe noch mal in die Sourcen geschaut. Es wird in
allen Bereichen so korrigiert, als ob im FIFO die Daten in der
Reihenfolge ADC0, ADC1, ADC2 und ADC3 ankommen. Das kann natürlich
falsch sein, aber gibt es mehr als den Verdacht, was darauf
schließen lässt, dass nicht alle ADCs verwendet werden? Dass die
Firmware hinterher nicht alle vorhandenen Daten auswertet ist klar.
Gruß, Guido
Hallo Rolf,
ein Vertauschen der ADC-Werte möchte ich nicht ausschließen. Nur wurde
das bisher anhand der auf dem Display dargestellten Werte beurteilt, der
Datenexport dagegen bringt hier eher Aufschluss über die korrekte
Reihenfolge. Bei der Darstellung auf dem Display müssen dann ja noch
einmal Werte weggeschmissen werden, immerhin stehen nur 600px zur
Darstellung zur Verfügung. Das heißt, wenn die Darstellung auf dem
Display scheinbar stimmt, muss das für die Samples im Speicher noch
lange nicht gelten.
Wie wird dieses zweite Downsampling überhaupt realisiert? Welche Werte
in welcher Reihenfolge werden hier weggeschmissen?
Gruß, branadic
Guido schrieb:
> Hallo Falk,>> das ist schön. Ist jetzt also das SVN soweit fertig?
Fertig? Mhhhh.... Es sind jetzt alle mir bekannten Versionen
eingepflegt. Da ich gerade kein Scope habe, weiß ich nicht, ob das alles
funktioniert.
> Vorher mache> ich an der Firmware nichts mehr
Nach meinem Verständnis sind im SVN jetzt die aktuellen Versionen von:
- Firmware aus Hayos BlueFlash_Build_0_87.zip
- Letzte Änderungen am Screenshot (Farbe 14s), kompatibel zur aktuellen
Version von w2000a-screenshot
- Dito für das (sehr rudimentäre) w2000a-qtgui
> (mir gehen mit jeder neuen Version halt alle Bookmarks flöten...).
Bookmarks?
Falk
Hallo Guido,
irgendwie muss ja das erste Downsampling realisiert worden sein, da
stimmen wir sicher beide überein. Das erste Downsampling ist jenes,
welches dafür sorgt, dass bei 1GS alle Daten in den Speicher wandern,
bei 500MS nur noch jeder zweite Wert (doppelte Anzahl Signalperioden),
bei 250MS jeder vierte Wert (vierfache Anzahl Signalperioden) usw. und
so fort.
Jetzt stellt sich natürlich die Frage, ob die Werte die in den FIFO
wandern auch alle äquidistant sind. Äquidistanz wäre nur gegeben, wenn
bei 500MS die Werte von ADC0 und ADC2 verwendet werden. Bei 250MS
entsprechend nur noch die Werte von ADC0.
Sollte hier schon Unfug passieren, dann wären die Samples nicht mehr
plausibel, weil das Eingangssignal nicht in gleichen Zeitabständen
abgetastet würde, sondern irgendwie. Das wäre der GAU!
Jetzt ist nur die Frage, wie wir die Frage beantworten können, ohne
einen Blick auf das FPGA-Design von Welec werfen zu können.
Gruß, branadic
Hallo branadic,
was meinst du jetzt mit Downsampling? Für die Firmware kannst
du das Hayos Programming-Maps entnehmen. Z.B. werden bei 250 MS/s
16 kB Daten gesampled und davon jeder 25. Wert (Faktor=25)
angezeigt. Macht für die Darstellung insgesamt 655 Werte
(Sample-Depth=25).
@ Falk: Die Lesezeichen in Kate, die mir den Weg durch
tausende Programmzeilen bahnen. ;-)
Gruß, Guido
Guido schrieb:
...
> @ Falk: Die Lesezeichen in Kate, die mir den Weg durch> tausende Programmzeilen bahnen. ;-)
Oh, die kannst Du wohl wieder wegschmeißen.
Ich wollte ja viele kleine Dateien haben..... Naja, das läßt sich
vielleicht Zug um Zug umsetzen.
Es war zwar ein Stück Arbeit, das zusammenzubauen, aber angesichts der
Tatsache, daß Hayo einen überragenden Anteil an der Arbeit hat, das
W20xx brauchbar zu machen - und alle anderen sich gedrückt haben ;-) -
war es das wert.
Wollte ich auch mal gesagt haben.
Falk
Okay, noch mal langsam Guido.
Mit dem ersten Downsampling meine ich jene Daten, die im 16k-Speicher
landen. Wie du diesem Bild hier:
http://www.mikrocontroller.net/attachment/54980/alle_Samples.PNG
entnehmen kannst, habe ich den kompletten Speicher bei 1GS / 500MS und
250MS mit der Screenshot.exe ausgelesen. Wie du auch siehst, sind es
jeweils 16k Datenpunkte und man erkennt, dass bei 1GS 33 Signalperioden
zu sehen sind, bei 500MS sogar 66 Signalperioden und bei 250MS sind es
dann sogar 132 Signalperioden.
Das führt uns zur Erkenntnis, dass bei 500MS die Werte von 2 ADCs
weggeschmissen werden müssen, bevor sie überhaupt im Speicher landen,
sonst würde das mit der doppelten Anzahl an Signalperioden aufgrund des
16k-Speichers ja nicht funktionieren. Soweit klar?
Bei 250MS habe ich nun die vierfache Anzahl an Signalperioden gegenüber
1GS. Also müssen die Werte von 3 ADC weggeschmissen werden, sonst könnt
ich nicht die vierfache Anzahl Signalperioden im Speicher haben.
Jetzt klar?
Gruß, branadic
Hallo branadic,
nö, immer noch nicht klar. Was wäre denn, wenn die Samplerate der
Wandler jeweils halbiert würde? Kannst du das ausschließen. Das
ist es, was ich meine ich würde so vorgehen, denn den Takt im FPGA
zu halbieren ist ja kein Hexenwerk.
Gruß, Guido
Hallo,
also ich habe ein altes W2012 ohne A.
Ich verfolge die Diskussionen hier schon lange. Leider hat mir Wittig
nie geantwortet.
Nun ja, ich hab nun mal ein Update gewagt (die neuere Firmware 1.10.03
oder so) lief ja bei mir nicht, man konnte nur Min und Max auswählen.
Also, ich habe die Datei W2022A.JIC per JTAG in den Config-Flash
geschrieben. Danach ein Update mit der Firmware 1.2.BF.0.86beta gemacht.
Schien alles gut zu laufen. Das Firmwareupdate läuft soweit durch. Das
Gerät startet neu, im Updater steht allerding noch "Programmierung ..
bitte warten" und es kommt dann dort ein Timeout.
Wie gesagt, Gerät läuft und lässt sich auch bedienen. Nur sind die
ADC-Values (Konsole) immer auf 255. Die Traces bleiben auch nach
Kalibrierung am unteren Bildschirmrand. So ganz stimmt dann wohl doch
was nicht? Hat jemand eine Idee?
Morgen probier ich nochmal die alte Firmware, um zu sehen, obs am
FPGA-Core liegt, mir war aber so, als ging es dann noch.
Hallo Remo,
> ADC-Values (Konsole) immer auf 255. Die Traces bleiben auch nach> Kalibrierung am unteren Bildschirmrand. So ganz stimmt dann wohl doch> was nicht? Hat jemand eine Idee?
Schau doch mal hier:
http://forum.ixbt.com/topic.cgi?id=48:8586
Schauen geht ja noch. Lesen ist allerdings viel schwieriger : -)
Soweit ich das verstehe, haben sie dort ein Upgrade geschafft.
Gruß Jürgen
Hallo Guido,
das wäre prinzipiell natürlich machbar, aber die Wahrscheinlichkeit für
dieses Vorgehen dürfte eher gering sein, wenn nicht sogar ganz
ausgeschlossen werden.
Die einfachste Möglichkeit ist einfach ein Downsampling, sprich Werte
werden schlichtweg weggeschmissen.
Das man eine Takthalbierung vorgesehen hat traue ich dann noch nicht
einmal Wittig zu.
Der sinnvollste Weg wäre eigentlich, mit so wenig ADCs wie möglich zu
arbeiten, also genauso wie ich das schon die ganze Zeit schreibe:
1GS - vierfach interleaved
500MS - 2fach interleaved
250MS - gar nicht mehr interleaved
Was aber können wir machen für den Fall, dass der Downsampler von Wittig
nicht korrekt funktioniert?
Ich meine, dass uns dann nur die Möglichkeit bleibt mit den vollen 1GS/s
in allen Zeitbasen zu arbeiten, die 16k Speicher zu füllen und dann die
richtigen Samples via FW herauszupicken. Das ändert die erzielbare
Speichertiefe im Oszi insgesamt gewaltig und dürfte auch die Performance
gewaltig nach unten treiben.
Beste Grüße, branadic
Hallo,
also folgende Situation:
altes W2012 ohne A mit FPGA-Core für W2022A (slogs *.JIC Datei) führt
dazu,
dass die Relais nicht mehr angesteuert werden. Deswegen gehen die
Analogeingänge dann auch nicht mehr.
Taster und Encoder funkitonieren. Hat sich da doch was an der Schaltung
verändert?
Wie kann ich dies überprüfen?
Wo kann ich im FPGA-Design die Pin-Belegung für die Relais-Steuerung
finden bzw. ändern?
In welchem Thread ist diese Anfrage besser aufgehoben?
Gruß, Remo.
Remo schrieb:
> Hallo,>> also folgende Situation:>> altes W2012 ohne A mit FPGA-Core für W2022A (slogs *.JIC Datei) führt> dazu,
...
> In welchem Thread ist diese Anfrage besser aufgehoben?
Entweder im Hardwarethread Beitrag "Wittig(welec) DSO W20xxA Hardware"
oder gleich da, wo mehr Leute mitlesen:
https://sourceforge.net/apps/phpbb/welecw2000a/
Gruß,
Falk
P.S.: Im Übrigen bin ich der Ansicht, daß dieses Forum für diese Art
der Kommunikation ziemlich ungeeignet ist.
Hallo branadic, guido,
Um die Diskussion um den Downsampler etwas zu kaeren habe ich mal den
clock an den AD-Convertern bei verschieden Sample raten gemessen. Der
Clock ist immer 250Mhz. Damit ist klar das das FPGA Design ein
(schlechtes) Downsampling macht. Leider wissen wir nicht ob das
irgendwie via SW beeinflusst werden kann.
N.B. Der Fehler tritt auch bei der Original FW 1.3 auf.
Martin
Martin H. schrieb:
> Um die Diskussion um den Downsampler etwas zu kaeren habe ich mal den> clock an den AD-Convertern bei verschieden Sample raten gemessen. Der> Clock ist immer 250Mhz. Damit ist klar das das FPGA Design ein> (schlechtes) Downsampling macht. Leider wissen wir nicht ob das> irgendwie via SW beeinflusst werden kann.> N.B. Der Fehler tritt auch bei der Original FW 1.3 auf.
Man hätte drauf kommen können, das zu tun =D Naja aber gut dass das
jetzt geklärt ist.
Das wichtigste Argument für das Downsampling (statt einer Reduzierung
der Samplerate) ist übrigens, dass man so schnell wie möglich vom
Interleaving mehrerer ADC wegmöchte, weil dadurch ja doch einiges an
Fehler auf's Signal kommt (durch Clock Jitter, unterschiedliche
Signallaufzeiten, ... -- da gab's mal so ein PDF von Agilent(?), in dem
gut gezeigt wurde, was das Interleaving so für Effekte hat).
Edit: Habe das Ticketsystem im Trac nach euren Wünschen eingestellt.
Sorry, hatte das total verpennt am WE.
Hallo,
über das ADC Timing hatten wir schon ausführlich im HW Thread
diskutiert.
Jeder der 4 ADC (pro CH) wird von einem eigenen Clocksignal angesteuert.
Dieses Clocksignal wird von den 4 PLL's im FPGA direkt erzeugt (25MHz
input vom Quarz *10). Das Timing der einzelnen PLL zueinander lässt sich
in weiten Grenzen ändern, also eine konstante Phasenverschiebnung zw.
den einzelnen Clocks um z.B. Laufzeitunterschiede zu den ADC
auszugleichen.
Allerdings findet die Clockerzeugung und Festlegung einer evtl.
Phasenverschiebung in VHDL statt und lässt sich somit nachträglich nicht
mehr korrigieren (ohne ein neues VHDL- Design aufzuspielen)
> Aufgenommen habe ich (siehe Bild oben links) ein 2MHz Rechtecksignal mit> 1GS/s bei 100ns/div.> Danach habe ich dann auf 2µs/div gestellt, Stopp gedrückt, auf 100ns> zurück gestellt und eine erneute Messung durchgeführt. Dabei bleibt die> Samplerate von 500MS/s bei 100ns/div erhalten.
Vielleicht sollten wir erstmal diesen Fehler fixen???
Da ich ja bereits vor vielen Monaten von eigenartigen Schwingungen (bei
höheren Freq.) berichtet habe, wollte ich heute einmal ein Signal mit
60MHz als csv abspeichern. Im Prinzip geht es darum diesen Effekt näher
zu untersuchen und mit dem jetzt festgestellten Fehler zu vergleichen.
Das Ergebnis hat mich dann doch etwas überrascht.
Sollte diese Datei nicht so aufgebaut sein das in Jeder Zeile die Werte
des ADC0;ADC1;ADC2;ADC3 stehen, in der nächsten Zeile dann entsprechend
u.s.w.?
Also Anlage einmal ein Screendump meines Signal- wenig spektakulär.
Hallo,
danke Martin, damit ist das geklärt. Ist aber sehr seltsam, dass
niemand den Firmware-Entwickler darüber aufgeklärt hat.
@ branadic: dann probiere ich mal mit dem SVN und baue eine .ram,
die die Offsetkoreektur entsprechend anpasst. Dann können wir
damit mal testen.
Gruß, Guido
Aha, jetzt hab ich's auch verstanden. Die Einzelnen ADC Werte liegen
Zeilenweise vor.
Also erste Zeile: ADC0-ch1;ADC0-ch2;ADC0-CH3;ADC3-ch4
Zweite Zeile: ADC1-ch1;ADC1-ch2;.... usw.
Mich hat nur bei branadic verwirrt, daß in seiner csv- Datei (s.h. hier
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware" ) die Spalten 2, 3,
4 keine konstanten Werte enthalten, sondern irgendwelche Mülldaten die
sich auch nicht mit Rauschen erklären lassen.
Gruß, brunowe
Hallo zusammen,
schön, dass sich einige Unklarheiten jetzt schon einmal geklärt haben.
Den Takt hätte ich ja auch selbst gemessen, wenn ich ein zweites Oszi
mit der notwendigen Bandbreite daheim hätte :)
Und auch von Guido weiß ich, dass er über ein solches Gerät nicht
verfügt.
Also an dieser Stelle ein kleiner Dank an Martin.
Die Ungereimtheit in der Darstellung der Daten wäre nun auch geklärt und
ich nehme meine Behauptung von gestern? wieder zurück, dass der Export
der Daten nicht korrekt funktioniert. Octave interpretiert nur das
Semicolon als Zeilenende und importiert die Daten von Kanal 2, 3 und 4
nicht. Tausche ich jedoch die Semicolons gegen ein Komma aus, dann
erhalte ich auch eine 16384x4 Matrix, wobei Spalte 1 Kanal 1 ist usw.
Wäre auch das geklärt.
Guido, dann ist es also wirklich schon mal so, dass die
Offset-Korrekturwerte auf die falschen Samples wirken?
Aber anders herum gefragt, auf die Daten die ich aus dem
16k-Samplespeicher auslese hat das doch keinen Einfluss oder? Das sind
doch für mich die absoluten Rohdaten oder werden die Daten aus dem FIFO
schon korrigiert in den 16k-Samplespeicher gelesen? Dann wiederum hätte
die Korrekturreihenfolge natürlich einen Einfluss.
Ich bin gespannt was sich tut, auch wenn der Hayo jetzt im Urlaub ist.
Beste Grüße, branadic
Hallo branadic,
doch die Daten sind schon vorverarbeitet (Offsetkorrektur,
Invertierung, Averaging). Das erfolgt in READADC_ALL.
Im anhängenden .ram habe ich mal versucht für Kanal 1 die
Offsetkorrektur anzupassen, die anderen Kanäle sind unverändert,
damit solltest du vergleichen konnen.
Gruß, Guido
Hallo Guido,
einen Unterschied bezüglich der Zacken auf den Signalflanken zwischen
der Ram-Testversion und der aktuellen,frisch compilierten 0.87 kann ich
leider nicht feststellen. Mir ist bloß aufgefallen, daß mit dem
Umschalten des Test_sw1 mit shft-S auf deine C-Routinen in READADC_ALL
diese merkwürdigen Zacken auf den Flanken gegenüber den
Assemblerroutinen vergrößert werden. Hier scheint es also noch
Unterschiede in asm und C Implementierungen zu geben.
Leider kann ich keinen screenshot mehr machen, da nach der Umstellung
von Falk im svn die screenshot_v0.4.exe unter win32 nicht mehr zum Ende
kommt.
Wo gibt es eine aktuelle passende Datei?
Gruß Jürgen
Jürgen schrieb:
> Hallo Guido,
...
> Leider kann ich keinen screenshot mehr machen, da nach der Umstellung> von Falk im svn die screenshot_v0.4.exe unter win32 nicht mehr zum Ende> kommt.> Wo gibt es eine aktuelle passende Datei?
Die müßte mal jemand komplilieren....
Falk
>Die müßte mal jemand komplilieren....>Falk
Eben!
Zurück zum Thema: hab die 0.86 nochmal aufgelegt und hier die zwei
Screenshots gemacht. Mal zum Vergleich Version 1 mit asm-routinen
Hallo Jürgen,
danke für die Tests. Na das ist doch schon mal ein Fortschritt,
an den C-Routinen habe ich noch nichts geändert. Da muss ich
erst mal versuchen besser zu kapieren wie die Daten angeordnet
sind.
Erst muss ich auch mal die Screenshots zum funktionieren
bringen.
@ Falk: kannst du für das PC-Programm noch einen Tarball und/oder
ein Zip hinzufügen?
@ branadic: Würdest du bitte mal die Befehle für octave posten,
mit denen du die Bilder hinbekommst? Dann muss ich nicht die
ganze Dokumentation durchwühlen.
Gruß, Guido
Daniel H. schrieb:
> Martin H. schrieb:>> [Downsampling]>> [Downsampling^2]>> Edit: Habe das Ticketsystem im Trac nach euren Wünschen eingestellt.> Sorry, hatte das total verpennt am WE.
Danke! - Habe gerade mal Bugs/Feature-Requests gefiled
(könnte jmd. - bei Gelegengheit - die Priorität von #8
(https://sourceforge.net/apps/trac/welecw2000a/ticket/8))
mal auf Minor setzen?)
Frage: gibt es nicht auch eine 0.87 (habe die Bugs jetzt auf
0.86 gesetzt ;)
Ich wüsste da noch einige nette Plugins für Trac - soll ich
da mal 'ne Liste schicken? ;)
Daniel: wenn Du möchtest, kannst Du mich (rowue) auch auf TICKET_ADMIN
setzen (aber wie beschrieben, wenn Du möchtest ;)
So,
ich habe jetzt die Visualisierung mit gnuplot hinbekommen und
kann die Zacken live bestaunen. Ich habe mich schon immer gefragt,
warum die Zeitbasis so verrückt verwendet wird und auch Hayo
wollte da ja schon länger mal ran gehen. Vielleicht haben wir ja
den Grund gefunden. wenn man von 20 Werten 19 wegwirft, sind ev.
die Zacken verschwunden.
Allerdings war die Vermutung, dass diese Zacken nichts mit der
Offsetkorrektur zu tun haben imho korrekt, die sind viel zu
stark. Sollen wir es mit Datenverwürfeln pobieren?
Gruß, Guido
Hallo Guido,
bin leider erst jetzt nach Hause gekommen und kann mich wieder anderen
Dingen widmen...
Nun, wenn es wirklich so ist, dass im Speicher bereits "gewürfelte",
vorverarbeitete (Offsetkorrektur, Invertierung, Averaging) Daten liegen,
dann könnte ein neues Würfeln eventuell den gewünschten Erfolg bringen
:)
Beste Grüße, branadic
> Ich wüsste da noch einige nette Plugins für Trac - soll ich> da mal 'ne Liste schicken? ;)
Da muss ich mal schauen ob es mittlerweile möglich ist, Plugins zu
installieren. Anfangs konnte man definitiv nix an der gehosteten App
verstellen, aber seit einiger Zeit tauchen zumindest schonmal die
Settings der trac.ini im Trac-Adminbereich auf. Evtl. hat SF.net jetzt
ja auch 'ne Möglichkeit, Plugins nachzuinstallieren. Ich geb die Tage
bescheid wenn ich mich in der SF.net-Doku umgesehen habe, obs geht oder
nicht.
> Daniel: wenn Du möchtest, kannst Du mich (rowue) auch auf TICKET_ADMIN> setzen (aber wie beschrieben, wenn Du möchtest ;)
Hab dich mal in die Developer-Gruppe gesteckt.
Hallo Guido,
der Jürgen hat ja schon mal ein paar Screenshots geliefert, viel
interessanter ist aber ein direkter Vergleich der Daten im Speicher mit
beiden Routinen. Das hab ich mal für 1GS / 500MS und 250MS durchgeführt.
Das Ergebnis kann man dann oben sehen. (0.86beta)
Schwinger gibt es bei beiden Methoden. Das heißt für mich, dass auch im
Assemblercode die falschen Samples abgeholt werden.
Beste Grüße, branadic
@branadic, guido
Fuer die 500Ms Stoerung habe ich eine verwuerfelung gefunden:
Original date; 12345678 zu 56127834
In Angang eine CVS Datei mit den 1. Kanal von branadic und den
korrigierten Daten.
Martin
p.s. fuer die 250Ms Daten geht dieser Ansatz leider nicht!
Daniel H. schrieb:
>> Ich wüsste da noch einige nette Plugins für Trac - soll ich>> da mal 'ne Liste schicken? ;)>> Da muss ich mal schauen ob es mittlerweile möglich ist, Plugins zu> installieren. Anfangs konnte man definitiv nix an der gehosteten App> verstellen, aber seit einiger Zeit tauchen zumindest schonmal die> Settings der trac.ini im Trac-Adminbereich auf. Evtl. hat SF.net jetzt> ja auch 'ne Möglichkeit, Plugins nachzuinstallieren. Ich geb die Tage> bescheid wenn ich mich in der SF.net-Doku umgesehen habe, obs geht oder> nicht.>
Schau mal unter Admin, ob Du da "links" (in dem Reiter, wo Du auch
Permissions, etc findest ;) - einen Punkt Plugins hast, dann sollte
nach anclicken rechts auch ein Feld "Install Plugin" auftauchen ;)
Vorschläge wären:
TracFigure: https://www.selidor.net/trac/wiki/TracFigureMacro
Einbau von Bildern
TracIncludeMacro: http://trac-hacks.org/wiki/IncludeMacro
Erlaubt Inhalte anderer URLS oder Trac-Objekte in's
Wiki (auch Tickets) einzubinden
TracMath: (eher schwierig, braucht u.a. Latex auf dem System)
Latex-Formeln in Tickets und im Wiki
TracTags: http://trac-hacks.org/wiki/TagsPlugin
Erlaubt Tags zu Objekten im Trac, ähnlich den
Kategorien bei MediaWiki ;)
TracWikiGoodies: http://trac-hacks.org/wiki/WikiGoodiesPlugin
Diverse HTML-Zeichen ;)
siteupload: http://trac-hacks.org/wiki/SiteUploadPlugin
Erlaubt das Hochladen von Dateien in htdocs - manchmal
nett zum Verlinken ;)
Irgendwo gibt es auch ein Plugin für GraphViz-Dateien ;)
>> Daniel: wenn Du möchtest, kannst Du mich (rowue) auch auf TICKET_ADMIN>> setzen (aber wie beschrieben, wenn Du möchtest ;)>> Hab dich mal in die Developer-Gruppe gesteckt.
Bedankt ;)
Martin H. schrieb:
> @branadic, guido>> [Abtaststörung]
Hmmmm ....
könnte es Sinn machen (wegen der Linearität) ein Dreieck-Signal
zu sampeln und keinen Sinus - da müsste sich aus dem Differentenquotient
(doch einiges ablesen lassen ;)
Grüße,
rowue
Hallo Martin,
sieht schon besser aus, scheint aber noch nicht komplett des Rätsels
Lösung zu sein. Scheinbar ist immer noch eine systematische Vertauschung
drin. (siehe Bild)
@ Rolf
Ist schwer, denn du musst bedenken, dass auch Rauschen ein Punkt ist.
Solange jedoch eine Systematik in den Daten zu erkennen ist, kann es
sich nicht um Rauschen handeln, mein ich.
Beste Grüße, branadic
Rolf Würdemann schrieb:
> Kurze Frage:>> gibt es hier Widerspruch/Bedenken, die>> BF.0.87>> so wie>> ScS.0.3> ScS.0.4>> auch als Versionen aufzunehmen?
Was meinst Du mit "als Versionen aufnehmen"?
Falk
Hallo,
so ganz überzeugt von Martins Verwürfelung bin ich noch nicht.
Als Anhang einmal ein MATLAB Ausdruck von branadics original Daten- und
darunter mit Martins Verwürfelung. Wesentlich besser, aber immer noch
deutliche Ausreißer.
Einen Test mit einem ordentlichen Rampensignal (relativ langsam im vgl.
zur Timebase) hatte ich auch schon einmal angeregt, leider fehlt mir ein
entsprechendes Testsignal.
Ist euch auch schon aufgefallen das immer so ca. die ersten 50-100
Samples aus der csv. Datei absolut nicht zu gebrauchen sind? Liegt das
am Export, oder liegen im Speicher tatsächlich anfangs nur fehlerhafte
Daten?
Gruß, brunowe
Rolf Würdemann schrieb:
> Schau mal unter Admin, ob Du da "links" (in dem Reiter, wo Du auch> Permissions, etc findest ;) - einen Punkt Plugins hast, dann sollte> nach anclicken rechts auch ein Feld "Install Plugin" auftauchen ;)
Nein, tut es nicht. Aber bisher bin ich auch vertrauter mit der
manuellen Installation von Trac-Plugins. Aber wie gesagt - ich schaue
mal.
Könnte Wittig versuchen, die ADCs softwareseitig / VHDL-seitig zu
synchronisieren? Eigentlich würde ich ja Phasenanpassungen am
Clocksignal dafür erwarten, aber vielleicht hatten die ja mal wieder
komische Einfälle?
Wenn sie es bei 1GSa eingerichtet hätten und dann die gleichen
Korrekturen bei niedrigeren Sampleraten anwendet?
Ihr kennt euch schon besser mit dem Gesamtpaket aus, könnte sowas
dahinterstecken?
Gruß
Michael
Interessant an Martins Korrekturvorschlag ist, dass die Korrektur am
Anfang der Samplereihe eher bescheidene Verbesserungen bringt, weiter
hinten dagegen sehr gute. Plottet doch mal Samples 6000-7000. Sehr
eigenartig.
Falk Willberg schrieb:
> Rolf Würdemann schrieb:>> Kurze Frage:>>>> gibt es hier Widerspruch/Bedenken, die>>>> BF.0.87>>>> so wie>>>> ScS.0.3>> ScS.0.4>>>> auch als Versionen aufzunehmen?>> Was meinst Du mit "als Versionen aufnehmen"?
im Ticket-System kann man, neben der Software-Komponente
(BlueFlash Firmware (NIOS), Screenshot Software (PC))
auch eine Version auswählen/anbieten.
Bisher sind da die BF.0.80 - BF.0.87 drin, ich würde
gerne noch die Screenshot-Versionen 0.3, 0.4 (0.5)
und die BF.0.87 "anbieten" - Der Verweis auf die Version
hilft etwas bei der Fehlersuche.
>> Falk
Grüße,
rowue
EDIT: und "SS" möchte ich als Kürzel für den Screenshot nur ungern
nehmen.
Oh,
da haben wir ja ein schönes Durcheinander. Vielleicht sollten wir
uns erst mal auf Messvorschriften einigen. Dreiecksignal finde ich
gut, Ramnpe wäre natürlich noch besser. Erstmal sollten wir
rausbekommen, ob alle Oszis den selben Versatz haben. Bei mir
ist die Zweiergruppierung von Martin nicht optimal (s.A.). Michaels
Beitrag klingt auch sehr interessant, da wäre ich nicht drauf
gekommen.
Die ersten irgendwas Samples sind auch bei mir voll daneben. Auch
dafür gibt es keine plausible Erklärung. Und die Bereiche unterhalb
250 MS/s fehlen auch noch.
Viel zu tun, Guido
Rolf Würdemann schrieb:
> Falk Willberg schrieb:>> Rolf Würdemann schrieb:>>> Kurze Frage:>>>>>> gibt es hier Widerspruch/Bedenken, die>>>>>> BF.0.87>>>>>> so wie>>>>>> ScS.0.3>>> ScS.0.4>>>>>> auch als Versionen aufzunehmen?>>>> Was meinst Du mit "als Versionen aufnehmen"?>> im Ticket-System kann man, neben der Software-Komponente> (BlueFlash Firmware (NIOS), Screenshot Software (PC))> auch eine Version auswählen/anbieten.>> Bisher sind da die BF.0.80 - BF.0.87 drin, ich würde> gerne noch die Screenshot-Versionen 0.3, 0.4 (0.5)> und die BF.0.87 "anbieten" - Der Verweis auf die Version> hilft etwas bei der Fehlersuche.
Wo finde ich das nun wieder ;-)
Mein Vorschlag: Die hier gepostete BF.0.87 habe ich im SVN mit den
Änderungen für den ScreenShot zusammengeführt. Sollten wir die nicht
0.88 nennen?
Dann halte ich es für eine gute Idee, die Screenshot-Version an die
zugehörige Firmware-Version anzupassen. Das wäre jetzt also Screenshot
0.88.
Vielleicht kannst Du noch warten, bis jemand bestätigt, daß Screenshot
auch unter Windows läuft und tatsächlich zur Firmware aus dem SVN
passt...
> EDIT: und "SS" möchte ich als Kürzel für den Screenshot nur ungern> nehmen.
SchirmAuszug ist auch nicht politisch korrekt ;-)
Falk
P.S.: irc.freenode.org:6667 #welec ist ziemlich verwaist.
P.P.S.: Wie wäre es mal mit Skype? Meine Nummer ist Falk-Willberg
P.P.P.S.: Heute nicht mehr ;-)
Haaar Falk,
> Sollten wir die nicht 0.88 nennen?
bedeutet das neuen Checkout und neue Bookmarks? Da kann man schon die
Lust verlieren. Oder bleibt im trunk alles beim alten?
Gruß, Guido
Guido schrieb:
> Haaar Falk,>>> Sollten wir die nicht 0.88 nennen?>> bedeutet das neuen Checkout und neue Bookmarks?
Nein.
> Da kann man schon die Lust verlieren.
Nimm vi, da hast Du keinen Ärger mit Bookmarks ;-)
> Oder bleibt im trunk alles beim alten?
Vorläufig ja. Solange die Struktur nicht wieder geändert wird, sollten
die Änderungen im Rahmen bleiben.
Falk
Hallo Guido,
klar können wir uns auf ein gemeinsames Messsignal einigen.
Bis 10MHz kann ich zumindest mit einem Dreiecksignal dienen. Rampe habe
ich nicht, ansonsten stehen mir nur Sinus und Rechteck noch zur
Verfügung.
Ich muss ehrlich gestehen, dass mir nicht ganz klar ist, wie eine solche
Synchronisation funktionieren sollte. Dazu müsste ja irgendein
Synchronisationssignal, auf das man "triggern" könnte, von den ADCs
zurück zum FPGA kommen.
Ansonsten ist es doch schön zu sehen, dass sich hier was auch ohne Hayo
bewegen kann :)
Auch wenn eine gewisse Systematik bei der ADC-Nicht-Reihenfolge drin zu
sein scheint, so könnte man doch den Eindruck gewinnen, dass irgendwie
eine Form von rand(ReadADC) durchgeführt wird.
Ich bin gespannt, was sich auf dem Gebiet tut. Schade nur, dass so viele
scheinbar Bilder schauen, sich aber nicht dazu äußern. Seid ihr
schüchtern?
Beste Grüße, branadic
Nur mal so als Idee: Die Offsetkorrektur der einzelnen ADCs mit Absicht
und deutlich verhageln und dann einfach kein Signal aufnehmen. Also z.B.
ADC1 + 50, ADC2 +100, ADC3 -50, ADC4 -100.
Da sollte man schön erkennen, wann welcher ADC im Speicher liegt.
Hallo branadic,
wenn wir erstmal untereinander vergleichen, hoffe ich, dass es kein
rand(ADC) ist. Eine Systematik muss schon her, sonst bleibt es wie
bei Wittig: alle unangenehmen Werte werden schlicht ausgeblendet.
Heute hat wieder ein potentieller Mitstreiter aufgegeben, hat bei
ebay 202 Eur für sein 2022A bekommen. Vllt. haben wir damit ja einen
neuen Mitentwickler gewonnen. :-)
Gruß, Guido
@ Karl: wenn die Werte erstmal im Speicher sind, ist das kein
Problem mehr. Ab da hat Hayo ja die ganze Sache entwickelt. Was
vorher passiert kriegen wir halt nur sehr schwer raus
(TrialAndError).
Gruß, Guido
branadic schrieb:
> [Martin ...]>> @ Rolf> Ist schwer, denn du musst bedenken, dass auch Rauschen ein Punkt ist.> Solange jedoch eine Systematik in den Daten zu erkennen ist, kann es> sich nicht um Rauschen handeln, mein ich.>
Naja, unserer Fehler sticht ja aus dem Rauschen raus, sonst würden
wir ihn nicht wahrnehmen ;)
Ich habe mir die Daten eben mit einem - nennen wir es mal Dreieckssignal
- angeschaut und wollte mir gerade etwas Statistik geben, als mir eine
bessere Idee kam ....
* Wir nehmen ein Signal mit einer steigenden Flanke, ob Sägezahn,
Rechteck, Dreieck, Sinus oder was uns auch immer einfällt ist dabei
(fast) egal
* Wir stellen den Vorverstärker des DSO so ein, dass dieser übersteuert
wird, lediglich 15 Messpunkte des Signals müssen im entsprechenden
Messbereich des DSO liegen.
* Von diesen 15 Messpunkten nehmen wir den, der Modulo acht null
ergibt und die nächsten sieben Kollegen. Diese nach Wert geordnet
sollten die Abtastfolge ergeben ;)
Btw: haben wir vier oder acht ADC's/Kanal? Ich ging immer von vier aus
...
> Beste Grüße, branadic
Grüße,
rowue
Ich habe jetzt mal mit dem o.g. System gespielt. Das Testsignal ist als
png beigefügt, die Testdateien kommen in den nächsten Einträgen (ich
liebe Trac ;).
Die Anstiegsrate beträgt 3,614 mV/ns.
Als Scanning-Order ergibt sich hieraus für
* 250Ms/sec: 2 + n*(34127856) (screenshot-0090.csv) 100mV/div
* 500Ms/sec: 4 + n*(56127834) (screenshot-0084.csv) 50mV/div
Interessant wäre jetzt eine zweite Messung, die diese Daten bestätigt.
Auffällig ist das paarweise Auftreten der Messwerte. Hier könnte sich
eine interessante Möglichkeit der Mittelwertbildung aufzeugen.
(Merken: mal schauen, wieviele Werte sich im Anstiegsbereich befinden
und ob dies dem Erwartungswert (g) entspricht ;)
Grüße,
n8,
rowue
Falk Willberg schrieb:
> Rolf Würdemann schrieb:>> Falk Willberg schrieb:>>> Rolf Würdemann schrieb:>>>> Kurze Frage:>>>>>>>> [...]>> Wo finde ich das nun wieder ;-)
In der Maske, wenn Du beim Trac 'nen Ticket eintütest ;)
Oder im Admin-Menue unter Ticket - Versions ;)
>> Mein Vorschlag: Die hier gepostete BF.0.87 habe ich im SVN mit den> Änderungen für den ScreenShot zusammengeführt. Sollten wir die nicht> 0.88 nennen?>
Hmmja - als Tag haben wir derzeit -0.87 ;) - Mit der 0.88
würde ich noch etwas warten - da wurden ja einige Bugs gefiled,
und der eine oder andere davon könnte einfach zu beheben sein ;)
Wir wollen Versionsnummern ja nicht inflationär gebrauchen ;)
> Dann halte ich es für eine gute Idee, die Screenshot-Version an die> zugehörige Firmware-Version anzupassen. Das wäre jetzt also Screenshot> 0.88.>
Wer ist für die Namensgebung der Screenshot-Versionen verantwortlich?
Aber stimmt - da die anscheinend eng an die Firmware gebunden sind,
wäre eine direkte Kopplung sicher sinnvoll ;)
> Vielleicht kannst Du noch warten, bis jemand bestätigt, daß Screenshot> auch unter Windows läuft und tatsächlich zur Firmware aus dem SVN> passt...>
No Prob ;)
>> EDIT: und "SS" möchte ich als Kürzel für den Screenshot nur ungern>> nehmen.>> SchirmAuszug ist auch nicht politisch korrekt ;-)
Siehe Congress-Centrum ;) (CCH ;)
>> Falk> P.S.: irc.freenode.org:6667 #welec ist ziemlich verwaist.> P.P.S.: Wie wäre es mal mit Skype? Meine Nummer ist Falk-Willberg> P.P.P.S.: Heute nicht mehr ;-)
Wenn Du im Irc bist, kannste mich per /msg rowue ansprechen - ich schau
dann mal rüber ;) (wenn ich an der Konsole bin ;)
Sonst finde ich auch XMPP/Jabber nicht schlecht ;)
N8 ;)
Rolf Würdemann schrieb:
> Ich habe jetzt mal mit dem o.g. System gespielt. Das Testsignal ist als> png beigefügt, die Testdateien kommen in den nächsten Einträgen (ich> liebe Trac ;).>> Die Anstiegsrate beträgt 3,614 mV/ns.>> Als Scanning-Order ergibt sich hieraus für>> * 250Ms/sec: 2 + n*(34127856) (screenshot-0090.csv) 100mV/div> * 500Ms/sec: 4 + n*(56127834) (screenshot-0084.csv) 50mV/div>
[...]
2 und 4 bedeuted hierbei einen Offset un 2 resp. 4 Bytes am Anfang
der Datei ;)
So langsam wird das doch!
Ich muss leider zugeben, dass ich nicht ganz kapiere, was mir deine csv
Dateien sagen, Rolf. Kannst du dazu noch ein paar Worte sagen?
Ansonsten scheint deine Nachtschicht ja recht produktiv gewesen zu sein!
Gruß
Michael
branadic schrieb:
> Hallo Hayo,>> ich hätte einen Punkt für die Wishlist:>> Eine Kombination aus Roll und Shiftmode.
Ist für den Urlaub notiert, ebenso die anderen Fehlermeldungen die seit
der letzten Woche hier gepostet wurden. Am Sonnabend geht es los - das
Oszi fährt mit :-)
Da mir die Abgleichmöglichkeit mit dem SFN unterwegs fehlt wird es da
wohl eine Verschiebung der Codebasis geben. Wie wir das dann abgleichen,
können wir ja dann Ende August klären.
Gruß Hayo
Hayo W. schrieb:
...
> Da mir die Abgleichmöglichkeit mit dem SFN unterwegs fehlt wird es da> wohl eine Verschiebung der Codebasis geben.
Wirst Du auf Basis der letzten Subversion-Version weitermachen?
> Wie wir das dann abgleichen, können wir ja dann Ende August klären.
Ich weise auf Beitrag "SVN wieder aktuell" hin
;-)
Schönen Urlaub,
Falk
Gönn' dir auf jeden Fall einen schönen Urlaub - und bevor es Krach mit
der Frau gibt...wenn die Bugs zwei Wochen später gefixed werden, wird
das auch keinen umbringen.
Gruß,
Michael
Michael H. schrieb:
> So langsam wird das doch!> Ich muss leider zugeben, dass ich nicht ganz kapiere, was mir deine csv> Dateien sagen, Rolf. Kannst du dazu noch ein paar Worte sagen?
Die csv Dateien sind Dateien der Messung des in dem Bild dargestellten
Signals mit den angegebenen Sampleraten.
Innerhalb dieser Dateien sucht mensch sich nun eine steigende Flanke
und notiert sich - beginnend mit einem durch acht teilbaren Index -
24 Messwerte, welche mensch in achter Gruppen zusammenfasst -
Es ergibt sich eine 8x3 Matrix.
z.B.:
25 77 120
30 81 125
63 106 151
63 105 151
88 132 175
91 135 179
118 162 208
117 161 207
(aus der 500MSa/s-Datei, screenshot-0084.csv)
Innerhalb dieser Gruppen sucht mensch sich nun Zahlengruppen, deren
Werte innerhalb eines Intervalls liegen. Dies ergibt den Offset
2 oder 4. Die acht Zahlen innerhalb des Intervalls ordnet man
nun entsprechend ihrer Größe an (je nach dem, ob steigende
oder fallende Flanke). Aus der Anordnung der Indexe ergibt sich
die Reihenfolge der Abtastungen.
Interessant ist hierbei, dass je zwei Werte sehr dicht beieinander
liegen (ein Paar bilden). Es hat den Anschein, als ob hier zweimal
direkt hintereinander abgetastet wird.
Hier könnte es interessant sein, aus dem jeweiligen Mittelwert der
Paare und den bekannten Daten (Signalanstiegszeit, Wertebereich
des ADC und Auflösungsfaktor) die (gemittelte) Zeit zwischen zwei
Abtastgruppen zu ermitteln.
> Ansonsten scheint deine Nachtschicht ja recht produktiv gewesen zu sein!
Danke! - Wenn ich das wissenschaftlich aufbereiten soll, sagt Bescheid
;)
>> Gruß> Michael
Grüße,
rowue
Hayo W. schrieb:
> branadic schrieb:>> Hallo Hayo,>>>> [Wishlist]>>>> Eine Kombination aus Roll und Shiftmode.>> Ist für den Urlaub notiert, ebenso die anderen Fehlermeldungen die seit> der letzten Woche hier gepostet wurden. Am Sonnabend geht es los - das> Oszi fährt mit :-)
Für uns schön (dass das Oszi mitkommt) aber: wolltest Du Urlaub machen
oder arbeiten? ;)
Ansonsten: hast Du Dir auch die Tickets im Trac mal angesehen?
Ich hatte da noch die eine oder andere Kleinigkeit (Darstellungs-
fehler, etc) "eingetütet" ;)
EDIT: http://sourceforge.net/apps/trac/welecw2000a/report/1>> Da mir die Abgleichmöglichkeit mit dem SFN unterwegs fehlt wird es da> wohl eine Verschiebung der Codebasis geben. Wie wir das dann abgleichen,> können wir ja dann Ende August klären.
Also: Wenn Du jetzt auf Basis des svn weiterarbeitest, wollte das
nicht das Problem sein, ansonsten verweise ich auf den Kommentar
von Falk ;)
(Wobei Du ja bisher mit Abstand das meiste gemacht hast ;)
>> Gruß Hayo
Grüße,
rowue
Michael H. schrieb:
> Gönn' dir auf jeden Fall einen schönen Urlaub - und bevor es Krach mit> der Frau gibt...wenn die Bugs zwei Wochen später gefixed werden, wird> das auch keinen umbringen.
Keine Angst, Urlaub geht vor. Aber meine Frau hat einige Bücher mit im
Gepäck, das ist dann der Moment in dem das Oszi ins Spiel kommt :-)
@Falk
Die Basis ist (bzw. war) die neu aufgeteilte Version, die ich als
Vorschlag für das SFN gepostet hatte (ich glaube 0.87). Der momentane
Stand weicht ohnehin schon von der aktuellen Version ab, da ich in der
Zwischenzeit einige Änderungen an der Screenshotfunktion vorgenommen
habe und auch den Rauschfilter erweitert bzw. verbessert habe.
Wie schon gesagt, wir müssen dann mal abstimmen, was davon in die
SFN-Version einfließen soll.
Gruß Hayo
Rolf Würdemann schrieb:
>> Ansonsten: hast Du Dir auch die Tickets im Trac mal angesehen?> Ich hatte da noch die eine oder andere Kleinigkeit (Darstellungs-> fehler, etc) "eingetütet" ;)>
Nein, das hatte ich noch nicht auf dem Radar. Danke für den Tip. Da
werde ich gleich mal meine Liste erweitern. Allerdings sehe ich, dass
einige Punkte, die ich hier im Forum eingesammelt habe da auch
auftauchen.
Gruß Hayo
Hayo W. schrieb:
...
> Die Basis ist (bzw. war) die neu aufgeteilte Version, die ich als> Vorschlag für das SFN gepostet hatte (ich glaube 0.87). Der momentane> Stand weicht ohnehin schon von der aktuellen Version ab, da ich in der> Zwischenzeit einige Änderungen an der Screenshotfunktion vorgenommen> habe und auch den Rauschfilter erweitert bzw. verbessert habe.>> Wie schon gesagt, wir müssen dann mal abstimmen, was davon in die> SFN-Version einfließen soll.
Ich wünsche Dir viel Spaß dabei :-(
Ich mache das nicht nochmal.
Falk
Jürgen schrieb:
>>Die müßte mal jemand komplilieren....>>Falk>> Eben!
Ich habe mal w2000a-screenshot.exe kompiliert. Ob die funktioniert, weiß
ich nicht. Wenn das mal jemand (mit der FW aus dem SVN) testen könnte?
Falk
Vergrault hier bloß nicht das Zugpferd des ganzen Firmwareprojekts!
Vielleicht ist Hayo (wie mir) nicht klar, warum es so einen Aufwand
macht, die Änderungen einzupflegen. Generell ist es übrigens etwas
problematisch für Leute die der Software nicht so nahe stehen (damit
meine ich mich), das alles nachzuvollziehen. Trunk? Für mich heißt das
Kofferraum... Comitted? Was denn, ein Verbrechen?
Gruß
Michael
@Falk & Daniel
Ich glaube Ihr habt mich da missverstanden. Ich wollte nicht die jetzige
Struktur oder den aktuellen Stand in Frage stellen, sondern meine
Änderungen so in die SFN-Version (mittels SVN) integrieren, das nichts
Vorhandenes durcheinander kommt, sondern nur Korrekturen oder
Verbesserungen einfließen. Das erfordert zwar etwas Handarbeit
meinerseits, sollte aber doch in Eurem Sinne sein oder?
Gruß Hayo
Ach ja, der Grund für die Änderungen an der Screenshotfunktion waren
unter anderem massive Fehler in der Bilddarstellung bei der 0.5 und
Unregelmäßigkeiten bei der Übertragung der Daten.
Weiterhin habe ich den Support für Schwarz/Weiß Screenshots rausgenommen
und die Steuerung welcher Typ erzeugt werden soll (BMP, PNG, CSV, ASCII)
komplett ins QP-Menü des Oszi verlagert, so dass das Screenshotprogramm
nur noch mit dem Schnittstellenparameter gestartet werden muß.
Diese Änderungen sind vorerst nur für mich selbst entstanden, und müssen
nicht in die offizielle Version einfließen.
Gruß Hayo
Now something completely different:
Das Ticket Nr.16 - Dieses Verhalten hatten wir schon einmal hier im
Forum diskutiert und waren zu dem Ergebnis gekommen, dass das so korrekt
ist. Im "Normal" Triggermodus hört die Signalverarbeitung auf sobald der
Trigger nicht mehr auslöst. Nur im "Auto" Modus läuft er auch dann
weiter.
Das Ticket wäre demnach eigentlich keines. Oder sehe ich das falsch?
Hayo
Hayo W. schrieb:
> Ach ja, der Grund für die Änderungen an der Screenshotfunktion waren> unter anderem massive Fehler in der Bilddarstellung bei der 0.5 und> Unregelmäßigkeiten bei der Übertragung der Daten.
Könntest Du das mal committen?
Falk
Hayo W. schrieb:
> @Falk & Daniel>> Ich glaube Ihr habt mich da missverstanden. Ich wollte nicht die jetzige> Struktur oder den aktuellen Stand in Frage stellen, sondern meine> Änderungen so in die SFN-Version (mittels SVN) integrieren, das nichts> Vorhandenes durcheinander kommt, sondern nur Korrekturen oder> Verbesserungen einfließen.
Ok, wenn Du Änderungen auf Basis der Version 172 machst, kann nicht viel
passieren...
Falk
Hallo Hayo,
auch wenn okilidokili das Ticket etwas konfus verfasst hat, ja, ich gebe
dir recht, nach unserer bisherigen Festlegung- It's a feature not a bug.
Wobei ich es ehrlich gesagt auch jedes mal sehr verwirrend finde, daß
dieses nicht mehr getriggerte Signal einfach stehen bleibt- vom
logischen würde ich erwarten das der Bildschirm dann gelöscht wird.
Manchmal ist es sehr schwer zu erkennen, ob sich das Oszi aufgehängt
hat, ob das Signal nur so stabil und gut getriggert ist, oder ob es auf
Trigger normal steht und einfach nicht die Triggerbedingung erfüllt.
Mir persönlich würde es wesentlich besser gefallen den TFT in diesem
Fall zu löschen und das Signal erst beim erneuten Erreichen der normal-
Triggerbedingung wieder darzustellen.
Gruß, brunowe
P.S.: verfasst du einen dementsprechenden Kommentar in Sf- Tickets für
okilidokili?
@ Hayo
Zum Triggerproblem: das hast du missverstanden.
Der Normaltrigger löst nur aus wenn ein Triggerereignis kommt, das ist
völlig ok.
Aber: bei der beschriebenen Situation kommen dauern Triggerereignisse
und es passiert trotzdem nichts, erst wenn man zweimal Run/Stop drückt
oder nochmal an der Zeitbasis dreht werden die Triggerereignisse wieder
verarbeitet.
Für den Test wurde ein I2C Bus mit einer Realtime Clock verwendet, auf
dem dauernd was los ist, so dass also auch dauernd getriggert werden
müsste.
Gruß
Michael
Michael H. schrieb:
> Vergrault hier bloß nicht das Zugpferd des ganzen Firmwareprojekts!>> Vielleicht ist Hayo (wie mir) nicht klar, warum es so einen Aufwand> macht, die Änderungen einzupflegen. Generell ist es übrigens etwas> problematisch für Leute die der Software nicht so nahe stehen (damit> meine ich mich), das alles nachzuvollziehen. Trunk? Für mich heißt das> Kofferraum... Comitted? Was denn, ein Verbrechen?
trunk: Stamm
branch: Zweig
commit: festlegen ;)
>> Gruß> Michael
Grüße,
rowue
Hallo zusammen,
also die Triggerfunktion im Normal-Mode ist beim Tek ebenfalls exakt so
umgesetzt. Gibt es kein neues Triggerereignis, dann bleibt das Bild
solange stehen, bis ein neues Triggerereignis auftaucht. Im Auto-Mode
wird der Bildschirm jedoch bei Abwesenheit des Triggerereignisses
gelöscht.
Was jedoch hilfreich wäre, um die Verwirrung etwas zu entwirren:
Am Tek gibt es für den Triggermodus eine LED, anhand derer man erkennen
kann, ob der Trigger auf Normal oder auf Auto steht. Da es bei uns eine
solche LED nicht gibt, wäre vielleicht ein Eintrag in der oberen
Informationsleiste hilfreich? Ein einfaches "A" für Auto oder ein "N"
für normal würde ja schon reichen.
Meine Anmerkung hat jedoch nichts mit dem von Michael beschriebenem
Problem zu tun.
Beste Grüße, branadic
Das Kenntlichmachen des Triggers halte ich für eine gute Idee.
Von anderen Oszis (nicht nur Tek) kenne ich den Normalmodus des Triggers
übrigens genauso, wie er beim Welec umgesetzt ist, der passt definitiv
so wie er ist.
Nichtsdestotrotz bleibt aber das beschriebene Problem bestehen, ich
hoffe auf deutsch habt ihr es besser verstanden.
Achja: beim Start des Oszis steht der Trigger immer auf Auto, wenn er
sich die alte Einstellung merken würde, wäre das doch hübscher, oder?
@ Rolf: an meinem Englisch scheitert das ganze nicht, das Problem ist,
dass man sich unter all den Begriffen oft nichts vorstellen kann, wenn
man die dazugehörigen Tools noch nie verwendet hat. Da jetzt meine
Prüfungen rum sind, ein Platz für die Masterarbeit und wahrscheinlich
auch Arbeitsplatz für nachher gefunden ist, habe ich jetzt Zeit, mir
neben der Fertigstellung zweiter Studienprojekte das ganze mal
anzusehen.
Gruß
Michael
@Michael
Ok also er sollte eigentlich triggern, da die Triggerschwelle
überschritten ist, tut es aber nicht? Oder hast Du Grund zur Annahme,
dass er das Triggerereignis erkennt aber sich danach im Firmwaredickicht
verhaspelt?
Das kann ich leider erst zu hause überprüfen. Danke jedenfalls für die
Rückmeldung.
@Branadic
Tja die LED kann ich wirklich nicht nachprogrammieren, aber wird der
Triggermodus nicht oben rechts in der Statusleiste angezeigt? Ich meine
mich zu erinnern, dass dort im "Auto" Modus auch Auto eingeblendet wird.
@Falk
Wenn ich aus dem Urlaub zurückkomme wird sicherlich nicht mehr die 172
der aktuelle Stand sein, aber der dann aktuelle Stand wird dann die
Basis bilden. Ich werde dann auch bevor ich da was einbaue klären was
rein soll und was nicht.
Gruß Hayo
Hayo W. schrieb:
> @Michael>> Ok also er sollte eigentlich triggern, da die Triggerschwelle> überschritten ist, tut es aber nicht? Oder hast Du Grund zur Annahme,> dass er das Triggerereignis erkennt aber sich danach im Firmwaredickicht> verhaspelt?>> Das kann ich leider erst zu hause überprüfen. Danke jedenfalls für die> Rückmeldung.
Ja genau er sollte triggern, da der Bus munter vor sich in werkelt (das
habe ich mit meinem zweiten Oszi zusätzlich kontrolliert), tut es aber
nicht. Oder besser gesagt: zunächst klappt alles wunderbar, wenn ich an
der timebase drehe aber auf einmal nicht mehr. Ob das Problem am Trigger
oder sonstwo liegt, kann ich nicht sicher sagen, das Scope hat aber auf
alles normal reagiert, so dass ich schon auf den Trigger tippen würde.
Hayo hat Recht, der Triggermodus wird bereits oben eingeblendet (Auto
bzw. Norm).
Gruß,
Micahel
Hayo W. schrieb:
...
> @Falk>> Wenn ich aus dem Urlaub zurückkomme wird sicherlich nicht mehr die 172> der aktuelle Stand sein, aber der dann aktuelle Stand wird dann die> Basis bilden.
Mit etwas Glück wird Subversion das Einbauen sogar automatisch
erledigen.
> Ich werde dann auch bevor ich da was einbaue klären was> rein soll und was nicht.
Einbauen darfst Du natürlich alles, was Du willst. Nur das Ausbauen darf
sich gerne auf Bugs reduzieren ;-)
Falk
@Rolf und Michael,
ja wir haben definitiv nur 4 ADC pro Ch. Wie kommt ihr also auf eine
Verwürfelungsperiode von 8?
Ok, wir haben uns auf Skype da eben eine Erklärung zurecht gelegt, aber
dennoch bin ich auf eure Meinung gespannt.
Könnt ihr euch auch erklären warum die Verwürfelung nicht konstant gut
über die 16k Samples passt? Also wie oben festgestellt ab ca. Sample
2000 relativ gut.
Persönlich bin ich noch nicht so ganz von der Verwürfelung überzeugt,
zumindest nicht als alleinige Ursache.
Gruß, brunowe
Bruno We schrieb:
> @Rolf und Michael,>> [Verwürfelung]
Ich rechne gerade was durch, wenn ich mehr habe, sage ich Bescheid ;)
>> Gruß, brunowe
Grüße,
rowue
Hallo,
ich habe mal noch mit der Screenshotfunktion gespielt. Tolles
Werkzeug! Die Verwürfelung tritt soweit ich es erkennen kann
nur in den Bereichen mit 500 MS/s und 250 MS/s auf. In den
anderen sehe ich nichts davon.
Wenn der FPGA mit 400 MHz getaktet wird, kann der FIFO ja nicht
ein 1 GS/s aufnehmen. Da müssen also noch andere Tricks verwendet
werden, was die Fehlermöglichkeiten im Design erhöht. Die Zacken
sind da wohl nur die Spitze des Eisbergs.
Ich kann mit den CSV-Daten sogar die beobachte Schwebung ansehen.
Falls jemand die Möglichkeit hat: ein Signal mit ca. 62.5 MHz und
so kleiner Amplitude aufnehmen, dass noch keine extremen
Störungen sichtbar sind (+- 25 Schritte des ADC oder so). Dann in
der Darstellung nur jeden 4. Wert ansehen. Ich vermute, dass da ein
weiterer Takt ins Spiel kommt, der diese Schwebung erzeugt. Das
könnte der FIFO-Takt sein.
Gruß, Guido
Guido schrieb:
> Wenn der FPGA mit 400 MHz getaktet wird
Wird er nicht. Draußen ist ein 25MHz Quarz, drinnen wird vermutlich auf
125MHz hochmultipliziert, allerhöchstens auf 250MHz. Für den NIOS usw.
werden niedrigere Frequenzen verwendet werden, so 50-100MHz.
> kann der FIFO ja nicht> ein 1 GS/s aufnehmen. Da müssen also noch andere Tricks verwendet> werden
Ja, die Tricks sind z.B., dass wir vier 250MHz-ADC haben. Somit hast du
pro 250MHz-Takt 32 bit Samplewerte, je 8 von jedem ADC. Es gibt noch
mehr Tricks, die ich aber erst nachher erläutere, wenn die geschichte
mit der 4- vs. 8-Werte-Verwürfelung erklärt wurde, möchte nicht die
Ideen vorwegnehmen.
> was die Fehlermöglichkeiten im Design erhöht.
Ja, ich vermute sie aber woanders, nämlich an den Übergängen der Signale
von einer in die andere Clock Domain und evtl. an der Stelle, an der die
ADC-Werte eingelesen werden. Ich traue den Wittigs zu, sowohl die
Synchronisation falsch zu machen als auch die erste Stufe im FPGA mit
250MHz laufen zu lassen und dann die dabei entstehenden Timing-Probleme
zu billigen.
> Die Zacken> sind da wohl nur die Spitze des Eisbergs.
DAS hast du schön gesagt ;)
Grüße
Daniel
P.S.: Der Daniel, der hier als Daniel (Gast) firmiert, bin nicht ich!
Bruno We schrieb:
> @Rolf und Michael,>> ja wir haben definitiv nur 4 ADC pro Ch. Wie kommt ihr also auf eine> Verwürfelungsperiode von 8?
Ansonsten zu Verwürfelungsperiode von 8: mal 16 Werte (s.o.)
hintereinander:
25 30 63 63 88 91 118 117 77 81 106 105 132 135 162 161
Wenn Du Dir das ansiehst, wirst Du feststellen, dass die
Werte zwischen Index 5 (88) und 12 (105) innerhalb eines Intervalls
liegen. (Mein Testsignal, monoton steigend)
Wenn Du diese entsprechend (aufsteigend) anordnest und bei
Index 5 den ersten ADC setzt, kommst Du auf die o.g,
Vertauschung für 500MS/s.
Interessant dabei ist, dass jeweils zwei Messwerte sehr
dicht beieinander liegen (nahezu identisch sind).
Dafür gibt es jetzt zwei Erklärungen:
* zwei Messwerte werden sehr kurz hintereinander aufgenommen.
* zwei unterschiedliche Messungen alternierend gespeichert
(3A,3B,1A,1B,4A,4B,2A,2B) - wobei diese Messungen nicht
direkt aufeinander folgen.
Für Rauscheffekte ist es zu regelmässig.
Für mich stellt sich nun die Frage:
> Ok, wir haben uns auf Skype da eben eine Erklärung zurecht gelegt, aber> dennoch bin ich auf eure Meinung gespannt.> Könnt ihr euch auch erklären warum die Verwürfelung nicht konstant gut> über die 16k Samples passt? Also wie oben festgestellt ab ca. Sample> 2000 relativ gut.
Ich jage gleich noch mal die Daten mit dem Offset durch - vielleicht
hat es ja auch was damit zu tun - ansonsten könnte eine Mittelung
innerhalb eines Paares interessant sein ;)
>> Persönlich bin ich noch nicht so ganz von der Verwürfelung überzeugt,> zumindest nicht als alleinige Ursache.>
Also die Verwürfelung existiert. Ob dazu noch eine Mittelung oder
alternierende Speicherung kommt, ist eine andere Sache ;)
> Gruß, brunowe
Grüße,
rowue
Hähä,
> Ich traue den Wittigs zu, sowohl ...
ich traue denen auch zu mit 3 Latches zu arbeiten und das
vierte Byte direkt in den 32-Bit-FIFO zu leiten. Uund alles
asynchron?
Gruß, Guido
Rolf Würdemann schrieb:
> Bruno We schrieb:>> @Rolf und Michael,>>>> [...]> Dafür gibt es jetzt zwei Erklärungen:>> * zwei Messwerte werden sehr kurz hintereinander aufgenommen.> * zwei unterschiedliche Messungen alternierend gespeichert> (3A,3B,1A,1B,4A,4B,2A,2B) - wobei diese Messungen _nicht_> direkt aufeinander folgen.
Dritte Möglichkeit:
Zwei ADC's laufen bei 250/500MHz parallel und werfen
ihre Daten rein (Mittelung)
EDIT: MS/s - nicht MHz ;)
>>> Grüße,
Grüße^2,
>> rowue
So Leute,
ich glaub jetzt werd ich vollends verrückt. Ich wollte mal die Messung
von Rolf nachstellen.
Also dacht ich mir, der Speicher ist 16k lang, ich sample mit 1GS/s
(100ns/div), also legst mal schön ein 61kHz Dreiecksignal an, dann
solltest du ja im besten Fall sauber eine Periode im Speicher haben.
Haha... weit gefehlt, zehn sind es! (siehe Bild)
Bei 500MS (2µs/div) sind es dann entsprechend 20 und bei 250MS (5µs/div)
sogar 40.
geht gleich weiter...
Also hab ich bei 500MS die Frequenz halbiert und bei 250MS dann noch mal
halbiert. So sind es in allen drei Bereichen 10 Perioden. (siehe Bild)
Bin ich blöd, ist mein Oszi defekt?
Kann das bitte mal jemand nachprüfen?
Beste Grüße, branadic
Rolf Würdemann schrieb:
> Bruno We schrieb:>> @Rolf und Michael,>>>> [...]> Für mich stellt sich nun die Frage:>> Ok, wir haben uns auf Skype da eben eine Erklärung zurecht gelegt, aber>> dennoch bin ich auf eure Meinung gespannt.>> Könnt ihr euch auch erklären warum die Verwürfelung nicht konstant gut>> über die 16k Samples passt? Also wie oben festgestellt ab ca. Sample>> 2000 relativ gut.>> [...]
Also: Ich habe eben mal gewürfelt und gemittelt, eine Rechnung steht
vor meiner schlussendlichen Antwort noch aus ;)
Zu dem Problem mit der verspäteten Konvergenz, so habe ich hier ein
Bild, bei der ab ca. Sample 1000 mein "eigentliches Signal" anfängt,
davor habe ich "rubbish".
Ein entsprechendes Bild kenne ich auch von der Orginal-FW bei
Datentransfer per USB. Dazu hatte ich im Source mal was davon gelesen,
dass eine Position angegeben wird, aber der das Signal "anfängt".
Um nun mit dem "PreTrigger" arbeiten zu können, müssen die Daten
kontinuierlich in den Speicher gesampelt werden.
Evtl. handelt es sich bei den Daten bis Index 2000 noch um den
Rest von den Daten dahinter (und bedenken: ich verwende noch einen
kleinen Offset ;)
Grüße,
rowue
Die letzte Rechnung verlief leider etwas unbefriedigend :(
Aber für alle, die sich gerne mal ein Bild mit Verwürfelung
ansehen möchten habe ich mal ein Bild der steigenden Flanken
mit Verwürfelung beigefügt.
Aus diesen Daten müsste sich generell die Abtastperiode bestimmen
lassen. Wir haben eine definierte Steigung, wir haben Abtastwerte
und den Faktor zwischen Abtastwerten und Spannung.
Leider komme ich bei der Samplefrequenz von 500MSa/s auf eine
Abtastperiode von
und bei 250MSa/s auf eine Abtastperiode von
Der angegebene Fehler stellt den statistischen Fehler
meiner Messpunkte dar.
Ich schau mir da morgen noch mal andere Daten an, ansonsten
müsste ich den Messaufbau nochmal verfeinern ;)
n8 ;)
rowue
branadic schrieb:
> So Leute,>> ich glaub jetzt werd ich vollends verrückt. Ich wollte mal die Messung> von Rolf nachstellen.> Also dacht ich mir, der Speicher ist 16k lang, ich sample mit 1GS/s> (100ns/div), also legst mal schön ein 61kHz Dreiecksignal an, dann> solltest du ja im besten Fall sauber eine Periode im Speicher haben.>> [...]
Was aber nicht mein Ansatz ist ;)
* Der ADC-Wandler hat 255 Intervalle(!)
Diese werden auf den Spannungsbereich 8 V/DIV aufgeteilt
* Es existieren eine Anzahl n (hoffentlich) äquidistante
Abtastpunkte
* Nun gilt es ein Zusammenspiel von Eingangs-Signal und
Einstellung des Vorverstärkers zu finden, bei denen
zwischen Min (0) und Max (255) etwa 16 - 50 Abstastpunkte
liegen. Desto weniger, desto besser. 16(15) stellt dabei
einen unteren Grenzwert dar. (50 ist schon bald tödlich)
Der Hintergrund hierbei ist, den Spannungssprung zwischen
den Abtastpunkten möglichst gross zu halten um Rauscheffekte
zu minimieren. (Zeitdiskretes Signal)
* Ein Signal mit einem linearen Anstieg hat dabei den Vorteil,
dass die Abtastperiode relativ einfach zurückgerechnet
werden kann, ohne z.B. den Sinus wieder rausfalten zu
müssen. (Wobei die Annahme gemacht wird, dass die
Eingangsverstärker selbst linear sind ;)
* Bei der Messung sollten Einstellungen für die Eingangsverstärker
verwendet werden, welche möglichst rauscharm sind ;)
Wie oben beschrieben/gezeigt, scheint die Würfelfolge zu stimmen,
allerdings weicht die ermittelte Abtastperiode doch etwas sehr
stark vom Erwartungswert ab. (2ns, 4ns)
Ich werde mir das morgen mal mit anderen Daten (aus einer Messung
mit dem nächst empfindlicheren Spannungsverstärkung) ansehen. Wenn
die Daten hier auch nicht stimmen, werde ich die Messung mit einem
verfeinerten Messaufbau wiederholen.
Falls jmd. (z.B. mit einem W202XA) die Messung wiederholen möchte,
wäre das sehr cool.
>> geht gleich weiter...
Grüße,
rowue
@branadic
>So Leute,>ich glaub jetzt werd ich vollends verrückt.
Das habe ich vor drei Wochen auch schon bemerkt, dass da was faul ist.
Dachte aber, ich wäre das Problem. Habe damals den Screenshot mit dem
internen Rect-Generator getestet. Auf dem Bildschirm waren es zwei
Perioden. In OpenOffice mit den CVS dann ne ganze Nummer mehr...,
Leider kann ich dazu gerade wegen Prüfungen nichts beitragen.
Gruß,
Stefan
@ Thomas O. (kosmos)
Ich speichere, wie du richtig festgestellr hast CSV-Dateien und lade sie
anschließend in QTOctave und plotte sie dort^bzw. bearbeite sie dort.
@ Rolf Würdemann (rowue)
es ging mir darum, wie du es auch gemacht hast, eine Rampe aufzuzeichen,
um nach Regelmäßigkeiten Ausschau zu halten. Dazu sollte mir eben das
61kHz Dreiecksignal dienen. Man hätte erwartet, dass eine Periode im
Speicher liegt, dem ist aber offensichtlich nicht so.
Auf das, was mir auf dem TFT angezeigt wird verlasse ich mich nicht
mehr. Solange im Samplespeicher nicht das erwartete liegt ist was faul.
Für mich schaut es so aus: 10Perioden à 100MS sind nicht gleich 1GS. Was
passiert hier also?
@ Stefan E. (stefan_e)
schade, dass du nicht schon eher geschrieben hast, dass dir da
irgendwelche Unregelmäßigkeiten aufgefallen sind. Dann wären wir
vielleicht schon drei Wochen weiter :(
Jetzt noch einmal die Frage an die Kollegen, die die
Screenshot-Funktionen möglich gemacht haben. Welche Daten lest ihr aus?
Ist das wirklich der Speicher, der aus dem FIFO heraus gefüttert wird?
Nicht das wir einer Finte hinterher jagen.
Beste Grüße, branadic
branadic schrieb:
...
> Jetzt noch einmal die Frage an die Kollegen, die die> Screenshot-Funktionen möglich gemacht haben. Welche Daten lest ihr aus?
Die Daten aus SIGNAL1[]...SIGNAL4[].
> Ist das wirklich der Speicher, der aus dem FIFO heraus gefüttert wird?
Ich versuche gerade, das herauszufinden... Vielleicht will noch jemand
einen Blick auf Hardware::ReadOut_Signal werfen? Da sehe ich noch einen
"readout_sigbuf", in den 4096 longs gelesen werden (oder so...)
hardware_t.cpp:5219. Danach wird auch Hardware::READADC_ALL aufgerufen.
Assembler....
> Nicht das wir einer Finte hinterher jagen.
Ich kann leider noch nicht testen :-(
Hi Leute,
ich verfolge seit geraumer Zeit eure Arbeit und bin sehr beeindruckt !
Tolle Arbeit von allen Beteiligten !!!!!!
Leider habe ich noch nicht das DSO, aber hoffentlich bald...
Eine großes Problem im Augenblick ist den Fehler eindeutig einzugrenzen.
Ist er im Digitalteil( FPGA) oder im Analogteil zu suchen.
Auch die AD-Wandler könnten einen potentielle Fehlerquelle darstellen
(Timing Probleme).
Hab leider noch keinen Zeit gefunden, mir den Schaltplan zu Gemüte zu
führen, aber wäre es nicht denkbar, den digitalen Teil der AD Wandler
durch z.B ein FPGA zu simulieren ??
Dann wäre man in der Lage, eindeutig den Fehler einzugrenzen.
Leider bin ich kein FPGA Freak, aber ich könnte mir vorstellen, das im
entsprechenen Forum, ein Experte in der Lage wäre, dies mal "schnell" zu
coden.
Noch Allen einen schönen Tag
Gruß
Siegmar
siegmar schrieb:
> Dann wäre man in der Lage, eindeutig den Fehler einzugrenzen.> Leider bin ich kein FPGA Freak, aber ich könnte mir vorstellen, das im> entsprechenen Forum, ein Experte in der Lage wäre, dies mal "schnell" zu> coden.
Das wäre möglich, aber der elektrische Aufwand ist hoch. FPGA sind eben
leider doch keine Mikrocontroller ("Saft drauf und los").
Falk Willberg schrieb:
> branadic schrieb:>> ...>>> Jetzt noch einmal die Frage an die Kollegen, die die>> Screenshot-Funktionen möglich gemacht haben. Welche Daten lest ihr aus?>> Die Daten aus SIGNAL1[]...SIGNAL4[].
...
Das scheinen nicht die rohen ADC-Werte zu sein....
Falk
Hallo zusammen,
ich verfolge die Diskussion schon eine Weile und mir ist dabei folgender
Gedanke gekommen:
Wie sind die vier ADCs denn an den Output des letzten AD8131 angebunden?
Gibt es hier eine Entkoppelung? Leider sehe ich das im Schaltplan nicht
oder ich habe das richtige PDF noch nicht gefunden.
Langer Rede kurzer Sinn: Wenn die ADC-Inputs irgendwie entkoppelt sind,
könnte man alle vier übersteueren (so dass sie möglichst Rauschfrei 0xFF
liefern) und dann einen künstlich auf eine geringere Spannung
(idealerweise 0V) ziehen. Das dürfe im Speicher doch ziemlich schnell
zeigen wo die Daten dieses ADCs landen. Damit könnte man die aktuelle
Verwürfelungsvermutung absichern.
Oder übersimplifiziere ich das Problem jetzt?
Gruß
Daniel
Hallo Daniel G,
die einzelnen ADC sind leider nicht "entkoppelt". D.h. der Ausgang des
letzten AD8131 (genauer gesagt die Ausgänge- wg. differentieller
Ansteuerung) gehen parallel an alle 4 ADC. Ohne große Löterei (und das
will ich bei dem Pinabstand mal besser lassen) ist dein Vorschlag nicht
durchzuführen.
Gruß, brunowe
Hallo Bruno We,
hm... gibt es denn ein Schaltbild der Umgebung der ADCs? Ich würde mir
deren Außenbeschaltung gerne mal ansehen. Evtl. gibt's es einen anderen
Weg ein "eindeutiges" Signal auf den Weg zu bringen...
Gruß
Daniel
Hallo,
Daniel G. schrieb:
> deren Außenbeschaltung gerne mal ansehen. Evtl. gibt's es einen anderen> Weg ein "eindeutiges" Signal auf den Weg zu bringen...
man könnte die Referenzspannung der einzelnen ADCs modifizieren.
D.h. Nutzsignal ist DC > 0 und dann durch verringern der Ref-V
eines einzelnen ADCs bei diesem einen klar größeren Output erzeugen.
Gruß,
Günter
Das ist ja spannender als ein Thriller hier!
Weil im Moment doch recht viele kluge Köpfe an den Problemen knobeln,
bin ich recht zuversichtlich, dass es bald den einen oder anderen
Durchbruch geben wird. Wer hätte gedacht dass ein völlig fehlerhaftes
Produkt solchen Spaß machen kann?
Da ich jetzt eine Woche "Heimaturlaub" mache, wird sich meine
Beteiligung wohl fürs Erste auf das Mitlesen beschränken, ohne Oszi und
eigenen PC kann ich sonst wohl nicht viel beitragen.
Gruß,
Michael
>Falk Willberg schrieb:>> branadic schrieb:>>>> ...>>>>> Jetzt noch einmal die Frage an die Kollegen, die die>>> Screenshot-Funktionen möglich gemacht haben. Welche Daten lest ihr aus?>>>> Die Daten aus SIGNAL1[]...SIGNAL4[].>...>Das scheinen nicht die rohen ADC-Werte zu sein....
Hab mal eine Version des letzten SVN stands (173) so umgebaut, das mit
den Test switch 1 (SHIFT S) die Rohdaten in SIGNAL1[]..SIGNAL4[] landen.
Anbei das entsprechende TomCat.ram
Scheint keine grosse Differenz zu sein.
Martin
Hall Günter,
du hast mich da auf eine Idee gebracht. Lt. Datenblatt wäre Pin 68 des
MAX1121 eine Möglichkeit. Dieser legt das Ausgabeformat fest. Wenn er
auf 0 liegt, wird der Wert als Zweier-Komplement ausgegeben, bei 1 als
normaler Binärwert. Der Pin hat einen internen Pulldown. Wenn er im
Scope unbeschaltet ist (weil Wittig sich hier auf den Pulldown verlassen
hat) so könnte man über diesen Pin einen der Wandler von
Zweier-Komplement auf Binär-Output umschalten. D.h. bei positiven
Vollausschlag würde der Wert von 0111 1111 auf 1111 1111 springen. Das
wäre doch eine gut zuordenbare Veränderung, oder?
Gruß
Daniel
> Scheint keine grosse Differenz zu sein.
Berichtige:
Jetzt verstehe ich weshalb da zwischen Highspeed und Lowspeed
unterschieden wird! Mit den Rohdaten wird bei lowspeed sichtbar das da
immer alle 4 AD's ausgelesen werden (wobei die angezeigte Samplerate
einem einzelnen AD entspricht, die Daten werden dann so umgeschichtet
das sie in 4 x 4K bloecken fuer die 4 AD's hintereinander liegen (das
bedeutet das wir hier in wirklichkeit nur 4K Speicher tiefe haben!)
Martin
Hallo Falk,
die Werte in Signalx sind schon in READADC_ALL vorverarbeitet, d.h.
Offsetkorreektur, ev. Invertierung und Averaging. Ich habe versucht
das in C umzuschreiben, Hayo hat das in ADC_ReadData umbenannt. Ev.
wird da die Funktion leichter zu erkennen sein als im Assemblercode.
Für die lamgsamen Zeitabsen ist das wieder falsch (mein Fehler),
für die schnellen hoffe ich, dass es dasselbe macht wie ADC_READALL.
Ich probiere mal branadics Messung nachzuvollziehen, das kling
interessant.
Gruß, Guido
Hallo Martin,
so habe ich das auch interpretiert und in C umgesetzt. Die
Umschichtung muss wirklich stattfinden, aber ob das was mit
der Zahl benutzter ADCs zu tun hat? Da bin ich mir nicht mehr
sicher, muss noch ausprobiert werden.
Gruß, Guido
Hallo Daniel,
Daniel G. schrieb:
> du hast mich da auf eine Idee gebracht. Lt. Datenblatt wäre Pin 68 des> MAX1121 eine Möglichkeit. Dieser legt das Ausgabeformat fest. Wenn er> auf 0 liegt, wird der Wert als Zweier-Komplement ausgegeben, bei 1 als> normaler Binärwert. Der Pin hat einen internen Pulldown. Wenn er im> Scope unbeschaltet ist (weil Wittig sich hier auf den Pulldown verlassen> hat) so könnte man über diesen Pin einen der Wandler von> Zweier-Komplement auf Binär-Output umschalten. D.h. bei positiven> Vollausschlag würde der Wert von 0111 1111 auf 1111 1111 springen. Das> wäre doch eine gut zuordenbare Veränderung, oder?
sehr gute Idee, damit würde ein wandernder Pullup (ständiges umlöten
:-()
oder eventuell eine Verbindung von vier freien Schieberegister-Ausgängen
zu diesem Pin (die Schieberegister die auch z.B. für die
Bereichsumschaltung
da sind) eine eindeutige Unterscheidung eines spez. ADCs ermöglichen.
Gruß,
Günter
Guido schrieb:
> Hallo Falk,>> die Werte in Signalx sind schon in READADC_ALL vorverarbeitet, d.h.> Offsetkorreektur, ev. Invertierung und Averaging. Ich habe versucht> das in C umzuschreiben, Hayo hat das in ADC_ReadData umbenannt.
Ich muß am Datenexport sowieso ein wenig ändern. Ich habe zum probieren
mal ein pre-pre-pre-088 in http://falk-willberg.de/tmp/pre-088/
abgelegt.
Vielleicht lagere ich da künftig meine nicht-kaputten "Kompilate" ;-)
Falk
Hallo branadic,
sehe gerade deine Versuche von gestern mit 61,5kHz und 1,2 4 Perioden
usw. Ich habe das mal nachgestellt und nichts da! Passt in der 0.86 beim
W2024A recht genau! Ist zwar fast kein Dreieck mehr vom
"Eigenbau-S12-Controller DDS", aber was solls! Im Anhang die
500MS/s-.csv.(Hab hoffentlich die richtige erwischt). Es sind auf jeden
Fall nicht 10 Perioden.
Gruß Jürgen
Hallo Daniel G.
nein einen Schaltplan von der ADC Umgebung und dem FPGA- Part gibt es
nicht- da hat sich noch keiner ran getraut ;-)
Hier wurden ja wirklich schon tolle Vorschläge zur Identifizierung der
einzelnen ADC gemacht, Respekt.
Die ADC- Vorspannung wird mit/am letzten AD8131 (U12) erzeugt, die
Ansteuerung ist hier zu finden:
http://welecw2000a.sourceforge.net/docs/schematics/Analog-Input-Part_assignment_V3_3.pdf
Diese Vorspannung ist für alle 4 ADC und alle Kanäle die Gleiche.
Lötungen direkt an den einzelnen ADC sind schon recht heikel... Evtl.
finden wir ja doch noch eine Antwort auf SW- Basis.
Ansonsten halte ich die Möglichkeit mit dem Zweier-Kompl. über Pin68 der
ADC durchaus für gangbar.
Dann hab ich heute auch mal versucht, das von branadic und Stefan E.
beschriebene Phänomen, der falschen Anzahl von im Speicher hinterlegten
Perioden nachzustellen. Zum Glück ohne Erfolg!
Als Anlage ein paar Bildchen zum ansehen. Wie gesagt, ich konnte
keinerlei Unregelmäßigkeiten feststellen. Auffallend ist aber, das
teilweise fast der gesamte Speicherbereich auch am TFT dargestellt wird.
D.h. die Speichertiefe nur eine unwesentlich längere (zeitl. gesehen)
Aufzeichnung zulässt als am TFT dargestellt.
Selbstverständlich werden für die TFT Anzeige eine Menge
"Zwischensamples" weggelassen (oder gemittelt- denoising) um auf die
600Px Darstellungsmöglichkeit unseres TFT zu kommen.
Gruß, brunowe
Hallo,
ja, branadics Messung kann ich auch nicht bestätigen. Ist wohl
mal nach "Wer misst, misst Mist".
Sieht mir aus, als ob in den langsamen Bereichen doch alle 4
ADCs benutzt werden. Ich meine eine kleine Offsetverschiebung
zu erkennen, wobei die Korrektur bei meiner Firmware für alle
Datenpunkte dieselbe ist.
Gruß, Guido
Hallo zusammen,
> ja, branadics Messung kann ich auch nicht bestätigen. Ist wohl
mal nach "Wer misst, misst Mist".
danke für die Blumen, aber ein 61kHz-Signal bekomme ich gerade noch
gebacken zu messen :)
Motiviert durch die heutigen Beiträge habe ich mein Oszi mal komplett
zurück gesetzt (komplettes Backup inkl. der Protected Bereiche) und die
FW0.86 erneut aufgespielt.
Jetzt passt es auch bei mir. Scheint, als hätte sich da irgendwas
verabschiedet, was auch immer da passiert gewesen sein mag. K.A.!
Damit wäre dieser Fehler von der Liste gestrichen und ein solcher Effekt
mal für die Nachwelt und eine Lösung dafür festgehalten.
Beste Grüße, branadic
Ich finde die Idee mit der Rampe und einer Periode beim zweiten
Nachdenken gar nicht so schlecht - allerdings mit einigen
Modifikationen:
* Test-Signal mit ~122 kHz (Halbe Periode)
* Das Signal wird so eingestellt, dass es gut in
einen Messbereich passt (Vollausschlag ;)
* Dann wird Der Messbereich um Faktor 1000 verkleinert
(V -> mV)
Somit sollten wir dann ~16 Samples haben, die innerhalb des
Intervalls [2:253] (grob) liegen. Der Rest überschreitet unseren
Messbereich.
An diesen ~16 Werten dürte sich einiges ablesen lassen ;)
Am besten ohne Bandbreitenbedämpfung, Denoising - ich frage mich
eh gerade schon, ob dass unserer Vorverstärker "so" mitmacht
(oder die 5ns nicht von diesem kommen ;)
Hat wer Lust? ;)
Grüße,
rowue
EDIT: /me möchte heute Abend mal Messpause machen ;)
branadic schrieb:
> Hallo zusammen,>>> [Messung]>> Motiviert durch die heutigen Beiträge habe ich mein Oszi mal komplett> zurück gesetzt (komplettes Backup inkl. der Protected Bereiche) und die> FW0.86 erneut aufgespielt.> Jetzt passt es auch bei mir. Scheint, als hätte sich da irgendwas> verabschiedet, was auch immer da passiert gewesen sein mag. K.A.!>> Damit wäre dieser Fehler von der Liste gestrichen und ein solcher Effekt> mal für die Nachwelt und eine Lösung dafür festgehalten.
Den Fehler sollten wir mal im Auge behalten - gerade Runtime-Errors
und Systeme, die sich dann irgendwann undefiniert verhalten sind
was fieses ....
Hast Du Lust da ein Ticket einzutüten? ;)
>> Beste Grüße, branadic
Grüße,
rowue
Hallo Rolf,
da ich mich mit dem Ticketsystem bisher noch nicht auseinander gesetzt
habe, überlasse ich das lieber mal jemandem, der sich damit auskennt :)
Zu deiner vorherigen Meldung, du meinst wahrscheinlich nicht 122kHz
sondern 30,5kHz.
Ich hab da mal schnell zwei CSV-Dateien mit eben diesen erstellt. Der
OPV hat es überlebt :)
Einmal mit Bandbreitenbegrenzung (mBW) und einmal ohne (oBW). Darfst
dich an den Daten gerne austoben.
Magst du nicht auch zu uns ins Skype kommen? Dann könnte man in Echtzeit
kommunizieren. Findest nicht nur den Falk dort, sondern auch BrunoWE,
Daniel (crazor) sowie mich (mister_pocher) und ganz langsam wächst die
Gruppe, weil sich doch ab und an jemand überwinden kann. Um schnell mal
Info's auszutauschen ist diese Plattform eher ungeeignet.
Beste Grüße, branadic
Also da kaum einer seine Input-Stufen um den Faktor 1000 übersteuern
möchte, hier mein Vorschlag:
Nehmt doch einfach ein möglichst gutes (steilflankiges) Rechtecksignal-
Flanke idealerweise 16Px breit, skaliert das Oszi entsprechend damit ihr
einen möglichst grossen ADC Bereich mit dem Rechteck überstreicht und
schon sollten die einzelnen ADC- Werte (16Stck) der Flanke ihre
Verwürfelung zeigen.
Gruß, brunowe
Mal was anderes. Wenn wirklich beim Übergang der Taktdomänen oder
schlimmer noch: Beim Timing der 250 MHz Domäne Mist gebaut wurde, kann
man dann zuverlässig (über alle Geräte/Toleranzen/Temperaturen) sagen in
welcher Reihenfolge die Samples anliegen und ob alle Bits richtig sind?
Meinem Verständnis nach eher nicht, weil es nicht definiert ist, was ein
FF macht oder wann es das macht, wenn die SU oder Hold Zeiten verletzt
werden.
Wer seine Hardware ein bischen quälen will: Durch hohe Spannung oder
tiefe Temperaturen verkürzen sich die Gatterlaufzeiten. Also zückt das
Kältespray ;-D.
Gibt es eine Möglichkeit, die 25 MHz Referenz durch 20 MHz oder so zu
ersetzen? Dann hätte man halt ein 800 MSPS Scope. Wenn es damit gut ist,
wäre zumindest der Fehler gefunden und als Lösung hilft nur noch ein
neues FPGA Design.
Hallo zusammen,
ich finde es Schade, dass der IRC-Channel zugunsten von Skype aufgegeben
wurde. Da ich zum Teil mit IT-Security mein Geld verdiene, kommt Skype
leider nicht in Frage. Ich hoffe Ihr publiziert die Ergebnisse euerer
Bemühungen hier im Forum. Über die parellele Möglichkeit eines
regelmäßigen IRC-Chats (z.B. jeden Freitag) würde bestimmt nicht nur ich
mich freuen...
PS: Ich muss mich wirklich mal im Tracker anmelden ;)
Gruß
Daniel
branadic schrieb:
> Einmal mit Bandbreitenbegrenzung (mBW) und einmal ohne (oBW). Darfst> dich an den Daten gerne austoben.
Merci - und mit den 30kHz hattest Du deutlich recht (5) ;)
> [Skype]
Naja - zu Skype siehe:
http://de.wikipedia.org/wiki/Skype#Kritik
Aber für Leute, die Jabber/XMPP machen gibt es auf
conference.jabber.ccc.de
einen Raum "welec" ;)
>> Beste Grüße, branadic
Grüße,
rowue ;)
Daniel G. schrieb:
> Hallo zusammen,>> [IRC/Skype]
Hi ... treibe mich jetzt auch Abends (wenn ich eh im IRC bin) auch
in #welec rum ...
Sonst - siehe letzten Post ;)
>> PS: Ich muss mich wirklich mal im Tracker anmelden ;)>> Gruß> Daniel
Grüße,
rowue
Daniel G. schrieb:
> Hallo zusammen,>> ich finde es Schade, dass der IRC-Channel zugunsten von Skype aufgegeben> wurde.
Wurde er nicht, es ist nur nichts los... Das würde sich ändern, wenn da
mehr Teilnehmer wären....
> Da ich zum Teil mit IT-Security mein Geld verdiene, kommt Skype> leider nicht in Frage.
Das kann ich gut verstehen, geht mir auch so. Da aber ein Kunde auf
Skype besteht, kann ich sowieso nicht darauf verzichten.....
Falk
Karl schrieb:
> Mal was anderes. Wenn wirklich beim Übergang der Taktdomänen oder> schlimmer noch: Beim Timing der 250 MHz Domäne Mist gebaut wurde, kann> man dann zuverlässig (über alle Geräte/Toleranzen/Temperaturen) sagen in> welcher Reihenfolge die Samples anliegen und ob alle Bits richtig sind?> Meinem Verständnis nach eher nicht, weil es nicht definiert ist, was ein> FF macht oder wann es das macht, wenn die SU oder Hold Zeiten verletzt> werden.
Ich hoffe nicht, dass die Entwickler dieses Gerätes solch schwerwiegende
Fehler gemacht haben ....
>> Wer seine Hardware ein bischen quälen will: Durch hohe Spannung oder> tiefe Temperaturen verkürzen sich die Gatterlaufzeiten. Also zückt das> Kältespray ;-D.
Wieso Kältespray? N2, liq.
>> [...]
Nabend zusammen,
mal noch as anderes:
In der Timebase 2ns/div sehe ich 25 Pixel, erwarten würde man 24, in der
Timebase 5ns/div zähle ich 67 Pixel, erwarten würde man 60. Noch weiter
zählen tu ich mir lieber nicht an.
Muss das so sein?
Beste Grüße, branadic
Hallo Karl,
> Gibt es eine Möglichkeit, die 25 MHz Referenz durch 20 MHz oder so zu> ersetzen? Dann hätte man halt ein 800 MSPS Scope. Wenn es damit gut ist,> wäre zumindest der Fehler gefunden und als Lösung hilft nur noch ein> neues FPGA Design.
Je mehr ich über diesen Vorschlag nachdenke, umso besser gefällt er mir.
Was kann schlimmstenfalls beim Austausch des Quarze 25MHz gegen einen
mit 20MHz passieren?
Die RS232 wird nicht mehr funktionieren, sämtliche auf die Zeitbasis von
25MHz ausgerichteten Vorgänge laufen langsamer (TB am Oszi stimmt nicht
mehr etc.). Wenn es dumm läuft, wird der TFT außerhalb seiner
Spezifikation betrieben und bleibt schwarz. (Halte ich eher für
unwahrscheinlich)
Verwendet wird als Zeitbasis übrigens ein QO 25,00MHz SMD 3,3V 7x5
Quarzoszillators (oder gleichwertig)- wer den Austausch wagt, darauf
achten das er ebenfalls einen mit 3,3V erwischt! (Bei mir ist keiner in
der Bastelkiste, schade!)
Der Austausch an und für sich sollte problemlos sein.
Gruß, brunowe
(P.S.: gehört ja fast schon in den HW Thread)
Das ist ja interessant: die Idee, den Quarz gegen 20MHz auszutauschen,
hatte ich in einem Gedankeblitz heute morgen auch,
aber aus anderem Grund:
Kann man an die 4*8 Ausgänge der ADCs Leitungen anbringen? dann könnten
wir einen LogicPort LA1034 dort anschließen.
Der kann mit max. 200 (10 x 20^^^) MHz extern getaktet werden. Dann
wüssten wir endlich, was hier wirklich gespielt wird.
Oder über einen gemeinsamen Taktgeber synchronisieren (wer weiß, welcher
Quarz im LA steckt?)
Ich kann es gar nicht mit ansehen, wie hier Kapital brachliegt:
der eine hat keinen vernünftigen Generator, der andere hat sein Oszi in
der Reparatur.
Deshalb möchte ich ebenfalls (m)einen Beitrag leisten und Fehlendes zur
Verfügung stellen, z.B. einen LA1034, ein
weiteres W20xx oder einen Generator (müsste ich erst besorgen).
Wo besteht Bedarf?
Hallo und guten Abend,
ich wollte heute mal herausfinden, was ich auf dem Bildschirm am Oszi
sehen kann und was dagegen tatsächlich im Speicher liegt.
Dazu habe ich ein 61kHz Sinussignal mit 500MS/s hergenommen und das mal
mit zu kleiner Spannungsbasis (50mV/div, Tastkopf 1:1) aufgenommen. Dann
als Bild exportiert und einmal als CSV-Datei.
Hier seht ihr, was auf dem Bildschirm vom Oszi angezeigt wird.
Gleich geht's weiter...
branadic schrieb:
> ... weiter geht es.> Tatsächlich schauen die exportierten Daten aus dem Speicher??? anders> aus, nämlich so...
Und? Die meisten Bildschirme/Grafikkarten haben Ihren
Koordinatenursprung
Oben-Links und zählen (leider) die Y-Achse positiv runter.
(An der X-Achse gespiegelte kart. Koordinaten) - Dein Plot-Programm
verwendet (wie fast alle mir bekannten Plot-Programme) das
kartesische Koordinaten-System wie wir es kennen ;)
Kann man in der Bildschirmausgabe sicher anpassen - kostet aber
Rechen-Zeit ....
>> Beste Grüße, branadic
Grüße,
rowue
Karl schrieb:
> Mal was anderes. Wenn wirklich beim Übergang der Taktdomänen oder> schlimmer noch: Beim Timing der 250 MHz Domäne Mist gebaut wurde,
Ich habe eine andere Theorie: Das passt alles ganz prima, aber:
Die Muster, die man zu erkennen glaubt, sind meistens 4 Perioden lang,
manchmal aber auch länger!
Ich habe mal ein Spektrum des CSV-Dumps der Rohdaten gemacht. Signal war
ein 5MHz Sinus mit ein paar Oberwellen. Die sieht man auch ganz prima.
Aber da ist auch noch ein Signal bei 89MHz. Und jeweils +/-5, +/-10 und
+/-15 MHz.
Ich bin sicher, daß 89MHz ein UKW-Rundfunksender ist und die Signale
daneben die Mischprodukte mit dem 5MHz Signal.
Wenn das Timing der ADCs so unsauber wäre, wie befürchtet, würden wir
dann so ein prima Spektrum bekommen?
Just my2¢,
Falk
Ich glaube nicht, dass man exakt sagen kann wie sich ein schlechtes
Timing auswirkt. Ist auch nur eine Vermutung und nachdem ich selbst
keins von den Dingern hab, der Vorschlag den Quarz zu tauschen.
Das mit dem UKW Sender und den Mischprodukten seh ich ein, aber hat der
auch die nötige Amplitude und Frequenz (4 oder 8 samples)? Ich glaube
nicht. Mach mal n Bild wo die Amplitude des 5 MHz Signals dargestellt
wird.
Karl schrieb:
> Das mit dem UKW Sender und den Mischprodukten seh ich ein, aber hat der> auch die nötige Amplitude und Frequenz (4 oder 8 samples)? Ich glaube> nicht. Mach mal n Bild wo die Amplitude des 5 MHz Signals dargestellt> wird.
Bittschön.
Falk
Danke :) Ist das Spannung oder Leistung? Egal. Wörst Käjs (TM) schätze
ich immer noch 30 dB Abstand raus. Das wird von den ADCs doch schon
garnicht mehr richtig aufgelöst und erklärt leider die Zacken nicht.
Was ich auch noch interessant finde: Clockjitter und nicht idealer
Abgleich ist super bei 250 MHz zu sehen. Nur so am Rande.
Was mich auf die nächste Idee bringt: Irgendjemand hat doch mal einen
Pin an den ADCs erwähnt, mit dem man signed/unsigned umschalten kann. Da
das Problem gern bei hohen Frequenzen UND hohen Pegeln auftritt,
vielleicht spricht da was über. Könnte man den nicht relativ niederohmig
auf den richtigen Pegel ziehen?
Karl schrieb:
> Wörst Käjs (TM)
Wurst-Käse? SCNR =)
Wegen der SVN-Plugins nochmal die Rückmeldung: Man kann jetzt zwar die
trac.ini per Admin-Interface bearbeiten, aber mit Plugins ist leider
momentan noch nix. Ist aber auch verständlich, dass die Jungs bei SF.net
nicht wollen, dass auf den Servern, auf denen Hunderte von
Trac-Installationen laufen, beliebiger Code ausgeführt werden kann.
Da die Ladezeiten in diesen Thread unerträglich geworden sind und dieses
Forum grundsätzlich keine geeignete Thread-Hierarchie ermöglicht, habe
ich einen deutschsprachigen Thread zum Thema PC-Software hier eröffnet:
https://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=3&t=18
Ich werde auch immer mal wieder im IRC (irc.freenode.net, #welec) sein
und gelegentlich, wenn ich viel Zeit habe ;-) hier hineinschauen.
Gruß,
Falk
Michael schrieb:
> Wie ist denn das Passwort für obigen Link?
Ups, das ist der für angemeldete Leser, der hier sollte das Lesen
erlauben:
http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=3&t=18> Muss man sich bei sourceforge anmelden, um die Beiträge zu lesen?
Nein nur zum Schreiben. Email-Adresse reicht. Ich habe für solche Zwecke
Spezialadressen, falls darüber doch mal Spam kommt. Die gibt's an jeder
Ecke kostenlos.
Falk
Heute um 21:00 MESZ werden sich Daniel und ich im IRC (irc.freenode.net,
#welec) über den von ihm vorgeschlagenen Auto-Updater unterhalten.
Mitdiskutanten sind willkommen.
Falk
Hallo
>ich einen deutschsprachigen Thread zum Thema PC-Software hier eröffnet:
Ohje.. :-(
Das wird die Leser und Schreiber reduzieren ... :-(
Beim Antworten im neuen Forum verlangt er ein Passwort :-(
Ich würde eher vorschlagen, auf den Mikrocontroller-Seiten zu bleiben
und den Thread vielleicht durchnummerieren...
Nach ca. 100 Beiträgen eine neue Thread-Nummer.
l.G. Roberto
Roberto schrieb:
> Hallo>>ich einen deutschsprachigen Thread zum Thema PC-Software hier eröffnet:> Ohje.. :-(> Das wird die Leser und Schreiber reduzieren ... :-(> Beim Antworten im neuen Forum verlangt er ein Passwort :-(> Ich würde eher vorschlagen, auf den Mikrocontroller-Seiten zu bleiben> und den Thread vielleicht durchnummerieren...> Nach ca. 100 Beiträgen eine neue Thread-Nummer.
Mein Vorschlag wäre, dass wir für Fehler/Auffälligkeiten eher
das Ticket-System nutzen (wobei wir dann auch Leute brauchen,
die sich um die Tickets kümmern). Damit werden Informationen
dann themenbezogen gesammelt (auch wenn dabei Infos "verloren"
gehen können (da muss dann die "Informationswiederbeschaffung"
ran ;)
>> l.G. Roberto
Grüße,
rowue
Roberto schrieb:
> Hallo>>ich einen deutschsprachigen Thread zum Thema PC-Software hier eröffnet:> Beim Antworten im neuen Forum verlangt er ein Passwort :-(
Meine Güte, dann melde Dich doch da an.
> Ich würde eher vorschlagen, auf den Mikrocontroller-Seiten zu bleiben> und den Thread vielleicht durchnummerieren...> Nach ca. 100 Beiträgen eine neue Thread-Nummer.
Warum sollen wir das so furchtbar kompliziert machen, wenn es eine
saubere Lösung gibt?
Falk
P.S.: http://sourceforge.net/projects/welecw2000a/files/
>Vielleicht kann Roberto nur den Sinn einer Anmeldung nicht erkennen?
Sehe ich auch so: Wir haben hier eine wunderbare Plattform um unsere
Gedanken auszutauschen. Mit mehr Plattformen kommen keine weitere
Ideen dazu. Das einzige Argument gegen diesen Thread ist der Nachteil
für Leute die neu dazukommen. Da müsste mal jemand einen Artikel im
Wiki anfangen.
Gruß, Guido
Hallo,
> Wir haben hier eine wunderbare Plattform um unsere Gedanken auszutauschen.
Also bitte, wo ist den das ein gutes Forum?
Ein paar Vorteile von SF?
- Ziemlich uneingeschränkte Verwaltungsmöglichkeiten sämtlicher Foren
und Threads.
- Fast uneingeschränkte Möglichkeiten des Up- und Downloads. (Also nicht
nur eine Upload pro Post!)
- Suchfunktion, z.B. nur neue Threads/ nur neue Posts anzeigen usw.
- Keine im NET verstreuten Quellen für VHDL FW PC Software/ Sourcen und
Foren/ Diskussion.
- Integriertes Wiki und Ticketsystem mit vielfältiger Adminmöglichkeit,
Möglichkeit der Mailinglist.
- Internationale Bekanntheit von SF, internationale Leserschaft.
- Eigener Projektbereich nur für Welec Belange (Hier im Forum gehen die
Beiträge in der Masse unter)
- Spamfilter bei SF...
Ich hab ja keine Ahnung was ihr alle für Geheimnisse habt, das ihr euch
so gegen eine Anmeldung bei SF sträubt, dazu reicht die Angabe einer
Email-Adr. Auf jeden Fall hab ich von dort noch nie eine Spam- Nachricht
erhalten. Ich bevorzuge es, wenn ich weiß mit welchen Leuten im Projekt
ich es zu tun habe und diese ggf. kurzfristig per Email erreichen kann.
Auch gibt es dann keine Verwirrung mehr mit drei gleichen (nicht
angemeldeten Michaels, Alexanders, Daniels...) so wie in diesem Forum.
Gruß, brunowe
P.S.
Die eigentlichen Absprachen, Tests etc. sollten sowieso mittels Skype,
ICQ oder einem ähnlichen Medium durchgeführt werden. Die Response-
Zeiten in einem Forum sind dazu einfach unbrauchbar!
Falk Willberg schrieb:
> Roberto schrieb:>> Hallo>>>[...]>> Falk> P.S.: http://sourceforge.net/projects/welecw2000a/files/
Hi Falk,
hast Du Lust, den Stand einmal in "tags" zu kopieren? ;)
Grüße,
rowue
Rolf Würdemann schrieb:
> Falk Willberg schrieb:>> Roberto schrieb:>>> Hallo>>>>[...]>>>> Falk>> P.S.: http://sourceforge.net/projects/welecw2000a/files/>>> Hi Falk,>> hast Du Lust, den Stand einmal in "tags" zu kopieren? ;)
Wie macht man das am Besten mit den Kommandozeilentools?
Falk
P.S.: Da die w2000a-screenshot.exe immer einen Blindflug für mich
bedeutet, könnte die mal jemand kompilieren und testen, der Windows
benutzt?
Hallo zusammen, hallo Falk,
ich habe heute noch mal Messungen am Rhode & Schwarz Signalgenerator mit
dem DSO gemacht. Signalquelle war ein Sinus von 1V Amplitude direkt mit
einem 50 Ohm-Kabel plus Abschlusswiderstand an das DSO gehängt.
Auffällig ist, dass ein 17 MHz-Signal noch gut ausschaut, bei etwa 18
MHz beginnen die ersten Ausreißer, um dann bei noch höheren
Signalfrequenzen in Datenfasching auszuarten.
Der Export der vermeintlichen Roh-Daten ist keiner, zumindest nicht laut
den bisher von mir ausgewerteten Signalen.
Hab extra jedes Signal einmal mit dem Parameter -d und einmal mit dem
Parameter -t exportiert.
Warum ist erklär ich mir wie folgt, auch wenn ich nicht so tief in der
Hardware des Gerätes drinstecke.
Das Programm ließt den Speicherinhalt aus. Da aber nur einmal 16k pro
Kanal vorhanden sind, müssen die korrigierten Daten folglich wieder in
denselben Speicher geschrieben werden.
Das heißt, es braucht, um Aussagen treffen zu können was mit den Daten
geschieht, eine Firmware Version, bei der die Rohdaten von Kanal 1
meinetwegen im Speicher von Kanal 1 abgelegt werden und die korrigierten
Daten im Speicher von Kanal 2.
Was sich aber anhand der Bilder abzeichnet ist, dass aus irgendeinem
Grund noch Fragmente im Speicher liegen, die zu den Lötzinn führt, den
man auf dem Bildschirm sehen kann.
Ich demonstriere das mal an obigem Bild mit Messungen von heute:
Man sieht der Reihenfolge die ersten 256 Werte aus dem Speicher eines
10MHz, eines 20MHz, eines 30MHz und eines 40MHz-Signales.
Beim 10MHz-Signal erkennt man leichte Treppenstufen, schon beim
20MHz-Signal jedoch erkennt man irgendwelche Datenfragmente. Das könnten
sein:
- Reste von vorherigen Aquisitions?
- Fehler aufgrund falsch überschriebenem Speicherinhalts?
- Fragmente, die aufgrund des Triggers entstehen?
Jedenfalls werden diese bei 30MHz und 40MHz stärker, bis irgendwann, mit
zunehmender Signalfrequenz, nur noch Lötzinn im Speicher steht.
Wo dieser Datenmüll entsteht, kann ich daher leider mit meinen Messungen
momentan nicht sagen, weil ich die Rohdaten aus dem ADC eben leider doch
nicht anschauen kann.
Daher wäre eine modifizierte FW mit den oben aufgeführten Änderungen
äußerst wünschenswert, damit wir die Ursache ein für allemal festnageln
können.
Ich hoffe ein wenig zur Aufklärung beigetragen haben zu können.
Hallo baranadic,
Mit dem FPGA Design, das ganz offensichtlich was falsch macht (was das
ist ist sehr schwer zu sagen) ist es leider nicht moeglich die
eigentlichen ADC daten auszulesen. Die SW hat nur Zugriff auf einen 16k
Speicher der schon die fehlerhaften Daten enthaelt.(wenn du die pseudo
Rohdaten sehen willst empfehle ich dir meine TomCat.ram von 29.07.2009
16:32 wo du mit dem Test-switch 1 (SHIFT-S) zwischen "Rohdaten" und vor
verarbeiteten Daten umschalten kannst.
Martin
Martin H. schrieb:
> Hallo baranadic,>> Mit dem FPGA Design, das ganz offensichtlich was falsch macht (was das> ist ist sehr schwer zu sagen) ist es leider nicht moeglich die> eigentlichen ADC daten auszulesen. Die SW hat nur Zugriff auf einen 16k> Speicher der schon die fehlerhaften Daten enthaelt.
Jein:
http://sourceforge.net/apps/trac/welecw2000a/wiki/ADC-FIFO-from-Firmware
Falk
Hallo
Ich hätte mal ne Frage/Bitte vielleicht könnte ja mal jemand der hier
noch Überblick hat den Thread in nem Wiki Artikel zusammen fassen? (So
wie zb beim miniLA
lg Michael
Falk Willberg schrieb:
> Martin H. schrieb:>> Hallo baranadic,>>>> Mit dem FPGA Design, das ganz offensichtlich was falsch macht (was das>> ist ist sehr schwer zu sagen) ist es leider nicht moeglich die>> eigentlichen ADC daten auszulesen. Die SW hat nur Zugriff auf einen 16k>> Speicher der schon die fehlerhaften Daten enthaelt.>> Jein:> http://sourceforge.net/apps/trac/welecw2000a/wiki/ADC-FIFO-from-Firmware>> Falk
Das ist genau das was ich meine, meine test SW gibt den "roh"
ausgelesenen Buffer ohne nach Verarbeitung aus (als ausgelesen mit der
Funktion aus dem wiki). Leider enthalten diese Daten auch schon die
Fehler, daher bleibt nur das FPGA Design als Fehlerquelle uebrig.
Martin
Vielleicht hier noch einmal der Hinweis an alle... es handelt sich bei
dem Softcore um einen NIOS I und nicht wie weitläufig angenommen um
einen NIOS II.
Diese Aussage ist auch nicht aus der Luft gegriffen, sondern stammt von
Altera selbst aus dem Telefongespräch, das ich wegen der Offenlegung der
Sourcen hatte.
Beste Grüße, branadic
@branadic
Das war Revison 173 aus dem SVN, wenn ich mich richtig erinnere. Wenn du
unter Windows arbeitest sollte das exe aus meinem post vom 27.07.2009
16:36 gehen.
Martin
Hallo Martin,
vielen Dank.
Ich habe die Datei jetzt mal eingespielt und spiele gerade damit ein
wenig. Dabei ist mir aufgefallen, dass der Triggerzeitpunkt auch bei
10MHz zu stimmen scheint, sobald man auf Rohdaten umschaltet.
Aktiviert man die Korrektur, dann wandert der Triggerpunkt plötzlich weg
und stimmt nicht mehr. Vielleicht ist das für die FW-Leute ein wichtiger
Hinweis?
Leider stehen mir hier daheim nur Signale bis 10MHz aus einem
bescheidenen DDS-10 von ELV zur Verfügung. Aber ich geb dir in sofern
recht, dass der Datenquark am Anfang des Speichers auch hier zu sehen
ist, möglicherweise ein erster Hinweis darauf, dass den Daten bei
höheren Frequenzen das gleiche Schicksal ereilen wird und es wirklich
ein Problem im FPGA-Design ist.
Anbei mal ein Bild, nicht das ihr noch auf Entzug geratet :)
Zu sehen ist ein 10MHz-Sinussignal aus dem DDS-10. Wiederum direkt mit
50-Ohm-Kabel und Abschlusswiderstand direkt ans Oszi.
Oben in blau dargestellt die Rohdaten, grün entsprechend ein Shot mit
den Korrekturwerten. Unten hab ich dann mal die korrigierten Daten
gespiegelt, damit man einen besseren Vergleich hat.
Was mir noch etwas unverständlich ist, warum dieser Effekt des
Daten-faschings im Speicher frequenzabhängig ist. Ich würde es
verstehen, wenn das sampleratenbhängig wäre, aber diese
Frequenzabhängigkeit hinterblicke ich nicht bzw. kann keinen rechten
Zusammenhang mit dem FPGA-Design herstellen. Denn bei 1GS/s und einem
100kHz-Signal würde man auch Ausreißer erwarten. In meinem Messungen von
100kHz - 200MHz (logarithmisch aufgenommen) kann man das aber nicht
sehen.
Wer die Daten selbst einmal analysieren möchte, dem stelle ich gerne die
Daten im CSV-Format zur Verfügung.
Beste Grüße, branadic
Hallo und guten Abend,
für all diejenigen die nicht die Möglichkeit haben beliebige Frequenzen
zu erzeugen und am Oszi zu messen, hier mal ein logarithmisch
aufgenommener Frequenzgang mit dem DSO und der FW 0.89.
Man sieht was im Speicher an Daten liegt und das zwischen 10 und 20 MHz
irgendwas passiert.
Signal war der berühmte Sinus mit 1V Amplitude. Eigentliches Ziel der
Messung war es, den Frequenzgang des Gerätes in Erfahrung zu bringen, um
die Eingangsstufe bewerten zu können. Wie ihr selbst sehen könnt ist
dieser so überhaupt nicht bestimmbar.
Große Hoffnung setze ich nun in das neue FPGA-Design. Ich werd mal
schauen, dass ich die Version finde, wo zumindest die Signaldarstellung
funktioniert hat und die ADC-Werte als Bit pro Pixel angezeigt worden.
Vielleicht lässt sich der Frequenzgang damit zumindest einmal
abschätzen.
Beste Grüße, branadic
branadic schrieb:
> Hallo zusammen, hallo Falk,>> ich habe heute noch mal Messungen am Rhode & Schwarz Signalgenerator mit> dem DSO gemacht. Signalquelle war ein Sinus von 1V Amplitude direkt mit> einem 50 Ohm-Kabel plus Abschlusswiderstand an das DSO gehängt.
Hi Branadic,
Obige Messung zeigt:
1Vpp, 10MHz (schwarz), 20MHz(rot), die geringere Amplitude bei
20MHz ist auf den FG (Grundig FG100) zurückzuführen. Die Legende
habe ich aus Versehen (Rufbereitschaft, von sechs Nächten zwei
durchgeschlafen) gelöscht. Gemessen wurde über ein T-Stück an
dem mit 50 Ohm abgeschlossenen Ausgang. Tastkopfeinstellung: 10/1
Der von Dir vorgetragene Effekt ("Datenmüll", 10_20_30_40_MHz)
wird mit dieser Messung widerlegt.
Verwendet wurde ein W2014A, HW: 8C7.E3, FW: Bf.0.87
>> [...]
Grüße,
rowue
Hallo Rolf,
>Der von Dir vorgetragene Effekt ("Datenmüll", 10_20_30_40_MHz)>wird mit dieser Messung widerlegt.
herzlichen Glückwunsch, bei deinem Gerät scheint bis 20MHz noch was
brauchbares im Speicher zu stehen (ersten Quatsch sieht man übrigens
auch innerhalb der ersten 100 Werte bei dir).
Das der von mir "vorgetragene Effekt" mit dieser Messung "widerlegt" ist
glaube ich nicht. Man könnte fast meinen du willst mir unterstellen,
dass ich nicht in der Lage wäre ein Signal in das Welec zu bekommen und
anschließend darzustellen??? Ich stelle hier schließlich keine wilden
Theorien auf, sondern warte mit Messungen auf. Wenn das unerwünscht ist,
dann darfst du das gern kundtun.
Nur weil bei dir und einem 20MHz-Sinussignal (Ein Sinus ist aber schon
was anderes als das was man da sieht, meinst du nicht auch?) der Effekt
nicht zu beobachten ist heißt das nicht, dass dies auf alle Geräte
zutrifft und meine Messungen Quatsch sind. Das lässt eher vermuten, dass
wir es hier mit einem Timingproblem innerhalb des FPGA-Designs zu tun
haben und du einen besseren FPGA vom Timing her in deinem Gerät zu haben
scheinst.
Das Problem mit dem Timing und der Timingunterschiede von Gerät zu Gerät
ist uns schon zu Beginn der Entwicklung des neuen FPGA-Designs
aufgefallen. Crazor scheint nämlich auch einen besseren FPGA in seinem
Gerät zuhaben. Während bei ihm das Design bereits lief hatten Bruno und
ich noch schwarze Bildschirme aufgrund der Timingprobleme im Design.
Mittlerweile sind diese Timingprobleme jedoch behoben.
Wie man sieht ist es notwendig noch mehr Messungen gegenüber zu stellen
und miteinander zu vergleichen. Voreilige Schlüsse bringen keinem was,
dazu brauchen wir einfach mehr Vergleiche anderer Welec-Besitzer.
Daher die Bitte an alle: Leute, es gibt mittlerweile die
Screenshotfunktion. Seid doch so nett und exportiert die Daten eines
höherfrequenten, mit 1GS/s aufgenommenen Sinussignales einfach mal in
ein CSV-File und schaut euch die Signale mit Excel oder sonst was an und
lasst uns wissen, ob ähnliche Effekte auch bei euch zu sehen sind oder
nicht.
W2014A HW: 8C7.00 FW: OS.0.89beta
Beste Grüße, branadic
Hallo Leute,
der Falk hat von einem meiner Datensätze mal ein Video zusammengestellt,
wo Signal im Speicher und zugehörige FFT zu sehen sind.
Sieht echt spektakulär aus und verdeutlicht noch einmal, was ich mit dem
bisher Geschriebenen meinte...
http://www.falk-willberg.de/tmp/FFT.mpeg
Beste Grüße, branadic
Hallo branadic,
schön anzusehen, aber ich verstehe trotzdem nicht mehr :-( .
In deinen Daten ist auch der Schwebungseffekt zu sehen. Nimm
mal einen Satz um 60 MHz und schau dir nur jeden 4. Wert an,
dann müsstest du ihn besser sehen.
Gruß, Guido
Hallo Guido,
selbst wenn ich mir jeden 4. Wert anschauen kommt nur unbrauchbarer
Zickzack heraus.
@ Rolf und alle anderen,
ich habe vorhin noch einmal Messungen gemacht und die ersten Ergebnisse
möchte ich euch nicht vorenthalten. Hier mal die Kurzmessung.
Die Frage war, ist es möglich auch hohe Frequenzen mit dem Welec zu
messen. Die Antwort darauf lautet: Ja, vorrausgesetzt der Signalpegel
des hochfrequenten Signales übersteigt eine bestimmte Schwelle nicht.
Bruno hatte das seinerzeit ja schon mal anhand eines Oszillators im
Video gezeigt. Ich möchte diese Aussage mit zwei Bildern belegen.
Signalquelle war wieder der Signalgenerator von Rhode & Schwarz. Als
Amplitude habe ich 15mV eingestellt und mal ein 50MHz Signal in den
Spannungsbasen 10mV/div, 20mV/div und 50mV/div aufgezeichnet und die
Daten exportiert.
Ihr seht die ersten 512 Samples aus dem Speicher.
Die zweite Aufnahme hier zeigt nun ein 100MHz Sinussignal, wieder mit
den 3 Spannungsbasen 10mV/div, 20mV/div und 50mV/div.
In weiteren Messungen, die ich aber erst noch komplett auswerten will,
habe ich mit noch kleinerer Signalamplitude gemessen und bin den
Frequenzbereich von 100kHz bis 200MHz hochgegangen und habe zudem die
Messungen sowohl auf Kanal 1 als auch auf Kanal 2 durchgeführt. Sobald
ich die Ergebnisse habe, werde ich darüber mehr berichten.
Beste Grüße, branadic
Hallo branadic,
soweit ist das ja nichts neues. Brauchst du noch Messdaten? Bei
kleienr Amplitude kann ich die liefern. Interessant ist die
Produktbildung mit Mischfrequenzen ab ca. 60 MHz. Erklären kann
ich mir das aber immer noch nicht.
Mit kleiner Auflösung zu messen ist imho o.k., da sonst die Probleme
mit den Videoverstärkern hinzukommen. Das könnte man mit meinem 2012
im Vergleich zu einem anderen Geräten untersuchen, da bei mir im
Kanal 1 ja die 22-Ohm-Widerstände drin sind, die schon einen
Unterschied machen.
Also, wenn du Messdaten brauchst, melde dich.
Gruß, Guido
könnte es ein Problem des Verstärkerkreises sein, da es anscheinend
abhängig vom Verstärkungsfaktor ist?
Wie bist du überhaupt auf dieses Problem gestoßen, welcher Sensor
liefert ein so niedriges Ausgangssignal. Evtl. Piezos?
Hallo Guido,
verschon mich bitte mit Messdaten, ich habe hier noch 6x 38 Dateien, die
ausgewertet wollen. :)
Kannst du nicht mit einem geeigneten Programm (bspw. QTOctave) selbst
die Auswertung durchführen?
@ Thomas,
denkbar, Bruno hatte ja schon Messungen durchgeführt, konnte aber nichts
auffälliges feststellen. Ich werde diese Messungen bei Gelegenheit
wiederholen.
Es geht auch nicht darum, dass irgendein Sensor ein derartiges Signal
liefern soll, sondern es geht darum, dass man bspw. nicht in der Lage
ist, ein 1Vpp Sinussignal von 100MHz mit den Spannungsbasen 1V/div,
2V/div oder 5V/div in irgendeiner Form bei einem Gerät mit angegebenen
100MHz Analogbandbreite vernünftig darzustellen. Jetzt stellt sich
natürlich die Frage wieso nicht und genau dem gehe ich momentan nach.
Beste Grüße, branadic
O.k. branadic,
natürlich kann ich das. Wenn ich nur eine Idee hätte. wonach ich suchen
soll. Falks FFT ist ist nicht uninteressant, aber ... naja, die
Abtastfrequenz kommt irgendwann ins Spiel. Warum?
Vielleicht sollten wir doch mal einen Tiefpass in die Software
aufnehmen. Der müsste aber bei höchstens 100 MHZ einsetzen und
würde viel Performance fressen.
Gruß, Guido
branadic schrieb:
> Hallo Guido,>> selbst wenn ich mir jeden 4. Wert anschauen kommt nur unbrauchbarer> Zickzack heraus.>> @ Rolf und alle anderen,>> ich habe vorhin noch einmal Messungen gemacht und die ersten Ergebnisse> möchte ich euch nicht vorenthalten. Hier mal die Kurzmessung.>> [...]
Hi Branadic,
mir war später am Abend auch aufgefallen, dass das 10/20/40
Verhalten ziemlich nach einer Übersteuerung aussieht (und
es insofern in dieser Messung einen (extremen) Hochpass
geben muss).
Was evtl. helfen könnte: Mir war beim Spielen mit dem Kalibrier-
und anderen Rechtecksignalen aufgefallen, dass der Tastkopf (auch
wenn angepasst) in der 10/1 Stellung an den Flanken leicht
zum Überschwingen (z.T. mit "Nulldurchgängen") neigt.
Könnte ein Hinweis sein. Vielleicht sollten wir die Schaltung
mal "durchsimulieren".
Grüße,
rowue
PS: "Überschwingungen" sieht man z.B. auch in den 50MHz-Samples
von Dir
branadic schrieb:
> [...]>> @ Rolf und alle anderen,>> [...]
Hi Branadic,
kurzer Nachtrag: Dein R&S kann doch sicher "vernünftig" pulsen.
Hast Du Lust mal einige, gerne auch niederfrequente, Pulsmessungen
zu machen, und die über 'ne FFT zu ziehen? - Könnte evtl. Aufschluss
über das Fequenzverhalten geben (Rechteck geht auch, aber Puls
ist besser ;)
Grüße,
rowue
branadic schrieb:
> Hallo zusammen, hallo Falk,>> ich habe heute noch mal Messungen am Rhode & Schwarz Signalgenerator mit> dem DSO gemacht. Signalquelle war ein Sinus von 1V Amplitude direkt mit> einem 50 Ohm-Kabel plus Abschlusswiderstand an das DSO gehängt.>> [...]
Hi Branadic,
magst Du mir evtl. den Gefallen tun, und in Deinem Messaufbau
mal das 50 Ohm Kabel gegen 'nen Tastkopf mit BNC-Adapter tauschen?
Ich habe eben etwas mit den Tastköpfen gespielt (6Vpp rein,
auf 500mV/Div, resp. 50mV/Div gestellt und übersteuert). Hierbei
zeigte sich, dass das System bei der 10/1 Einstellung deutlicher
zum Schwingen neigte, als bei der 1/1 Einstellung (geringere Dämpfung
im HF-Bereich).
(Gedanke aufschreib: kann es sein, dass da unter gewissen Umständen
irgenwas in der Eingangsstufe zum Schwingen angeregt wird und dann das
Signal versaut?)
Falk: In "set_serial" in der w2000a-screenshot.cpp setzt Du in neueren
Versionen "termios.c_cc[VMIN]" auf 0. Damit bekomme (zumindest ich)
Ärger mit dem "Trace" Modues (wo er in der Schleife klebt, bis ich
den Knopf am Scope drücke). "Ärger" meint: das Programm läuft gerade
mal eine Sekunde.
Grüße,
rowue
Letzter Gedanke für heute:
Beide Signale zeigen für 50mV/Div annähernd die gleiche Amplitude
(btw: ~60mVpp). Bei dem 50MHz Signal zeigt sich eine nahezu phasenstarre
Verzerrung (Kante). (Bei 20mV/Div zeigt sich bei dem 50MHz-Signal eine
Amplitude von ca. 30mV, dass 100MHz Signal ist nicht mehr zu
identifizieren.)
Mit der höheren Empfindlichkeit wird das System auch für Störungen
empfindlicher. Sagen wir: es gibt etwas hinter dem Verstärker
(Trigger?),
was auf z.B. die Stromversorgung durchschlägt und somit in die
Eingangsschaltung "einstrahlt". Bei geringeren Verstärkungsfaktoren
(5V/Div, 2V/Div) wird diese Störung noch nicht so stark in's Gewicht
fallen. Bei höheren Verstärkungsfaktoren (50mV/Div, 10mV/Div) wird
diese Störung mitverstärkt und koppelt somit mit ihrer Erregung.
Unser Oszi fängt an zu schwingen und gerät (unter unschönen Umständen)
in die Resonanzkatastrophe (100MHz, 15mV).
Das, was mir dabei am wenigsten gefällt, ist, dass da per Software
wenig zu machen sein wird.
Was meint ihr dazu? Oder bin ich gerade zu wirr?
Grüße,
rowue
Hallo,
die Gedanken drehen sich im Kreis! Als das hab ich schon vor Monaten
untersucht und gepostet.
Rolf du bist hier noch nicht so lange dabei, aber sieh doch mal in den
alten Posts, da findet sich auch eine komplette Simulation der Analog-
Input-stufen welche ich in LTSpice erstellt habe.
Ich kann die sogar sagen welcher Baustein in der Verstärkerkette dieses
ausgeprägte Hochpass- Charakter aufweist, der OPA 656. Auch zur Suche
über evtl. Alternativen findet sich im HW Thread eine Diskussion. Nicht
zuletzt sind auch schon Bemühungen von Walter und mir am Laufen, diese
Eingangsstufe (speziell der OPA656, aber auch der OPA1177 tragen
hauptsächlich zum Rauschen bei) zu ersetzen. DENNOCH- Mein Video mit
unserem Neuen VHDL Design (s.h. Youtube) wiederlegt eindeutig das die
analogen Stufen für dieses Phänomen verantwortlich sind.... Also bitte
diese Diskussion nicht wieder von vorne.
Gruß, brunowe
Bruno We schrieb:
> Hallo,>> die Gedanken drehen sich im Kreis! Als das hab ich schon vor Monaten> untersucht und gepostet.> [...]
Danke! - Jetzt ist einiges klarer ;) - (Rate mal, was ich heute
gemacht habe ;)
Habe da trotzdem noch die eine oder andere Frage. Sieht mensch
sich nachher im IRC?
>>> Gruß, brunowe
Grüße,
rowue
Hallo zusammen,
entgegen der Meinung von Bruno (nimm es mir bitte nicht übel), vermute
ich den Fehler nach Auswertung meiner Messdaten vom Freitag doch eher in
der Analogstufe und nicht im VHDL.
Dafür sprechen gleich mehrere Gründe. Wer sich die Bilder oben anschaut
sieht ein Sinussignal von 5.01mV Amplitude, aufgenommen in den
Spannungsbasen 10mV/div (oberes Diagramm), 20mV/div (mittleres Diagramm)
und 50mV/div (unteres Diagramm) mit 1GS/s. Dargestellt sind je 128
Werte.
Bei 90MHz kann man auch bei der Einstellung 10mV/div noch einen Sinus
erahnen, bei 100MHz treten bei der gewählten Amplitude massive Störungen
auf.
Gleichzeitig kann man in den anderen beiden Einstellungen sehen, dass
die Amplitude ansteigt.
Bei 180MHz scheinen diese Störungen wieder zu verschwinden und die
Amplitude nimmt wieder ab.
Das Signal war hier DC gekoppelt an den Eingang gelegt. Ich werde morgen
den Versuch noch einmal mit AC-Kopplung durchführen, erwarte hier jedoch
das gleiche Ergebnis.
Welcher Unterschied besteht also gegenüber dem neuen VHDL und dem
Welec-Design? Ich hab mich diesbezüglich beim Entwickler (crazor) schlau
gemacht. Zum einen war bei dem Video von Bruno die AC/DC-Kopplung noch
nicht geklärt, weiterhin die Verstärkungsfaktoren und als dritte
momentan bekannte Möglichkeit könnte der DAC als Ursache in Frage
kommen.
Es könnte also durchaus sein, dass im neuen VHDL irgendein
Schaltungsteil der Analogstufe vom FPGA her nicht aktiv geschaltet oder
anderweitig angesteuert wird, der im Welec-Design jedoch arbeitet und zu
diesen massiven Störungen führt. Ziel ist es für mich daher
herauszufinden, ob das so ist und wenn ja, welcher Teil dafür
verantwortlich ist.
Daher werde ich das Design, welches dem Video zugrunde liegt, ebenfalls
einspielen und den gleichen Versuch noch einmal durchführen, jedoch mit
verschiedenen Frequenzen und Amplituden.
Die letzte Möglichkeit zur Klärung ist, hier habe ich mich mit Walter
besprochen, die Messungen von Bruno noch einmal mit einem schnelleren
Oszilloskop zu verifizieren und die Messungen mit beiden Designs, also
dem original Welec-Design und dem neuen VHDL, durchzuführen.
@ Rolf
pulsen kann ich mit dem R&S leider nicht, dafür steht mir aber ein
Funktionsgenerator zur Verfügung.
Du wirst aber verstehen, dass ich nicht alle Messungen gleichzeitig
durchführen kann und da ich für nächste Woche Urlaub einlegen musste,
kann dieser Test noch ein paar Tage dauern.
Beste Grüße, branadic
Hallo branadic,
wirklich sehr fleißig. Ich bin aber immer noch der Meinung,
dass beides zusammenkommt. Klar, die Eingangsstufe, genauer
der Übergang vom Videoverstärker auf die ADCs spinnt. Dies
macht sich erst mit stärker dargestellten Signalen bemerkbar
und ist in deinen Messungen klar zu erkennen. Ich empfehle
22-Ohm-Widerstände ;-). Ich muss mal noch einen Abschlußwiderstand
einlöten, habe im Moment aber nur wenig Zeit.
Aber das Spinnen ab 100 MHz (bei meinem 2012A schon früher) ist
damit kaum zu erklären. Da kommt noch was dazu, das ich bisher
überhaupt nicht kapiere. Denke an die Spiegelfrequenzen in Falks
FFTs, oder auch die Schwebung bei ganzzahligen Bruchteilen der
Abtastfrequenz.
Gruß, Guido
Hallo Guido,
> und ist in deinen Messungen klar zu erkennen. Ich empfehle> 22-Ohm-Widerstände ;-). Ich muss mal noch einen Abschlußwiderstand> einlöten, habe im Moment aber nur wenig Zeit.
welche Baugröße benötige ich für die Widerstände? Muß mal ein paar
Widerstände bestellen.
Danke und Gruß
Jürgen
Hallo Jürgen,
passende Bauform für die Widerstände ist 0603. Für den Abschluss
habe ich noch nicht rausgefunden, wo man den anbringen könnte.
Gruß, Guido
Guido schrieb:
> Hallo branadic,>> wirklich sehr fleißig. Ich bin aber immer noch der Meinung,> dass beides zusammenkommt. Klar, die Eingangsstufe, genauer> der Übergang vom Videoverstärker auf die ADCs spinnt.
Da bin ich nicht mehr sicher. Siehe Bild: 138MHz, 5Vpp 500mv/div.
IRC: #welec (irc.freenode.org)
Forum: http://sourceforge.net/apps/phpbb/welecw2000a/
hmm im Bild ist ein 138 kHz Signal zu sehen...
Hab ich das jetzt richtig verstanden (im englischen Forum) - du hast das
Schwingungsproblem durch patchen eines ADC-Registers
gelöst???!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Viele Grüße,
egberto
Hallo Falk,
> Da bin ich nicht mehr sicher. Siehe Bild: 138MHz, 5Vpp 500mv/div.
das sieht gut aus. Wie bist du darauf gekommen, das wirkt doch im
FPGA-Design? Mal ganz langsam: adc_change12_reg wird doch auf
0x0200000 gesetzt. Das änderst du in hardware_t.cpp in 0x0020000?
Gruß, Guido
Hallo,
SUPER ARBEIT FALK!
Ich hab mein Oszi eben bis 150Mhz durchgewobbelt.
Auch wenn wir nicht wissen was da geschieht, das sieht verdammt gut aus!
Es zeigt sich bei mir zwar noch eine HF Schwebung (hoffe das Blech kommt
bald und hilft etwas!) und eine stark schwankende Amplitude über die
Frequenz....
*******************************
ABER DIE OSZILLATIONEN SIND WEG!
*******************************
Selbstverständlich sind damit die Probleme der relativ stark rauschenden
Eingangsstufen, sowie die schlechte Linearität nicht beseitigt, aber
jetzt macht's wieder Spass zum Weiterentwickeln!
Gruß, brunowe
P.S.: Ich sag jetzt nicht, ich habs ja gleich gesagt!
Ich würde mich ja gerne mit euch freuen, kann aber gerade nicht so recht
folgen.
(Wobei ich nicht ausschliessen möchte, dass es an mir liegt... ;-) )
Kann mir mal jemand auf die Sprünge helfen?
Beste Grüße,
Odic
Hallo Odic,
geht mir genauso, die Angaben von Falk machen imho keinen
Sinn, die Unterschiede zu den Werten in der Firmware sind zu
groß.
Nach dem Kommentar im Quelltext könnte es sich um ein
zuschaltbares Filter im FPGA handeln, das Falk ausgeschaltet
hat. Wie er auf das Bitmuster gekommen ist? Ist für mich aber
gut nachvollziehbar, dass ein verunglücktes FIR-Filter Murks
macht.
Gruß, Guido
Guido schrieb:
> Hallo Odic,>> geht mir genauso, die Angaben von Falk machen imho keinen> Sinn, die Unterschiede zu den Werten in der Firmware sind zu> groß.>> Nach dem Kommentar im Quelltext könnte es sich um ein> zuschaltbares Filter im FPGA handeln, das Falk ausgeschaltet> hat. Wie er auf das Bitmuster gekommen ist? Ist für mich aber> gut nachvollziehbar, dass ein verunglücktes FIR-Filter Murks> macht.
Lass die einfach versucht haben, einen Tiefpass einzubauen,
dass zu ggf. optimieren und dabei (vom Algorithmus her) Ein- und
Ausgang vertauscht haben. 'Nen FFT-Filter werden Wittig & Co.
dort nicht eingesetzt haben.
Mehr dazu dürfte im "DSP-Guide" (http://www.dspguide.com/)
zu finden sein ;)
>> Gruß, Guido
Grüße,
rowue
PS: Falk - hast Du das auch für die Kanäle 3&4 aktiviert?
So,
in der SVN-Version kann ich es auf Kanal 2 nachvollziehen.
Glückwunsch Falk, das ist wohl ein Volltreffer.
Auf Kanal 1 ändert sich bei mir nichts. Wird doch nicht an den
22-Ohm-Widerständen liegen?
Gruß, Guido
Guido schrieb:
> So,>> in der SVN-Version kann ich es auf Kanal 2 nachvollziehen.> Glückwunsch Falk, das ist wohl ein Volltreffer.
Beim mir (2014) sind Kanal 1&2 o.k. - auf 3&4 habe ich
Zacken und zum Teil Spikes - die muss ich mir aber noch mal
ansehen ...
>> Auf Kanal 1 ändert sich bei mir nichts. Wird doch nicht an den> 22-Ohm-Widerständen liegen?>> Gruß, Guido
Grüße,
rowue
Hallo,
jetzt habe ich noch mal mit dem steilflankigen 20-MHz-Signal
probiert und genau die gegenüber früher umgekehrten Verhältnisse
erhalten. Bilder gibts leider keine weil screenshot in der
momentanen Version wohl nicht funktioniert.
Das wäre ja die Härte, wenn die Widerstände die Probleme im Design
verbessert hätten. Naja, zu Vergleichszwecken lasse ich sie mal
noch drin.
Mal grundsätzlich: würde sich nicht jemand der sich auskennt damit
anfreunden können den Saustall in SFN zu beaufsichtigen? Es gibt da
SVN-Versionen, die noch nicht mal durch den Kompiler laufen, das
tgz für Screenshot enthält nur ein Windows-Executable (sehr witzig)
.....
Gruß, Guido
Hallo Guido,
die Screenshot aus der 0.90 läuft bei mir mit der 0.91 wunderbar. Auf
Kanal 1 und 2 habe ich dieselben Ergebnisse, scheint also mit deinen
Widerständen zusammen zu hängen.
Meiner Meinung nach ein weiterer Hinweis darauf, dass adc_change12_reg
irgendwie auf die Analogstufe (Bruno, ich bleib dabei) wirkt und nicht
im VHDL. Wo genau lässt sich aus dem bisherigen Schaltplan leider nicht
entnehmen, dafür ist er doch noch zu undetailiert.
Ein falsch angeschlossenes FIR-Filter schließe ich aus, da der Effekt
direkt auch mit dem Verstärkungsfaktor zusammenhängt und sich
amplitudenabhängig verhält.
Ich habe heute mit der FW Messungen am Signalgenerator durchgeführt. Für
die Auswertung der Daten werde ich mir ein wenig mehr Zeit nehmen, damit
ich mal ein Gefühl für die Bandbreite des Welec bekomme. Mit der neuen
FW, den ausbleibenden Schwingungen oder was immer das auch ist und den
heutigen Messungen, könnte man erstmal den Frequenzgang versuchen zu
quantifizieren.
Gibt es eigentlich irgendwo Info's darüber, inwieweit die 8bit ADC bei
2V/div ausgesteuert werden, sodass man von der Auflösung auf die
Amlitude schließen kann?
Oben dazu mal die Bilder, wie sich die Amplitude mit der neuen FW
verhält. Signal war wieder 1.4V Amplitude (Ueffektiv).
Beste Grüße, branadic
Rolf Würdemann schrieb:
> Guido schrieb:>> So,>>>> in der SVN-Version kann ich es auf Kanal 2 nachvollziehen.>> Glückwunsch Falk, das ist wohl ein Volltreffer.>> Beim mir (2014) sind Kanal 1&2 o.k. - auf 3&4 habe ich> Zacken und zum Teil Spikes - die muss ich mir aber noch mal> ansehen ...
Angesehen ...
Auf Kanal 4 bekomme ich "Schwinger" sobald ein Signal
(10 MHz Rechteck) anliegt, auf Kanal 3 kann ich sogar ohne
Signal durch die Einstellung des Null-Punktes Spikes provozieren.
Entweder hat mein Gerät eine Macke, oder es sind auf Kanal
3 und 4 noch weitere Filter aktiv - mag das mal jmd. testen? ;)
>>>> [...]
@Branadic: Hatte gestern mal mit 200mV/Div 'ne Amplitude bis
jeweils ~+- 3Div gemessen: min:79, max: 181 - das würde
auf etwa 136 Bit als Aussteuerung hinweisen, sollten aber
eher ~200 sein ...
>>>> Gruß, Guido>> Grüße,>> rowue
Grüße,
rowue
Hallo branadic,
afaik wird bei 2 V/div das Signal erst durch 100 geteilt und
anschließend mit 2,5 multipliziert. Ergibt bei 8 div maximal
0...400 mV bei einem Austeuerungsbereich des ADC von
0...625 mV. Damit liegen die Werte im FIFO zwischen 0 und
164.
Jo Mann, das ist kompliziert. Falks Hack wirkt sich zumindest
auch auf die Hardwareeinstellung aus. Z.B. wird der BW-Switch
damit wirkungslos. Über 100 MHz steigt auch die Amplitude an,
das macht mein VCO sicher nicht so stark. Immerhin haben wir
einen weiteren Angriffspunkt, Ich werde morgen mal noch mit den
Schwebungen probieren.
Gruß, Guido
Oops,
wer misst misst Mist (habe ich doch schon mal gepostet ;-)).
Habe beim Ausschalten bemerkt, dass mit Falks Hack beide
Eingangskanäle schwingen. Habe also wohl garnicht das Signal
des VCO gemessen.
Morgen weiter ...
Gute Nacht, Guido
Guido schrieb:
> Hallo branadic,>> afaik wird bei 2 V/div das Signal erst durch 100 geteilt und> anschließend mit 2,5 multipliziert. Ergibt bei 8 div maximal> 0...400 mV bei einem Austeuerungsbereich des ADC von> 0...625 mV. Damit liegen die Werte im FIFO zwischen 0 und> 164.
Oder die Änderung/Erkenntniss wurde noch nicht umgesetzt,
dass sind wir bei: 2V/div, durch 100 geteilt und mit 2
multipliziert. -> 0-320mV -> [0:131]
Hätte aber auch den Nachteil, dass dann die Bandbreitenbegrenzung
beim OPA nicht aktiv ist.
>> [...]>> Gruß, Guido
Grüße,
rowue
Moin/Nabend oder was auch immer ...
Ich habe in's Trac mal zwei Patches gestellt:
a) nen Bugfix für den "trace-mode" beim Screenshot (#27)
b) flashloader.sh (#28)
wäre nett, wenn die jmd. mal einpatchen und committen könnte
(kurze Anleitung findet sich in #27)
Bei Macports gibt es die Empfehlung/Ansage: Einen Commit/Punkt.
Fehler lassen sich so einfacher finden (Punkt kann hierbei sein:
Feature, Bugfix, Release, etc) - wäre auch meine Empfehlung an
dieser Stelle ;)
Grüße,
rowue
PS: Eine Übersicht über offene Tickets:
http://sourceforge.net/apps/trac/welecw2000a/report/1
branadic schrieb:
> Hallo Guido,>> [...]> Ein falsch angeschlossenes FIR-Filter schließe ich aus, da der Effekt> direkt auch mit dem Verstärkungsfaktor zusammenhängt und sich> amplitudenabhängig verhält.>
Naja, ich hatte da z.B. den Effekt, dass ich durch Umschalten
des Tastkopfes (und entsprechender Verstellung der Eingangsteilung)
von 10/1 auf 1/1 das damalige Verhalten "dämpfen" konnte, das
System also unempfindlicher gegen das Schwingen wurde.
Neben dem Umstand, dass ich den Eingangswiderstand durch
das Umschalten verringere, verringere ich auch die Bandbreite
und erhöhe die Anstiegszeit. Sprich: ich ziehe ihm die oberen
Fourier-Koeffizienten weg.
Diese können nun im Zusammenspiel mit dem OPA die Schaltung
zum Schwingen angeregt haben, oder jmd. hat versucht, dass
Verhalten des OPA per Software in den Griff zu bekommen und
hat sich dabei "in den Fuss" geschossen.
> Ich habe heute mit der FW Messungen am Signalgenerator durchgeführt. Für> die Auswertung der Daten werde ich mir ein wenig mehr Zeit nehmen, damit> ich mal ein Gefühl für die Bandbreite des Welec bekomme. Mit der neuen> FW, den ausbleibenden Schwingungen oder was immer das auch ist und den> heutigen Messungen, könnte man erstmal den Frequenzgang versuchen zu> quantifizieren.
Wäre sehr gut ;)
>> [...]> Oben dazu mal die Bilder, wie sich die Amplitude mit der neuen FW> verhält. Signal war wieder 1.4V Amplitude (Ueffektiv).>
Hupps ....
> Beste Grüße, branadic
Grüße,
rowue
Hallo Guido,
>afaik wird bei 2 V/div das Signal erst durch 100 geteilt und>anschließend mit 2,5 multipliziert. Ergibt bei 8 div maximal>0...400 mV bei einem Austeuerungsbereich des ADC von>0...625 mV. Damit liegen die Werte im FIFO zwischen 0 und>164.
danke für deine Antwort. Aber wie mir scheint, gibt es in der FW eine
Skalierungsstufe, die den reduzierten Aussteuerbereich der ADC wieder
ausgleich soll?
Wie bin ich darauf gekommen: Ich habe ja die Messungen mit Falk's FW
0.91 durchgeführt und die Daten abgespeichert. Nun wollte ich die
Bit-Werte wieder zurück in eine Spannung rechnen.
Da 128 eigentlich NULL entspricht schiebt man die Daten erst einmal
wieder um 128 runter:
Samplewert-128
Als Ergebnis hat man nun ein Signal, das zwischen -128 und 128. Wenn
0.625V gerade 8bit entspricht (resp. -128 bis +128) würde man also über
die einfache Verhätnisgleichung und anschließende Rückwärtsverstärkung
auf die richtige Spannung bekommen müssen:
(Samplewert-128) *0.625V/256 *100/2.5
oder anders geschrieben:
(Samplewert-128) *0.3125V/128 *100/2.5
Tatsächlich ist das aber nicht so und die Spannungswerte sind zu klein.
Rechne ich jedoch mit 0.4V anstelle der 0.3125V komme ich auf die
Spannungswerte, wie sie auch auf dem Oszi angezeigt werden und wie ich
sie erwarten würde:
(Samplewert-128) *0.4/128 *100/2.5
Jetzt stellt sich mir ganz unabhängig von dieser Rechnerei die Frage,
was passiert wenn nun aus irgendeinem Grund Signale am ADC auftreten,
die größer als der reduzierte Aussteuerbereich sind?
Beste Grüße, branadic
branadic schrieb:
> Hallo Guido,>>>afaik wird bei 2 V/div das Signal erst durch 100 geteilt und>>anschließend mit 2,5 multipliziert. Ergibt bei 8 div maximal>>0...400 mV bei einem Austeuerungsbereich des ADC von>>0...625 mV. Damit liegen die Werte im FIFO zwischen 0 und>>164.>> [...]>> (Samplewert-128) *0.625V/256 *100/2.5>> oder anders geschrieben:>> (Samplewert-128) *0.3125V/128 *100/2.5
Rechne mal
Laut bruno's Erklärung sehr weit oben im Thread sind die
Verstärkunksfaktoren 1;2;5 und nicht 1.25;2.5;5. Es war
mal angedacht, diese in 1.25;2.5;5 zu ändern. Es scheint
aber noch nicht umgesetzt worden zu sein (viele Änderungen
am Code (Anzeige, QM)
Evtl. wirst Du das auch in Deinen Analysen daran sehen,
dass bei den 5'er Stufen die Bandbreite (stärker) begrenzt
wird als bei den 1'er und 2'er Stufen.
>> Tatsächlich ist das aber nicht so und die Spannungswerte sind zu klein.> Rechne ich jedoch mit 0.4V anstelle der 0.3125V komme ich auf die> Spannungswerte, wie sie auch auf dem Oszi angezeigt werden und wie ich> sie erwarten würde:>> (Samplewert-128) *0.4/128 *100/2.5
>> Jetzt stellt sich mir ganz unabhängig von dieser Rechnerei die Frage,> was passiert wenn nun aus irgendeinem Grund Signale am ADC auftreten,> die größer als der reduzierte Aussteuerbereich sind?
Den ADC dürfte das nicht interessieren, solange dies im erlaubten
Aussteuerbereich liegt. In der Anzeige laufen die dann (wenn ich
mir Ticket #7 ansehe) gegen die oberen und unteren Grenzen. In den
csv-Dumps müsstest Du sie ohne diese Einschränkung sehen.
> Beste Grüße, branadic
Grüße,
rowue
Hallo zusammen,
ich habe mit den Daten aus meinen Messungen, ohne das Rauschen
herauszufiltern, mal den Frequenzgang berechnet. Die Amplitude [Vpp] bei
1MHz hab ich dazu mal als 0dB angenommen und die restlichen Werte darauf
normiert.
Damit ergibt sich für die Einstellung 2V/div bei mir oben gezeigter
Frequenzgang.
Beste Grüße, branadic
Ach ja, bevor Fragen aufkommen, was tatsächliche Stützstellen sind und
die Grafik in Frage gestellt wird, hier mal noch ein bildlicher
Nachtrag.
Beste Grüße, branadic
Hallo.
Ich habe gerade mal die Beta 0.91 draufgehaut und ein wenig
herumgespielt. Leider fehlt mir bisher noch eine Quelle für
hochfrequente Signale, allerdings habe ich die Flanke eines 2,7kHz
Rechtecksignals bei relativ kleinen Zeitbasen (z.B. 200ns) betrachtet
und dabei sind mir riesige Ausreißer aufgefallen, die im Schnitt alle
paar Sekunden zu sehen sind und die ich bei vorherigen Firmwareversionen
nicht bemerkt habe.
Die Spitzen zeigen sich mal öfter, mal selten - komisch.
Kann das jemand nachstellen? Ich weiß nicht, ob ich das bei den alten
Versionen nur nicht bemerkt habe oder ob das ein neues Problem ist,
es ist bei mir aber auf allen Kanälen zu sehen.
Komischerweise ließ sich schlecht auf diese Spitzen triggern, ich habe
aber einen Screenshot hinbekommen, den ihr hier sehen könnt.
Leider kann ich nicht ausschließen, dass es an der NE555 Schaltung
liegt, ich halte das aber für nicht sehr wahrscheinlich.
Außerdem hatte ich vorhin noch ein Problem, das ich aber nicht mehr
reproduzieren kann: ich konnte keine 500ns einstellen sondern nur 1 us
oder 200 ns. Damit verbunden war eine ziemlich versaute Darstellung der
Flanke. Nach ein wenig herumdrehen an der Zeitbasis war alles plötzlich
wieder normal.
Gruß,
Michael
Hallo Michael,
diesen Ausreißer kann ich bestätigen. Ich habe diesen Ausreißer in
meinen Aufzeichnungen auch jeweils am Anfang oder am Ende einer
Messreihe, wobei es sich nur um einen einzelnen Wert handelt. Vermutet
wird, dass hier vielleicht ein Bit gekippt ist.
Noch mal ein kleiner Nachtrag:
Was man anhand der obigen Bilder im Wesentlichen sehen kann, ist das
Frequenzverhalten des OPA656 aus der Analogstufe, der für den
Frequenzbereich von 0-100MHz im Prinzip ausreichend wäre, nicht aber für
die W202xA Geräte. Hier hätte man einen Unterschied in der Hardware
erwarten müssen, aber offensichtlich gibt es den nicht. Zumindest an der
Stelle hat Wittig/Welec geflunkert.
Beste Grüße, branadic
Falls noch jemand die alte Firmware (0.90 oder älter) draufhat, könnte
derjenige bitte mal überprüfen, ob bei ihm auch die seltsamen Spikes
auftreten, die ich ein paar posts weiter oben beschrieben habe?
Gruß,
Michael
Hallo Michael,
Michael H. schrieb:
> Falls noch jemand die alte Firmware (0.90 oder älter) draufhat, könnte> derjenige bitte mal überprüfen, ob bei ihm auch die seltsamen Spikes> auftreten, die ich ein paar posts weiter oben beschrieben habe?
Ich hab mein W2022A Skope seit letzter Woche in Benutzung und genau
diese Spikes hatte ich auch bei der Messung eines ca. 58 kHz
Rechtecksignals. Dachte aber auch, dass es eventuell an der Schaltung
liegen könnte (ATMEGA16 im STK500), aber sehr wahrscheinlich kam mir das
auch nicht vor.
Komisch war, dass die Spikes nach "Auto-Setup" weg waren?! Leider habe
ich nichtmehr in Erinnerung in welcher Zeitbasis die Spikes aufgetreten
sind... ;-/
Gruß,
Jan
Mein W2022A hat inzwischen auch fw beta 0.91 aufgespielt bekommen und
ich kann die Spikes ebenfalls bestätigen. Ich habe Frequenzen von 2kHz -
100 kHz getestet. Bei meinem Welec ist bis 10us/div alles ok. Ab 5us/div
(200Ms/s) bis zum Ende der Timebase treten sporadisch Spikes auf.
Hardy
Hallo erstmal,
ich habe mit Spannung eure Entwicklungen bezüglich des Welec2022
bzw.2024 verfolgt und möchte mal ein Lob aussprechen! Es ist ja
unglaublich, was man mit diesem DSO Firmwaremässig anstellen kann.
Da ich jetzt selbst im Besitz eines W2022 bin, möchte ich diese Projekt
auch weiterhin verfolgen, was aber sehr schwierig ist, da hier zig
Threads am laufen sind...im Sourceforge ist alles auf englisch, gibt es
da denn keine auf Deutsch??? Würde da gerne den einen oder anderen
Beitrag dazu leisten!
So, möchte hier nicht weiter zu müllen und wünsche allen noch einen
erfolgreichen Tag.
LG mike0815
Hallo
Ich hab ebenfalls die Firmware 0.91 eingespielt und Getestet mit
Frquenzen 1khz, 1mhz und 10mhz und ich habe die Singale in verschiedenen
v/div angesehen jedoch haben sich keine Spikes bei mir eingeschlichen.
/* welech 2024A */
Tag zusammen,
orientiert euch bitte nicht an dem, was auf dem Bildschirm dargestellt
wird, sondern was tatsächlich an Daten im Speicher liegt und schaut euch
diese Daten genauer an.
Dazu wurde die w2000a-screenshot.exe entwickelt.
Unter Win einfach die Komandozeile öffnen, in das Verzeichnis mit der
w2000a-screenshot.exe wechseln und die Datei mit:
w2000a-screenshot.exe -c 1 (für COM-Port 1) -d (für korrigierte Daten)
oder -r (für Rohdaten) -o (für einmaliges Auslesen) -t csv oder ascii
(Dateityp wählen)
öffnen. Dann am Oszi in das QuickPrint Menu wechseln und auf den Button
CSV drücken. Schon wird der Speicherinhalt in eine Datei geschrieben.
Wenn ihr CSV gewählt habt könnt ihr euch die Daten im einfachsten Fall
mit Excel anschauen.
Anhand dieser Daten lassen sich mehr Aussagen treffen, als die
Eindrücke, die ihr am Bildschirm gewinnen könnt.
zur Frage nach den Foren...
Im Sourceforge wird zum Teil auch Deutsch gesprochen wenn auch eher
notgedrungenermaßen Da Englisch jedoch eine Weltsprache ist und somit
weltweit Welec-Besitzer in den Genuss der Entwicklung kommen und daran
Einfluss haben können ist der Großteil in Englisch.
Ist diese befremdlich wirkende Sprache denn wirklich ein so ernsthaftes
Problem? Es wird niemandem der Kopf abgerissen, nur weil die Beiträge
nicht 100% grammatikalisch richtig sind. Also traut euch ruhig!
Gruß, branadic
...da hast du wohl recht, nur bei speziellen Ausdrücken, wird man dann
wohl den Langenscheid auspacken müssen...
Ich war mal auf der FW-Seite von Sourceforg und wollte mir mal das
aktuelle Image von Hayo ( der ja unglaubliches leistet) ziehen, da ich
schon erfolgreich hin u. her geflasht habe, jedoch ist es nicht möglich
diese herunter zu laden, ausser die neue Screenshotversion, ist die
Seite noch nicht richtig aktiv, oder was bremst da?
Gruß Michael
Michael,
ich habe das schnell getestet und konnte auch eine der Firmwares
herunterladen. Wo hängt's denn bei dir? Schon mal versucht, einen
anderen Mirror zu wählen, wenn der Download nicht klappt?
Hä? Mirror??? Wo kann ich denn den auswählen? Hatte doch die Seite vor
mir, da waren wohl alle Dateien, nur konnte ich sie nicht anklicken, auf
welcher Seite warst du denn da??? Habe noch eine Adresse gefunden :
(http://sourceforge.net/apps/phpbb/welecw2000a/viewforum.php?f=5),
da stand aber nur die 0.90 zur verfügung, wollte aber gerne die 0.91er
testen, bevor ich das Ding zurück gebe!!!
Hallo Michael,
dich trifft der Fortschritt.
Installiere erstmal einen SVN-Client, ohne den geht leider nichts mehr.
SFN ist halt eine heilige Kuh, jetzt tanze darum...
Guido
Guido schrieb:
> Hallo Michael,>> dich trifft der Fortschritt.>> Installiere erstmal einen SVN-Client, ohne den geht leider nichts mehr.
Blödsinn.
> SFN ist halt eine heilige Kuh, jetzt tanze darum...
Blödsinn.
http://sourceforge.net/projects/welecw2000a/
Falk
>Guido schrieb:>> Hallo Michael,>>>> dich trifft der Fortschritt.>>>> Installiere erstmal einen SVN-Client, ohne den geht leider nichts mehr.>Blödsinn.
Danke.
>> SFN ist halt eine heilige Kuh, jetzt tanze darum...>Blödsinn.
Nochmal, danke.
Du mich auch, Guido
...was'n mit euch los??? SVN-Client??? Heilige Kuh??? Jetzt geht's aber
los hier...
Werde mal den Link von Falk ausprobieren !
Jetzt habe ich mal die 0.90er aufgespielt, bei 50mV, 500mV und 5V ist
das Eigenrauschen minimalistisch im Vergleich zu vorher, ich bin
begeistert!
Nur bei den anderen Spannungen ist das Eigenrauschen enorm. Welec
beschrieb ja auch, das bei den oben angebenen Werten, das Eigenrauschen
am wenigsten ist.
Nun ja, muß ich bei den anderen Spannungseinstellungen jedesmal die
Null-Linie neu Kalibrieren??? Die haben da einen erheblichen Versatz!
...na dann, bis gleich
Gruß Michael
ich noch mal...Jetz muß ich mal blöd fragen, wo ist denn in dem Pack die
das Flash?? Wie soll ich eine "w2000a-screenshot.exe" flashen ??? Habe
hier schon zig Stunden mit lesen verbracht, hab ich da jetzt was
verpeilt???
Gruß Michael
Hallo Robert, wenn ich die "w2000a-screenshot-0.91.gz" runter lade und
entpacke, habe ich nur 3 Files drinnen und genau die 'TomCat.flash' ist
nicht dabei, ist mir ein Rätsel...ich habe mal einen Sreenshot gemacht,
damit du siehst, was ich m meine!
Gruß Michael
eben, da kann ich nix auswählen, warum auch immer, ich sehe die Datei,
kann sie weder anklicken, noch kann ich sie kopieren oder im neuen
Fenster öffnen...vielleicht könntest du sie mal hier anhängen dann wären
wir auf der sicheren Seite bevor ich hier alles zu mülle...
Ich komme da nicht dran, bin jetzt mit meinem Latein am Ende, da steckt
der Teufel drin oder was auch immer, wäre ich vom anderen Geschlecht,
könnte ich es ja evtl. noch verstehen.....uhhh, das war
diskriminierend...'lach'
Gruß Michael
man, was für eine Prozedur...vielen Dank, Robert, genau die wollte ich,
alles drinnen!!!
Ich wünsche auch eine gute Nacht, jetzt langt's, werde morgen das Image
aufspielen und dann mal testen!
Ich hoffe das das Problem mit den Zero-lines bei der 0.91er behoben ist,
da bei mir das die Messungen total verfälscht, muß nach jedem
Eingangswechsel neu Kalibrieren...
LG Michael
> mike0815 schrieb:> man, was für eine Prozedur...vielen Dank, Robert, genau die wollte ich,> alles drinnen!!!
Wie von Guido schon richtig bemerkt: Das ist eben der Fortschritt! (:O
Jedenfalls funktioniert Falk's Experiment gegen Signalverzerrungen
(adc_change12_reg) in der Version 0.91 leider definitiv nicht bei den
4-Kanalgeräten.
Gruß Jürgen
Es scheint Probleme mit den QuickMeasure Funktionen zu geben, sobald ich
Zeitbasen <50ns erreiche - kann das jemand bestätigen?
Risetime, Frequenz, Duty Cycle, +Width, -Width, Periode: alles passt
wunderbar bis 50ns, ab 20ns kommt nur noch Mist raus.
Getestes habe ich mit einem 12,4MHz Rechtecksignal, das ich mit nem R32C
erzeugt habe, Kanal 1, 1V/div, DC-gekoppelt.
Wenn es anderen genauso geht erstelle ich dazu nachher ein Ticket.
Gruß
Michael
Michael H. schrieb:
> Es scheint Probleme mit den QuickMeasure Funktionen zu geben, sobald ich> Zeitbasen <50ns erreiche - kann das jemand bestätigen?
Hallo Michael,
getestet hab ich das noch nicht, aber es ist durchaus möglich, dass Du
recht hast. Da unterhalb von 50 nS die interpolierten Zeitbasen
anfangen, liegen die Signaldaten nicht mehr im Ursprünglichen
Datenbereich, sondern in einem Eigenen für die interpolierten Daten. Das
muß natürlich auch bei QM berücksichtigt werden. Wenn das nicht
geschieht kommt natürlich Mist dabei raus.
Eigentlich ist das Stefans Baustelle, aber wenn er da nicht zu kommt
kann ich da auch mal ein Auge drauf werfen. Ein Ticket ist aber keine
schlechte Idee, dann geht das nicht unter.
Gruß Hayo
Wie von Guido schon richtig bemerkt: Das ist eben der Fortschritt! (:O
...ja was jetzt? Muß ich mich erst registrieren um an die Dateien zu
kommen, oder werde ich hier ein bißchen hoch genommen???
Gruß Michael
mir ist auch noch ein kleiner Schönheitsfehler aufgefallen, wenn ich die
Display-Taste drücke dann Funktionieren alle Menütasten bis auf die
Taste für Grid 33%, 66% und 99%, dies läßt sich nur mit dem Drehrad
ändern. Könnte man das nicht auch auf die Menütaste legen damit man
damit auch wechseln kann ohne einen 2ten Handgriff auf die Drehtaste zu
brauchen? Bei Switch Grid und Switch Drawing geht es doch auch mit einem
Handgriff.
Ich wundere mich, dass kaum noch jemand etwas postet, hier nicht und in
sourceforge auch nicht - gibt es Leute, die sich von der englischen
Sprache abschrecken lassen? Es wäre doch schade, wenn man die vergraulen
würde...und wenn man ehrlich ist, diskutieren ja doch nur
deutschsprachige Menschen bisher.
Oder was könnte noch dahinterstecken, dass die einst rege Diskussion so
eingeschlafen ist?
Hallo,
nur weil nichts gepostet wird heißt das nicht, dass nicht im Hintergrund
die Köpfe rauchen.
Sind alle fleißig bei der Sache und machen Fortschritte, sei es im HDL,
an der Hardware Front oder am PC Frontend.
Was sich in Sachen Firmware tut wage ich derzeit nicht zu beurteilen,
aber sicherlich wird auch da fleißig gearbeitet.
Nicht vergessen Michael, alle machen das aus Spaß an der Freude und
nicht, weil sie dafür bezahlt werden.
Beste Grüße, branadic
In der Tat - die Köpfe rauchen und ich bin nicht untätig (niemals!).
Ich glaube Einige hatten es schon bemerkt, die Sache mit dem neu
gesetzten adc_change-Register hat einen Haken. Wenn das Bit 25
(0x02000000), welches unter Anderem für die Schwingungen verantwortlich
ist, nicht gesetzt ist, dann sind zwar die Schwingungen bei hohen
Frequenzen weg, dafür tritt aber ein anderes Problem auf (deswegen wohl
auch der ganze Zampadu mit den Filterbits). Und zwar gibt es bei
Zeitbasen < 10µS Spikes (und zwar jeweils einen) mit Vollausschlag auf
allen Kanälen am Ende der ADC-Aufzeichnung (so zwischen Wert 14000 und
16000). Die exakte Position ist abhängig von der Zeitbasis immer exakt
die gleiche auf Kanal 1 + 4 und um 5 Werte verschoben auf Kanal 2 + 3
(siehe Bild). Die Ursache ist mir nicht so ganz klar (ob digital oder
analog verursacht).
In der Holiday Edition gibt es bereits eine Lösung für das Problem.
Gruß Hayo
Ich habe mich doch nur gewundert, dass so wenig gepostet wird und mich
gefragt ob das an der englischen Sprache liegen könnte - dass nach wie
vor viele Leute (gerade weil sie es ja aus Spaß machen) an dem Projekt
arbeiten, daran habe ich gar keinen Zweifel.
Du hast eine Lösung für die Spikes gefunden, Hayo? Das wäre ja klasse,
wenn man sich nicht mehr zwischen Spikes und Murks bei hohen Frequenzen
entscheiden müsste! Ich fange langsam an zu sabbern, wenn ich "Holiday
Edition" lese...
Aber wenn dir die Ursache der Spikes auch nicht so recht klar ist, wie
konntest du das ganze beheben?
Gruß,
Michael
Das ist die aktuelle Lösung - korrekt. Ich experimentiere allerdings mit
dem adc_change-Register an einer etwas geschmeidigeren Lösung, weiß aber
nicht ob das hinhaut.
Hayo
Um nochmal meine Ausführungen zur HE aus dem Hardware Thread zu
präzisieren hier ein kleiner Überblick über die Themen an denen ich
arbeite bzw. die schon eingebaut sind.
Im Wesentlichen betrifft das das die Tickets und das Verhalten bei hohen
Frequenzen.
Zur Zeit probiere ich mit verschiedenen Registerwerten herum um die
Spikes wegzukriegen ohne die Schwingneigung bei hohen Frequenzen wieder
einzubauen.
Ansonsten:
- Ticket 3: Autoscale + Rollmode -> erledigt
- Ticket 5: Ich habe die Save / Recall Funktion komplett
überarbeitet/repariert und dabei auch das Ticket erledigt. Es gibt jetzt
auch volle Unterstützung für den USTB-Mode. Weiterhin werden nach
Beendigung des Recalls alle vorherigen Einstellungen wieder hergestellt.
-> erledigt
Ticket 7: Im accurate drawing mode werden Signale die außerhalb des
Darstellungsbereichs liegen nicht mehr "plattgedrückt", sondern nicht
mehr dargestellt. Im schnellen Darstellungsmodus ist alles beim Alten.
Man kann sich also aussuchen welche Darstellung einem besser gefällt. ->
erledigt
Des Weiteren werden noch einige Erweiterungen an der FFT dazukommen.
Alles klar?
Gruß Hayo
Michael H. schrieb:
> Ticket 32 ist doch ein ziemlich alter Hut, also schon lange bekannt -> weiß inzwischen jemand was dahintersteckt?
Also wenn Du mit Denoising misst, ist das Ticket eine Doublette von
#14 ;) - Dort findest Du auch einen Kommentar, was dahinter steckt
und, dass mensch den Fehler ggf. nicht fixen sollte:
Sonst in Kürze:
Durch die Verwendung des "Moving Average Filter" (wandernder
Mittelwert Filter) sind einige Messwerte (Filterlänge - 1 ) nicht
definiert. Da stellt sich eher die Frage, was mensch mit diesen Werten
macht:
a) Mensch verkürzt den Filter zum Ende des Bereiches entsprechend und
ist so in der Lage die Werte darzustellen - schlecht: die
Charakteristik
des Filters wird geändert
b) Mensch nimmt den letzten Wert n'mal und füllt damit die nicht
definierten
Werte auf - auch schlecht - das Signal am Ende ist dann ein Strich
c) Mensch zeigt diese Werte an und verweist in einer FAQ drauf.
Meines erachtens die beste Möglichkeit - das Filterverhalten bleibt
definiert und jeder sieht, dass da Gülle steht ;)
>> Michael
Grüße,
rowue
Hayo W. schrieb:
> @rowue>> Dein Patch (Ticket 26) ist natürlich auch dabei.
Danke! ;)
Noch eine kurze Anfrage meinerseits: wie sähe es denn
von eurer Seite aus aus, mir write-access (Commit-Rechte)
auf das svn zu geben?
Damit könnte ich kleinere Bugfixes und Enhancements
direkt einspielen (grössere Sachen würde ich als
"Schein-Ticket" filen ;) - ohne über das Ticket-System
gehen zu müssen ...
Die Entscheidung braucht nicht "über's Knie" gebrochen zu
werden (mein DSO ist gerade in Böblingen und da ich nicht
testen kann, werde ich da gerade nichts machen) - könnte
aber perspektivisch die Arbeit erleichtern ;)
>> Hayo
Grüße,
rowue
Danke für die Erklärung Rolf, hatte ich bisher nicht mitbekommen.
Mich stört dieses Verhalten schon muss ich sagen, insofern würde ich für
die Lösung plädieren, die entsprechenden Werte durch den letzen gültigen
davor zu ersetzen - es kann sich ja nicht um viele Werte handeln, die so
bearbeitet werden müssen, so dass das Resultat doch recht ansehnlich
sein sollte, oder?
Michael
So die Spikeproblematik ist gelöst. Es gibt tatsächlich einen
Registerwert, mit dem die Spikes unterdrückt werden aber trotzdem keine
Schwingungen auftreten.
Gruß Hayo
Hi,
hab mir ein W2022A bei ebay ersteigert. Warte noch bis es ankommt.
@Hayo W.
Gibt es irgendwo eine übersicht was deine Firmware im Vergleich der
Originalen schon alles kann? Habe auch schon bei Sourceforge.net
gesucht, aber mein Englisch ist nicht so gut.
Oder was gibt es denn noch so für Opensource firmwares dafür? habe Schon
ziemlich lange gesucht, aber konnte das ganze noch nicht so richtig
überschauen.
Gerade habe ich gemerkt, dass, je nach gewählter Zeitbasis, es nach
einem Single Shot mal möglich ist, nach dem Triggerereignis horizontal
reinzuzoomen und mal nicht. Das ist ganz schön lästig!
Dazu erstelle ich nachher gleich noch ein Ticket.
Außerdem habe ich eben an einer Rechteckfunktion "Averaging" als
Acquire-Mode ausprobiert und festgestellt, dass das Ergebnis sehr
bescheiden ist. Mein anderes Oszi zeigt ein Rechteck wie aus dem
Lehrbuch wenn ich Average wähle, beim Welec verbessert sich die
Darstellung dagegen nur ein wenig. Über wie viele Perioden wird denn da
gemittelt?
Ist das auch ein Ticket wert?
Gruß
Michael
Hallo Michael,
das Ticket kannst du dir sparen. Wirf mal einen Blick in Hayos
Programming-Maps, dann siehst du, dass bei mancher Timebase nur
wenige Punkte mehr gesampelt als angezeigt werden. Da ist
narürlich ein Zoomen nicht mehr möglich.
Gruß, Guido
Danke Guido, das hatte ich nicht realisiert. Dann ist das natürlich
klar, lästig ist es aber nach wie vor.
Jemand mit den entsprechenden Rechten kann übrigens Ticket #18 löschen,
da von #31 abgedeckt.
Michael
N'Abend Guido,
ich vermute mal, das ist auch der Grund für die unterschiedlichen
Abhängigkeit zwischen main- und delayed-timebase, oder?
Sind an der Stelle in naher Zukunft Änderungen geplant?
Beste Grüße,
Odic
Hallo Odic und Michael,
da kann ich nur spekulieren. Hayo wollte sich schon lange mal
mit den Timebase-Einstellungen auseinandersetzen, muss aber
ständig andere Baustellen flicken. Ich könnte mir aber
vorstellen, dass da auch noch was zu machen ist, d.h. die
momentane Lösung mit heißer Nadel gestrickt wurde, wie vieles
anderes auch.
Gruß, Guido
Michael H. schrieb:
> Danke Guido, das hatte ich nicht realisiert. Dann ist das natürlich> klar, lästig ist es aber nach wie vor.>> Jemand mit den entsprechenden Rechten kann übrigens Ticket #18 löschen,> da von #31 abgedeckt.
Habe ich gerade gemacht - btw: Ihr solltet auch entsprechende
Informationen an die Tickets anhängen können - somit sollten
nicht immer neue Tickets aufgemacht werden müssen ;)
>> Michael
Grüße,
rowue
Ticket #2 kann vermutlich auch geschlossen werden.
Die FPGA-T51 Entwicklung scheint eingestellt worden zu sein, oder?
Bitte auch Ticket #1 prüfen, bei mir funktioniert der Math-Button
(1.2-OS0.91).
Gruß Bert
Bert schrieb:
> Ticket #2 kann vermutlich auch geschlossen werden.> Die FPGA-T51 Entwicklung scheint eingestellt worden zu sein, oder?> Bitte auch Ticket #1 prüfen, bei mir funktioniert der Math-Button> (1.2-OS0.91).
Hi Bert, dass sind vermutlich beides Tickets aus dem FPGA-Bereich ;)
Wäre evtl. interessant, wenn einige Leute mit "neueren" W2022A's
mal Ihren Math-Button mit der 0.88/0.89 im Gegensatz zu 0.91 prüfen
- ich musste da einen Patch für einen Kollegen mit solch einem
Gerät einbauen (gekauft ca. Juli/August 2009) und es könnte sein,
dass Wittig da einen Stapel Geräte mit Kurzschluss hat - dann
sollten wir den Patch evtl. drin lassen ;)
> Gruß Bert
Grüße,
rowue
Thomas O. schrieb:
> Fettes Dank für die Mühe. Wann kann man die neue Firmware erhaschen?
Heute bzw. nachher.
Michael H. schrieb:
> Na das klingt doch wieder mal super!> Was wie warum da passiert weißt du aber auch nicht, oder Hayo?
Die Ursache ist in der Tat nicht ganz klar, aber man kann durch
Ausprobieren die Zusammenhänge zwischen einzelnen Registerbits und
Anzeigefehlern herstellen.
Sven schrieb:
> Hi,> Gibt es irgendwo eine übersicht was deine Firmware im Vergleich der> Originalen schon alles kann?
Es ist ein Changelog dabei, da stehen alle Änderungen drin. Aber viel
einfacher ist es direkt zu vergleichen. Dazu mußt Du Dein Flash nicht
überschreiben, sondern kannst die Firmware direkt ins RAM laden
(Beschreibung ist dabei). Eigentlich kann man sagen, das die OS-Firmware
alles was die originale Firmware kann (oder auch nicht) besser kann und
auch noch mehr Funktionen hat.
> Oder was gibt es denn noch so für Opensource firmwares dafür? habe Schon> ziemlich lange gesucht, aber konnte das ganze noch nicht so richtig> überschauen.
Keine, es gibt nur dieses Projekt.
Guido schrieb:
> Hallo Odic und Michael,>> da kann ich nur spekulieren. Hayo wollte sich schon lange mal> mit den Timebase-Einstellungen auseinandersetzen, muss aber> ständig andere Baustellen flicken.
In den nächsten Tagen wollte ich dazu mal ein paar Vorabtests machen. Da
wird sich auf jeden Fall noch was tun.
> Ich könnte mir aber> vorstellen, dass da auch noch was zu machen ist, d.h. die> momentane Lösung mit heißer Nadel gestrickt wurde, wie vieles> anderes auch.
Jupp, das sehe ich auch so.
Bis nachher
Hayo
Ok, hier ist sie!
Out now, 0.92 Holiday Edition. Bitte beachtet das Changelog und testet
die neu hinzugekommenen Fixes und Funktionen. Zur Dokumentation benutzt
bitte die beigelegte Screenshotversion, da die anderen Vesionen nicht
kompatibel sind.
Gebt bitte Euer Statement ab, welche der Funktionen in die "OS"-Version
einfließen soll.
Gruß Hayo
Hayo W. schrieb:
> Ok, hier ist sie!>> [Version 0.92HE released]>>
Habe die Version schon mal in das Ticket-System des Trac aufgenommen.
(1.2.BF.0.92HE)
>> Gruß Hayo
Grüße,
rowue
Ich habe den Eindruck, dass die Refresh-Rate mit Noise Filter höher als
früher ist, kann das sein?
Beim Speichern und Laden von Signalen gibt es nach wie vor Probleme: Das
Oszi verstellt beim Laden nicht mehr den Trigger, steht aber immer auf
"Stop" und als ich versuchsweise eine Einstellung mit drei Signalen
gespeichert und geladen habe und anschließend das ganze mit nur einem
Signal, wurden die Nulllinienmarkierungen aller vier Kanäle mit
eingeblendet, Ergebnis war: 2x Kanal 1, die anderen drei jeweils einmal.
Das ist aber wohl nur ein Refresh-Problem, da alles verschwand nachdem
ich einmal auf Kanal 2 gedrückt hatte.
Ich konnte es auch reproduzieren: ein Signal speichern, laden und
anschließend auf "Run/Stop" drücken liefert bei mir den beschriebenen
Fehler.
Sonst habe ich noch nichts getestet, aber ich bin sicher, dass das Welec
damit wieder einen großen Schritt nach vorn gemacht hat.
Danke schonmal für die Verbesserungen!
Michael
Hallo,
Danke hab jetzt den Changelog gefunden, sourceforge.net finde ich ein
bisschen unübersichtlich.
Ist echt Wahnsinn was ihr schon erreicht habt. Morgen müsste mein Oszi
los geschickt werden. Wenn es ankommt kann ich beim Testen helfen. Für
mehr werden meine Programmierkenntnisse nicht reichen.
@Hayo
Danke fuer die HE, bei mir treten die spikes in AUTO mode nun nicht mehr
auf, dafuer habe ich nun manchmal spikes im Normal mode! Die sind leider
viel schwieriger zu erkennen weil sie nicht immer an der selben stelle
im Speicher sind!
N.b. die Delayed Funktion scheint bei 1Gs/sec nicht richtig zu
funkzionieren:
Bis zu 50ns/div ist sie OK (die Darstellung hat einen kleinen Versatz),
aber wen ich weiter zoome (was meiner Meinung nach nicht moeglich sein
sollte) wird nur eine Linie dargestellt (vermutlich ein falscher Bereich
der Daten). und ich kann nicht mehr nach 50ns/div zurueck gehen.
Martin
Danke schon mal für die ersten Testberichte.
@Michael H.
> Ich habe den Eindruck, dass die Refresh-Rate mit Noise Filter höher als> früher ist, kann das sein?
Jein, das kommt auf die eingestellte Zeitbasis an, da je nach
ungenutzten Samplewerten mit unterschiedlicher Filtertiefe gearbeitet
wird. Den Bereich <= 100nS habe ich auf schnelle Shift-Operation
umgestellt statt wie vorher normale Division, weiß aber nicht ob das
schon in der letzten Version drin war oder ob das jetzt neu ist.
> Beim Speichern und Laden von Signalen gibt es nach wie vor Probleme:> Das Oszi verstellt beim Laden nicht mehr den Trigger, steht aber> immer auf "Stop"
Ja natürlich! Da ist wohl die Funktionsweise des Recall unklar. Also
das gespeicherte Signal wird mit allen zugehörigen Einstellungen aus dem
Flash geladen. Damit dann im nächsten Durchlauf das geladene Signal
nicht gleich wieder vom aktuellen Signal überschrieben wird, geht das
Gerät in den Stop-Modus. Durch das Drücken der Stoptaste wird dann der
Stop-Modus und damit auch der Recall beendet -> die alten Einstellungen
werden aus dem Flash wieder hergestellt und der normale Betrieb wieder
gestartet.
> und als ich versuchsweise eine Einstellung mit drei Signalen> gespeichert und geladen habe und anschließend das ganze mit> nur einem Signal, wurden die Nulllinienmarkierungen aller> vier Kanäle mit eingeblendet, Ergebnis war: 2x Kanal 1,> die anderen drei jeweils einmal.
Diese Testkonstellation hate ich noch nicht. Danke für den Tip, werde
ich mal checken.
@Sven
Programmierkenntnisse sind nicht nötig. Mit den Tests helft Ihr mir
erheblich weiter. Da ich nicht die Zeit habe alle Konstellationen zu
testen bin ich auf diese Hilfe angewiesen.
@Martin H.
> Danke fuer die HE, bei mir treten die spikes in AUTO mode nun> nicht mehr auf, dafuer habe ich nun manchmal spikes im Normal mode!> Die sind leider viel schwieriger zu erkennen weil sie nicht immer> an der selben stelle im Speicher sind!
Ok werde ich mal checken. Ich habe alle Tests bislang im AUTO-Modus
gemacht.
> N.b. die Delayed Funktion scheint bei 1Gs/sec nicht richtig zu> funkzionieren:
Da habe ich in dieser Version nichts dran geändert. Das müßte also ein
Fall für die offizielle "OS"-Version (Ticket) sein.
Gruß und danke
Hayo
Hallo Hayo,
Ich habe gerade deine Firmware aufgespielt. Im FFT Menü gibt es einen
Fehler beim Anzeigen des Menüs "Mode". Siehe Screenshot.
Ein weiterer kleiner Bug (war schon in vorigen Versionen). Wenn man
"Autoscale" drückt und danach "Undo Autoscale), werden im oberen Menü
die Spannungsberecihe aller Kanäle angezeigt obwohl nur einer aktiviert
ist. (siehe Screenshot im zweiten Posting).
Der DAC Abgleich funktioniert bei mir nicht korrekt oder ich mach etwas
falsch. Ich stelle alle Kanäle auf 5V/div und starte "Search Zero Lines"
und danach "Calibrate DAC".
Danach stelle ich alle Kanäle auf 2V/div und mach das gleiche.
Stelle ich nun wieder zurück auf 5V/div habe ich auf Kanal 3 und 4 einen
Offset von -0.5div ud auf Kanal einen Offset von +0.25div. Auf Kanal 2
ca einen Offset von +2 Pixel.
Mache ich etwas falsch?
lg Robert
Hallo Robert,
du machst was falsch. ;-)
"Search Zero Lines" nur einmal im 5er Bereich drücken, in den
anderen Bereichen dann nur noch "Calibrate DAC".
Gruß, Guido
@Robert S.
Zum Kalibrieren hat Guido schon alles gesagt. Ansonsten danke für den
Fehlerreport, da hab ich ja wieder was zu tun, bevor das in die
"OS"-Version einfließen kann.
Gruß Hayo
Danke für die Hilfe!!
Ich hab noch zwei Fehler beim Delayed Mode gefunden.
#1: Ist der Delayed Mode aktive und man schaltet das Gerät aus und
wieder an, muss man am Timebase Rad einmal drehen, damit ein Signal
angezeigt wird.
#2: Im Delays Mode wird das Softmenü der Gritintensität nicht
aktualisiert wenn man im Display Menü am zugehörigen Drehencoder dreht
(die Gridintensität ändert sich schon). Wenn man den Delayed Mode
beendet wird wieder die Gridintensität vor aktivieren des Delayed Modes
angezeigt. Sollte man im Delayed Mode einen Screenshot machen, wird die
Grid-Plane mit der Intensität aus dem Main Mode angezeigt, nicht mit der
geänderten.
lg Robert
Hallo
Ich hab mein Oszi erst sehr kurz und benutze aufgrund der Spikes noch
immer die firmware 90.
Nun hab ich eine Frage wieso ist das "Rauschen" bei 1V größer als bei
500mV sollte es da nicht größer werden je kleiner die V Basis ist...
also der Ausschlag? Weil bei mir ist es genau umgekehrt. Im Anhang sind
2 Bilder das bei 1V hat deutliche hügel das bei 500mV nicht mehr so
sehr. (Ich weiß handy Kamera aber gibts ne MAC oder Linux software zum
Screenshot auslesen?)
http://img255.imageshack.us/i/67664861.jpg/http://img171.imageshack.us/i/500mv.jpg/
lg Mike
Hallo Mike,
es gibt auch eine Linuxversion, die ist auch bei der HE dabei.
Die Messbereiche sind grundsätzlich in drei Hauptbereiche eingeteilt,
die sich durch den Skalierungsfaktor unterscheiden. Alle 5er Bereiche
haben einen günstigenren Faktor als die 2er oder 1er. Daher haben aller
5er Bereiche ein geringeres Rauschen als die 2er und 1er Bereiche.
Gruß Hayo
Wie darf ich mir das mit dem Faktor vorstellen? Und ist das ganze schon
"fertig" oder schraubt ihr dort noch herum?
Danke für die schnelle Antwort.
lg Mike
Mike K. schrieb:
> Wie darf ich mir das mit dem Faktor vorstellen? Und ist das ganze schon> "fertig" oder schraubt ihr dort noch herum?
"fertig"? - Was für ein Wort ;)
Wie Du aus dem Text von brunowe weiter oben entnehmen kannst,
hat das DSO vier Verstärker, aus denen sich die Verstärkungsstufen
(1; 1,25)*(1;2;4) -> (1;1,25;2;2.5;4;5) einstellen lassen.
Das Rauschen der ersten beiden Verstärker bleibt etwa gleich
(7nV/sqrt(Hz)+ 20nV/sqrt(Hz) -> 27nV/sqrt(Hz) (ohne Rauschstrom))
und wird mit den nächsten Stufen entsprechend verstärkt.
Jeder der beiden nächsten Verstärker steuert nochmal 20nV/sqrt(Hz)
zu.
Entsprechend verhält sich das Signal/Rauschverhältniss reziprok
zur Amplitude des Eingangssignals.
An der hardwareseitigen Behebung dieses Problems arbeiten derzeit
Leute. Eine Umstellung der Verstärkungsfaktoren (1,25; 2; 4 -> 1;2,5;5)
erfodert weitere Messungen (es gibt hier verschiedene Ergebnisse zur
Durchlasskurve des Gerätes zwischen beiden Serien (W201X, W202X))
und hätte derzeit nur evtl. Vorteile für die Firmware (Geschwindigkeit,
Speicherbedarf ;)
Die dekadischen Stufen (1V, 100mV, ...) werden über ein
Widerstandsnetzwerk abgebildet.
>> Danke für die schnelle Antwort.>> lg Mike
Grüße,
rowue
Gerade habe ich versucht, die oben beschriebenen Spikes im "Normal" Mode
zu beobachten.
Testsignal 5V, 325kHz Rechteck. Es gibt Ausreißer, die ich aber wohl von
dem vom Controller erzeugten Signal kommen - die diversen
Rechtecksignale die ich damit generiere koppeln ganz gut gegenseitig
über.
Vielleicht kann das noch jemand mit professionelleren Mitteln testen?
Obwohl: wenn ich mit Single Shot eine Aufnahme nach der anderen mache,
erwische ich - selten, aber immerhin - einen Spike mit ca. derselben
Amplitude wie das Rechteck, der eigentlich nicht vom Signal herrühren
kann. Leider ist bei der HE das alte Problem mit dem zerstückelten
Screenshot wieder da (ja, ich habe screenshot_0.4BF verwendet), so dass
ich keinen ansehnlichen Shot erstellen konnte. Der Spike erschien bei
mir stets recht nah am rechten Bildschirmrand und hatte immer gleiches
Aussehen.
Obwohl ich nur mit Kanal 4 gemessen habe, war übrigens die ganze Zeit
das Triggersymbol von Kanal 2 eingeblendet - wahrscheinlich hilft ein
Refresh an passender Stelle?
Die anderen Spikes scheinen wirklich verschwunden zu sein, sehr schön.
Gruß
Michael
Nachtrag zum Triggersymbol:
Siehe Screenshot.
Ich habe mit Kanal 4 gemessen, Trigger stand auf Source 4. Trotzdem war
auch das Triggersymbol von Kanal 2 eingeblendet. Also habe ich mal auf
Source 2 geschaltet und am Trigger gedreht - dabei entstand dann das
Bild, das ihr hier sehen könnt.
Wenn ich Source 1 wähle, kann ich entsprechend nochmal beliebig viele
1er Triggersymbole dazuzaubern usw.
Gruß
Michael
Sorry wenn ich nochmal ne blöde Frage stelle.
Mein oszi ist heute gekommen. Hab erstmal ein backup von allem gemacht,
das ging 3 1/2 Stunden. Jetzt will ich zum test mal euere Firmware drauf
machen, dies dauer jetzt aber ca. 6h. Ist das normal? Ich habe ein USB
to RS232 converter vom Reichelt.
Kann ich das update jetzt einfach abbrechen und dann über das perl
Script machen? Da solls ja schneller gehen.
Ich habe vor ewigkeiten ja schonmal davon geredet, dass "bald" eine
Version des FPGA-Redesigns zur verfügung stünde, mit dem man schonmal
"spielen" kann. Neben Studiums-Endspurt-Stress kamen diverse Probleme
mit dem Design hinzu, und große Teile wurden seitdem überarbeitet oder
neu implementiert. Außerdem habe ich nun tatkräftige Unterstützung bei
der Entwicklung!
Nach langer Zeit gibt's also mal wieder was zu zeigen:
http://www.youtube.com/watch?v=vwSE2alpnYQ
Viel Spaß damit
Daniel
Michael H. schrieb:
> Leider ist bei der HE das alte Problem mit dem zerstückelten> Screenshot wieder da (ja, ich habe screenshot_0.4BF verwendet), so dass> ich keinen ansehnlichen Shot erstellen konnte.
Den Effekt hatte ich mal unter Linux. Bei mir funktioniert allerdings
jetzt alles. Sonst unter Windows das BMP-Format verwenden.
Hayo
Hallo Sven,
für das schnelle Update benötigst Du Pearl! Unter Windows sollte es so
gehen (Zitat von viel weiter oben):
-----
Ich verwende ActivePerl 5.8.8 (habe ich von
http://www.oldapps.com/Perl.php geladen).
Zusaetzlich benoetigst du das Modul Win32:SerialPort
Am einfachsten ist die Installierung via Perl Package Manager (PPM):
1. Neues Repository eintragen via Edit -> Preferences
und den Reiter Repositories
Name: Bribes
Location: http://www.bribes.org/perl/ppm
(ein ausfuerliches help findest du unter
http://www.bribes.org/perl/ppmdir.html)
2. Jezt kannst du das Modul Win32-SerialPort installieren:
Zeile mit Win32-SerialPort suchen und an klicken
Action -> Install Win32-Serialport 0.19
Das sollte alles sein.
-----
Ich hatte Anfangs auch Probleme mit Pearl und habe später gemerkt, dass
ein Nullmodemkabel das Problem dann behoben hat! Man ist versucht, den
Reichelt-Adapter direkt mit dem Scope zu verbinden (passt ja!),
allerdings sind dann RX und TX vertauscht. Also: Nullmodem-Kabel!
Den Rest findest Du im Updatepaket beschrieben.
Michel
Hi Michael,
habs gestern dann einfach weiter laufen lassen, weil ich nicht wusste
was passiert wenn ichs abbreche.
Heute morgen warens angeblich nur noch 18s bis es fertig ist, aber es
kamen nur timeout Fehler. Also musst ichs abbrechen, aber die Firmware
von hayo ist nun drauf und funktioniert auch so weit.
Hatte den adapter direkt (ohne nullmodem- Kabel) drauf gesteckt. Wenn
TxD und RxD vertauscht wären dürfte ich doch gar keine Verbindung
bekommen, oder?
Ist das beiligende RS232 Kabel ein Nullmodem- Kabel? mit diesem hab ich
grad mal einen Software Download gestartet, das geht auch nicht
scneller.
@Sven
Beim downloaden mit Perl der Original Firmware brauchst du zirka 1Std
fürs spätere uploaden der hier erhältlichen firmware per perlskript
brauchst du 5min
lg Mike
hast du denn auch die Baudrate von 115200 am Port eingestellt?
Also ich hatte heute das erste mal das Perlskript benutzt, nach 3min war
alles drinnen, ich dachte schon, es wäre nur die Hälfte angekommen, war
aber alles i.O.
Wie kann so ein extremer Zeitunterschied zwischen den beiden
Flash-Methoden sein???
Gruß, Michael
Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine
Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der
Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so?
Zu #38: Auch bei mir kommt es mit der HE immer wieder vor, dass nichts
angezeigt wird, obwohl alle Einstellungen korrekt sind. Nach einiger
Rumdreherei erscheint das Signal dann auf einmal wieder.
Ich werde auch nochmal versuchen, das nachzustellen.
Gruß
Michael
Michael H. schrieb:
> Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine> Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der> Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so?>
Es existieren Samplerates von 50 und 100 MSa/s, diese sind aber auch
in der Zeitbasis schwer auszuselektieren.
> Zu #38: Auch bei mir kommt es mit der HE immer wieder vor, dass nichts> angezeigt wird, obwohl alle Einstellungen korrekt sind. Nach einiger> Rumdreherei erscheint das Signal dann auf einmal wieder.> Ich werde auch nochmal versuchen, das nachzustellen.
Ich konnte mittlerweile das Signal durch Drehung der
Verstärkereinstellung
wieder "sichtbar" machen.
>> Gruß> Michael
Grüße,
rowue
PS: Sachdienliche Hinweise zu den Tickets können gerne an die
entsprechenden Tickets angehängt werden ;)
PPS: Die neue FW sieht gut aus, hat aber leider einige neue Bugs.
QM mit Zeitbasen <50ns funktioniert leider immer noch nicht
(Skalierungsproblem?)
Hallo Leute,
ich war zwischenzeitlich etwas beruflich eingespannt, so dass ich leider
nicht zu meiner Lieblingsbeschäftigung gekommen bin. Eure Beiträge und
Fehlermeldungen habe ich dennoch verfolgt und werde eine korrigierte
Fassung der HE in Kürze hier posten damit wir das dann mal endlich in
die OS Version reinpatchen können.
Ich war aber trotz alledem nicht untätig. In der Zwischenzeit habe ich
mich mit anständigem Mess-Equipment eingedeckt, um mal zuverlässige
Aussagen zum Einsatzbereich (Bandbreite und Signalintegrität) der W201x
und W202x Geräte machen zu können (HP3325A Präzisionssignalgenerator,
Tektronix 2465A 350MHz Oszilloskop). Wollen doch mal sehen was die W20xx
so hergeben mit den neuesten Firmwareänderungen.
@Rolf
Kein Skalierungsproblem. Wie schon weiter oben gesagt liegt es mit
ziemlicher Sicherheit daran, dass die interpolierten Daten in anderen
Speicherbereichen liegen. Ob ich dazu auch noch komme weiß ich
allerdings nicht.
Gruß Hayo
Michael H. schrieb:
> Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine> Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der> Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so?
Nein, der Grund ist entweder ein Fehler im FPGA-Design oder nur die
vergurkte Firmwareprogrammierung. Ob Ersteres zutrifft ergründe ich
noch. Wenn es nur die Firmware ist werde ich das auf jeden Fall
nachrüsten, beim FPGA-Design kann ich nicht viel machen, außer die
Sampletiefe und die Samplerate etwas geschickter zu verteilen als
momentan. Da bleibt dann nur der Umstieg auf eins der neuen FPGA-Designs
(siehe Hardware-Thread).
Gruß Hayo
Hi Hajo,
bei mir steht auch noch ein HP8116A und ein Grundig FG100,
ersterer könnte interessant sein, wenn wir mal in höhere
Bereiche gehen wollen ;)
Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5
umzuschalten - dann hätten wir in allen Bereichen die
gleiche Aussteuertiefe (habe schon etwas dran gespielt,
muss da aber noch mal ran;)
Grüße,
rowue
rowue schrieb:
> Hi Hajo,>> bei mir steht auch noch ein HP8116A und ein Grundig FG100,> ersterer könnte interessant sein, wenn wir mal in höhere> Bereiche gehen wollen ;)
Nette Ausrüstung, kann der HP auch noch mehr als 50MHz (via Rear Panel
Ausgang) ?
> Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5> umzuschalten - dann hätten wir in allen Bereichen die> gleiche Aussteuertiefe (habe schon etwas dran gespielt,> muss da aber noch mal ran;)
Wie hast Du die Umschaltung gemacht (Softwareseitig oder
Hardwareseitig)?
Werde gleich mal die ersten Ergebnisse meiner Vergleichstests
veröffentlichen, allerdings wie es sich gehört im Hardwarethread.
Gruß Hayo
Hayo W. schrieb:
> rowue schrieb:>> Hi Hajo,>>>> bei mir steht auch noch ein HP8116A und ein Grundig FG100,>> ersterer könnte interessant sein, wenn wir mal in höhere>> Bereiche gehen wollen ;)>> Nette Ausrüstung, kann der HP auch noch mehr als 50MHz (via Rear Panel> Ausgang) ?
Müsste ich mal prüfen - tendentiell eher nicht, wobei
ich allerdings in der FFT auch bei 50MHz die Oberwellen bis
200MHz klar erkennen kann (inkl. des von Andre beschriebenen
"überziehens")
>>> Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5>> umzuschalten - dann hätten wir in allen Bereichen die>> gleiche Aussteuertiefe (habe schon etwas dran gespielt,>> muss da aber noch mal ran;)>> Wie hast Du die Umschaltung gemacht (Softwareseitig oder> Hardwareseitig)?
Über die Bit-Register - also Hardwareseitig - ich habe
als Skalierungsfaktoren (auf die 400 px) mittels Messung
2,55;2,56;2,55 herausbekommen (wobei der theor. Wert bei
2,4606 liegt) und will als nächstes Nachschauen, wie ich
den "ZeroScaleFactor" bestimme, auch, wenn mir die Werte
bekannt vorkommen ;)
Neben dem evtl. Vorteil, nur zwei Werte (delayed, normal)
für die Darstellung auf dem Bildschirm zu haben, hätte
das noch in der Auswertung den Vorteil nicht ständig die
veränderten Verstärkungen der einzelnen Stufen einbeziehen
zu müssen. Dafür hätten wir halt nur um die 156 Bit zur
Verfügung :(
>>> Werde gleich mal die ersten Ergebnisse meiner Vergleichstests> veröffentlichen, allerdings wie es sich gehört im Hardwarethread.>
o.k. ;) - Oder im SF-Forum ;)
> Gruß Hayo
Grüße,
rowue
(Sorry für "Hajo" ;)
Hallo Hayo und Rolf,
die Verstärkungen 1, 2.5, 5 habe ich in BF0.56 schon mal getestet.
Ich habe dafür folgende Einstellung in Hardware::Setswitches verwendet:
Guido schrieb:
> Hallo Hayo und Rolf,>> die Verstärkungen 1, 2.5, 5 habe ich in BF0.56 schon mal getestet.> Ich habe dafür folgende Einstellung in Hardware::Setswitches verwendet:>>
1
>
2
>case0:dat_buf=0x0005;break;
3
>[...]
4
>
5
>
>> @ Rolf: Hast du das auch so?
Genau so ;)
Ich habe dann mit dem HP in den 50, 20, 10 mV/DIV Stufen jeweils die
Gleich-Spannungen in 1DIV Schritten von -4 DIV bis 4 DIV(*) eingestellt,
mit dem Multimeter kontrolliert (0,3% Messgenauigkeit, in der weiteren
Fehlerfortpflanzung vernachlässigt) und die (Roh-)Daten
(bandbreitenbegrenzt) ausgelesen.
Von diesen Rohdaten habe ich jeweils die ersten 2048 Sätze genommen und
die Mittelwerte gebildet. Mit diesen Mittelwerten (inkl. Fehler) habe
ich dann eine lineare Regression (Fit mit Polynom ersten Grades) im
Bezug auf Bits/DIV durchgeführt. Es ergaben sich folgende Zusammenhänge:
Als Skalierungsfaktoren für die Software hätte ich somit (**)
1
10mV/DIV:2,5651pm0,0229
2
20mV/DIV:2,5615pm0,0198
3
50mV/DIV:2,5469pm0,0173
Mit folgenden Auflösungen [mV/Bit]:
1
10mV/DIV:0,513pm0,0046
2
20mV/DIV:1,0246pm0,0079
3
50mV/DIV:2,5469pm0,0173
Wenn gewünscht, kann ich die Änderungen an tc_hardware.cpp mal in's svn
spühlen, dann können hier weitere Messungen zur Auflösung, etc
vorgenommen werden - ich gehe da schon von - leichten - Unterschieden
auf Grund der Bauteilstreuung aus.
Die angegebenen Fehler beziehen sich auf die Fehler der Anpassung (wie
gut passt eine Kurve mit dieser Steigung auf die Messpunkte). Für die
Fehler der berechneten Mittelwerte habe ich mal den mittleren relativen
Fehler berechnet:
1
10mV/DIV:1,3653%
2
20mV/DIV:1,0736%
3
50mV/DIV:0,8531%
(ja, ich habe gepfuscht und die Standardabweichung des Fehlers nicht
angegeben ;)
>> Gruß, Guido
Grüße,
rowue
(*) Also für 200mV/DIV z.B. von -200mV bis 200mV in 50mV Schritten.
(**) Ich habe die Daten gerade noch mal ausgewertet, deshalb der
Unterschied zum vorherigen Posting.
Rolf Würdemann schrieb:
> Guido schrieb:>> [...]>> (*) Also für 200mV/DIV z.B. von -200mV bis 200mV in 50mV Schritten.
Soll natürlich 50mV/DIV heissen ;)
> [...]
@Rolf
Ich habe mal die Messungen in den Hardwarethread gestellt. Leider stehen
mir nur bis 10 MHz die präzisen Rechtecksignale zur Verfügung. Darüber
habe ich nur ein nicht ganz so sauberes Hilfssignal, dass ich auf der
Rückseite des Funktionsgenerators abgreifen kann. Zudem habe ich da auch
nur einen nicht einstellbaren recht kleinen Signalpegel. Da wäre eine
Meßreihe mit Deinem 50 MHz Pulsgenerator sicher ganz interessant, zumal
man da dann auch die verschiedenen Spannungsbereiche miteinander
vergleichen könnte.
Gruß Hayo
moin erstmal,
ich habe folgendes bei der Nullinienkalibrierung in fast allen
Bereichen (Feintuning nur mit der DAC-Taste) festgestellt: bei
mehrmaligen betätigen, war der erste Kanal nicht auf null zu bekommen,
erst nach mehrmaligen verschieben des 1. Kanals (W2022A)nach oben(dann
jedes mal die DAC-Taste betätigt), hat sich die Kalibrierung auf null
eingestellt !
Im Quickmeasure habe ich zwischen beiden Kanälen einen Messunterschied
(egal ob 1V, 2V oder 5V-Bereich) von 0,5V -0,7V! Erst wenn ich beide
Kanäle in den unteren Bereich des Bildschirms verschiebe, sind die
gemessenen Spannungen gleich!
Ich hoffe, die Info war nützlich...
Gruß, Michael
Hayo W. schrieb:
> @Rolf>> [Pulsgenerator]
Hi Hayo,
sorry erstmal für die späte Antwort - ich hatte die letzten
Tage etwas sehr mit den 1;2.5;5 Faktoren und ihrer Abbildung
im Source gespielt ;)
Ich sehe mal zu, dass ich mir am WE noch das 2022A von
'nem Kollegen ausleihen kann, um dann mit beiden Geräten
entsprechende Aufnahmen zu machen. Allerdings könnte
es noch interessant sein, dies mit Deinem Tek zu vergleichen
(da ja die Bandbreite, etc. des HP nicht bekannt ist).
Alternativ könnte ich mit einigen Annahmen die "theoretischen"
Ausgangssignale des HP simulieren und dagegen stellen.
>> Gruß Hayo
Grüße,
rowue
mike0815 schrieb:
> moin erstmal,
Mohltiet ;)
> [Problem mit der DAC-Kalibrierung]
@mike0815:
Welche Version nutzt Du? Die 0.92HE oder die 0.91OS?
@Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder
Deiner letzten?
Ich weiss, dass Falk was an der ADC-Kalibrierung geändert
hat (r176, r178, die vor Deinem Urlaub war r172). Ich habe
bei meinen Spielereien (Faktoren) das Problem symmetrisch
zur Null-Linie (leicht, proportional zum Abstand).
>> Gruß, Michael
Grüße,
rowue
Rolf Würdemann schrieb:
> @Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder> Deiner letzten?
Meiner letzten! Die Änderungen von Falk sind also nicht drin. Was hat er
denn geändert? Hat er die Kalibrierung verbessert, oder "nur" das
Handling verändert?
Gruß Hayo
Hallo Rolf,
> [Problem mit der DAC-Kalibrierung]
...ich nutze die letze Ver.92HE auf W2022 (Hardwarever. 8C7.0L)
...du meine Fres.., eben mach ich das Teil an, da sind beide Nullinien
(Kanal 1+2 1V-Div)1,5 Teilstriche nach unten gerutscht, nach 1x
Dac-Abgleich, geht der 2.Kanal exakt auf null, der 1.Kanal zickt noch
herum.
Wenn ich die Nulllinie (nur 1.Kanal)mehrmals nach unten u. oben
verschiebe und nach jedem schieben die DAC drücke, bequemt auch er sich
endlich aufzusetzen!
Ich dachte, die Kalibrierung wird nach dem Abgleich in die Config
geschrieben und dann abgespeichert, nein, doch???
Jetzt hatte ich nochmal abgeschaltet und neu hochgefahren, die
Nulllinien waren wieder etwas verschoben, nach 1x DAC drücken war's dann
wieder Ok.
...liegt das jetzt explizit nur an meinem Gerät, oder habt ihr dasselbe
Problem???
Gruß, Michael
mike0815 schrieb:
> Ich dachte, die Kalibrierung wird nach dem Abgleich in die Config> geschrieben und dann abgespeichert, nein, doch???
Jupp, wird sie.
> Jetzt hatte ich nochmal abgeschaltet und neu hochgefahren, die> Nulllinien waren wieder etwas verschoben, nach 1x DAC drücken war's dann> wieder Ok.> ...liegt das jetzt explizit nur an meinem Gerät, oder habt ihr dasselbe> Problem???
Hmm, das muß ich mal überprüfen. Die 0.93HE steht in den Startlöchern.
Da hat sich einiges getan. Unter anderem habe ich die Startupsequenz
komplett geändert um den Reload aus dem Flash für jede Ausgangssituation
zu gewährleisten und nebenbei das gemeldete Problem mit dem Restart nach
Delayed-Betrieb zu beseitigen.
Vielleicht läßt sich das dann gleich mit erledigen.
Gruß Hayo
Da es sich nicht um offizielle Releases handelt, sondern um
Testversionen poste ich sie hier. Die 0.92HE findest Du etwas weiter
oben, die 0.93HE kommt in Kürze auch hier. Dabei handelt es sich im
Wesentlichen um eine Fehlerkorrektur der in der 0.92HE gemeldeten
Fehler. Allerdings habe ich dafür einige Sachen komplett umgestrickt, so
dass es über eine einfache Korrektur doch schon hinausgeht.
Hayo
Hallo Hayo,
> Die 0.93HE steht in den Startlöchern. <
ach, das wird wieder eine HE?? Ist ja wurscht, ich bin schon ganz
gespannt, wann ist denn mit der 093HE zu rechnen?
Jedenfalls, macht es hier einen riesen Spass!
Ich selber bin noch in der Aufbauphase was den Umgang mit Oszilloskopen
betrifft, da es mein Erstes ist...nach 35 Jahren...'lach'
Immerhin habe ich keine Probleme beim Backup und Flashen, Quartus und
der USB-Treiber von Slog ist ebenfalls installiert und funzt ohne
Probleme, würde ja gerne mehr experimentieren, nur habe ich so manche
Bedenken, beim Aufspielen z.B. EPCS16N aufzuspielen, nicht das ich da
noch was versaue!!!
Schade, das die Google-Groups nicht mehr so gepflegt wird, da ich diese
für übersichtlicher halte als die SVN.
Vielleicht könnte man von dem Projekt einige Kopien dort hinein setzen
und somit auch die eine oder andere Anleitung zusätzlich auf Deutsch
übersetzen, (so wie es z.B. in den Flashversionen) damit auch der eine
oder andere Anfänger, so wie ich es bin, einen besseren Durchblick
erhalten!!!
Hoffentlich gibt's jetzt kein Augenrollen bei den Profis...
Mein Gedanke dabei ist, das sich dann auch weniger Versierte hier
beteiligen und ihren Beitrag zum Projekt leisten können, denn viele
Augen, sehen auch mehr...und wenn es auch nur Kleinigkeiten sind
(vielleicht mit großer Wirkung), die Andere nicht sehen oder gesehen
haben.
Wie auch immer, wäre nur ein Vorschlag von mir...
Grüsse an alle aus dem Hessenland
@ mike0815: kleine Korrektur noch: Die Kalibrierwerte werden im
Flash gespeichert wenn du die Zeitbasis verstellst. Erst danach
ausschalten.
Gruß, Guido
mike0815 schrieb:
> ach, das wird wieder eine HE??
Ja ich dachte mir da es im Prinzip eine fehlerkorrigierte 0.92HE ist
werde ich das HE mal mit anhängen um den Bezug herzustellen und um
klarzustellen, dass es keine offizielle Version aus dem SFN ist.
> Jedenfalls, macht es hier einen riesen Spass!
Das geht uns allen auch so, daher verbraten wir hier ja auch soviel Zeit
anstatt soziale Kontakte zu pflegen ;-)
> Ich selber bin noch in der Aufbauphase was den Umgang mit Oszilloskopen> betrifft, da es mein Erstes ist...nach 35 Jahren...'lach'
Ist doch zum Kennenlernen von Theorie und Praxis geradezu ideal dieses
Projekt!
> Immerhin habe ich keine Probleme beim Backup und Flashen, Quartus und> der USB-Treiber von Slog ist ebenfalls installiert und funzt ohne> Probleme, würde ja gerne mehr experimentieren, nur habe ich so manche> Bedenken, beim Aufspielen z.B. EPCS16N aufzuspielen, nicht das ich da> noch was versaue!!!
Da kann ich wenig zu sagen, da ich mich bislang größtenteils auf die
reine FW-Entwicklung konzentriert habe. Allerdings wollte ich das bei
Gelegenheit auch mal ausprobieren.
> Schade, das die Google-Groups nicht mehr so gepflegt wird, da ich diese> für übersichtlicher halte als die SVN.
Das fand ich auch, da ließen sich recht unkompliziert einfach mal ein
paar Dokus oder Softwarebundles ablegen.
> Vielleicht könnte man von dem Projekt einige Kopien dort hinein setzen> und somit auch die eine oder andere Anleitung zusätzlich auf Deutsch> übersetzen, (so wie es z.B. in den Flashversionen) damit auch der eine> oder andere Anfänger, so wie ich es bin, einen besseren Durchblick> erhalten!!!
Leider wurde die Seite für den Upload gesperrt und wird vermutlich auch
nicht wieder geöffnet um den Fokus auf die SFN-Seite zu setzen.
Gruß Hayo
Guido schrieb:
> @ mike0815: kleine Korrektur noch: Die Kalibrierwerte werden im> Flash gespeichert wenn du die Zeitbasis verstellst. Erst danach> ausschalten.
Hi Guido, kleine Korrektur meinerseits, seit einigen Versionen (frag
mich jetzt nicht nach der genauen) werden die Einstellungen direkt
gespeichert. Das erkennst Du an folgendem Coding:
//Save new values to flash
config_changed = true;
Diese Variable wird beim Durchlauf der Hauptschleife jeweils einmal
ausgewertet und wenn sie gesetzt ist werden alle gerade aktuellen
Konfigurationsdaten ins Flash geschrieben.
Gruß Hayo
Hallo,
> > Die 0.93HE steht in den Startlöchern. <>ach, das wird wieder eine HE?? Ist ja wurscht...
Also mir ist das ganz und gar nicht wurscht!
Ab dem 05.10 werde ich wieder an der GUI weiter entwickeln (Mein
Co-Programmierer ist derzeit anderweitig beschäftigt).
Leider ist in den HE Versionen der Datentransfer nicht im vollen Umfang
verwirklicht (Befehlssatz gem. SF), demzufolge kann ich diese nicht zur
Entwicklung heranziehen! Die in den Grundzügen bereits vorhandene GUI
baut ergo auf die OS 0.91 auf.... schade, da mit dieser Version bei mir
massive Probl. bei höheren Freq. auf Ch1 auftreten.
Gruß, brunowe
hallo Hayo,
> Ja ich dachte mir da es im Prinzip eine fehlerkorrigierte 0.92HE ist...<
...stimmt, bin ich ganz deiner Meinung!!!
> ...anstatt soziale Kontakte zu pflegen ;-) <
nun ja, man(Mann) sollte das tun, was ihm Spass macht, das Leben ist
kurz...
> Ist doch zum Kennenlernen von Theorie und Praxis geradezu ideal dieses
Projekt! <
ABSOLUT!!!
> Da kann ich wenig zu sagen, da ich mich bislang größtenteils auf die
reine FW-Entwicklung konzentriert habe. Allerdings wollte ich das bei
Gelegenheit auch mal ausprobieren. <
Das ist auch gut so, denn so hat jeder seinen Part, der Tag hat ja nur
24 Std.(leider)
> Das fand ich auch, da ließen sich recht unkompliziert einfach mal ein
paar Dokus oder Softwarebundles ablegen. <
ist das denn im SVN nicht auch möglich??? Ja ich weiß, Innternational
(Die Russen sehr aktiv...)
Nur könnte das eine oder andere in Englisch falsch verstanden werden,
also mir geht's manchmal so, dann komme ich in's schleudern, wie wäre es
mit Kopien in deutscher Sprache??? Ich denke, das das der eine oder
andere Hobbyist begrüssen würde, da ja nicht alle der englischen Sprache
(z.B. Spezialausdrücke...) mächtig sind.
> Leider wurde die Seite für den Upload gesperrt... <
hmm, wieso das denn? Könnte man das nicht parallel bestücken, oder wäre
da der Aufwand zu groß???
Gruß Michael
Hayo W. schrieb:
> Diese Variable wird beim Durchlauf der Hauptschleife jeweils einmal> ausgewertet und wenn sie gesetzt ist werden alle gerade aktuellen> Konfigurationsdaten ins Flash geschrieben.
Erfolgt das Setzen in Interrupt-Handlern? Dann erfolgt das
Rücksetzen&Flashen hoffentlich unter Ausschluss von weiteren Interrupt?
;)
hallo brunowe,
>Also mir ist das ganz und gar nicht wurscht!<
...das konnte ich ja nicht wissen, wie werdet ihr euch denn da jetzt
einig? Jetzt wird's kompliziert, wenn sich die Versionen dermaßen
unterscheiden?!?
...un nu?
Gruß Michael
@Bruno
Wenn die 0.93HE hier getestet wurde und keine größeren Fehler mehr
auftreten, können die Änderungen in die OS-Version einfließen. Bislang
war das Ganze noch nicht ausgereift genug um es einfach da rein zu
mergen. Es handelt sich doch zum Teil um recht umfangreiche Änderungen,
daher möchte ich vorher sichergehen das da dann nicht neue Fehler mit in
die OS-Version eingebaut werden (so wie sie ja in der 0.92HE vorhanden
waren). Die wären ja ansonsten jetzt schon mit drin.
Andererseits muß ich erst prüfen ob ich alle Änderungen der OS-Version
auch in meiner eigenen Version haben möchte. Mir fehlt da momentan der
Überblick ob das alles stabil läuft und ungeprüft will ich das nicht
einfach so übernehmen.
Gruß Hayo
Ich nochmal zum "DAC-Abgleich"
...habe festgestellt(W2022A-092HE), das wenn ich die DAC-Kalibrierung
durchgeführt habe und dann den NOIS Filter einschalte, ich nochmals
einen Abgleich durchführen muß (DAC-Taste drücken), diesmal nur 1x in
den 5er-Bereichen, in allen anderen Bereichen, muß ich mindestenst 1-4x
die DAC-Taste drücken, dann erst ist alles hübsch!
Dann hätte ich noch eine Frage zum Coupling-Mode, was für eine Bewandnis
hat es mit dem PROBE-Softkey? Welche Funktion hat er? Kann ich intern
1:1 - 1000:1 schalten oder was hat er für eine Funktion?
Gruß Michael
Wenn du einen Tastkopf mit Vorteiler anschließt, muss das Oszi das doch
wissen, damit trotzdem die richtigen Spannungswerte angezeigt werden.
Wenn du den Tastkopf von 1:1 auf 10:1 umschaltest, wird doch sonst Mist
angezeigt.
Gruß
Michael
Michael H. schrieb:
> Wenn du einen Tastkopf mit Vorteiler anschließt, muss das Oszi das doch> wissen, damit trotzdem die richtigen Spannungswerte angezeigt werden.> Wenn du den Tastkopf von 1:1 auf 10:1 umschaltest, wird doch sonst Mist> angezeigt.>> Gruß> Michael
...logisch! Ist denn der 'MIST', der da angezeigt wird, so erheblich
bzw. die Werte falsch? Wenn ich am Tastkopf 10:1 eingestellt habe, dann
habe ich z.B. 680mV als 6,8V umgerechnet...
...nun ja, das ist dann natürlich eine angenhme Sache, d.h. wenn ich den
Tastkopp auf 10:1 stelle muß ichh den PROBE-Knopp auch auf 10:1
schalten?
Habe das eben mal gestestest: Tastknopp 10:1 und Probeknopp ebenfalls
auf 10:1 und wieder zurück auf 1:1...
Es gibt vom Messverhalten keinen Unterschied beim verstellen des
PROBE-Knopp's!
...und stimmt, bei Tastkoppschalter 1:10 kommt Müll raus, ist da jetzt
der Eingang hinüber, oder was?
Gruß Michael
So, jetzt muss ich doch mal meinen Senf dazu geben!
Hayo W. schrieb:
>Da es sich nicht um offizielle Releases handelt, sondern um>Testversionen poste ich sie hier. Die 0.92HE findest Du etwas weiter>oben, die 0.93HE kommt in Kürze auch hier. Dabei handelt es sich im>Wesentlichen um eine Fehlerkorrektur der in der 0.92HE gemeldeten>Fehler. Allerdings habe ich dafür einige Sachen komplett umgestrickt, so>dass es über eine einfache Korrektur doch schon hinausgeht.>Hayo
Was heisst hier"nicht offizielle Releases"? Du hast doch mindestens 90%
der bisherigen (NIOS1-) Firmware Entwicklungsarbeit geleistet und hast
mittlerweile den besten Überblick über Struktur und Konzept! Für mich
und sicher auch andere ist es immer noch das offizielle Release, da
nicht nur punktuell an einigen Ecken geändert wurde! Und, so umfangreich
waren die bisherigen Änderungen in der 0.91 ja wohl nun doch nicht, daß
sie nicht mit einer 0.93HE zusammen geführt werden könnten.
Deshalb bitte: Die 0.93HE wieder mit Sourcen veröffentlichen, damit man
sich ein Bild machen kann, wo denn nun die Ergänzungen der
sogenannten"offiziellen Version"liegen!
Musste ich mal loswerden.
Gruß Jürgen
Hallo Jürgen,
mein Vorschlag als einer der Ersten der das Projekt überhaupt zum Leben
gebracht hat...
melde dich bei SF an, und merge die Versionen!!!
Trotz SVN ist genau das die Arbeit, vor der sich derzeit jeder etwas
scheut...
Gruß, brunowe
Hi,
der Grund warum ich erstmal keine Sourcen beigelegt habe ist, dass ich
eine Abspaltung der Entwicklungslinie verhindern wollte. Wenn jemand die
Sourcen in die OS-Version mergen möchte lege ich die Sourcen aber gerne
bei.
Ich selbst entwickle zur Zeit immer noch auf der Basis meiner eigenen FW
da mir die Änderungen an der OS-Version nicht verifiziert bzw. validiert
genug sind. Mir fehlt da momentan der Überblick wer da alles an welchen
Baustellen herumflickt und ob das alles richtig gestestet wird. Daher
ist es mir (zumindest momentan) lieber, die Änderungen die ich in meiner
FW ausgiebig getestet habe nachträglich in die OS-Version einfließen zu
lassen, bzw. sinnige Änderungen aus der OS-Version zu übernehmen.
By the way: gibt es einen konkreten Status zur Remoteschnittstelle und
zur Screenshotfunktion? Läuft das stabil?
Gruß Hayo
Hallo Hayo,
der Status der implementierten Befehle ist hier dokumentiert:
http://sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPI
Das USB Protokoll ist hier beschrieben:
http://sourceforge.net/apps/trac/welecw2000a/wiki/USB-Protocol
Der Datentransfer via RS232 läuft absolut stabil. Leider lassen die
derzeit möglichen 115kBd keine tolle refresh- rate bei meiner GUI zu.
Die RS232 ist da eindeutig der limitierende Faktor was z.B. die live
Darstellung einer FFT betrifft (ca. 2-3 Bilder/s). Im neuen VHDL Design
kann die Transfer- Rate wohl zumindest auf 230kBd gesteigert werden,
aber da sollen sich die VHDL Profis ruhig noch etwas spielen.
Gruß, brunowe
Bruno We schrieb:
> Im neuen VHDL Design> kann die Transfer- Rate wohl zumindest auf 230kBd gesteigert werden,
Nee, auch im originalen Design von den Wittigs ist doch die 2. UART, die
mit dem FX1 verbunden ist, in ihrer Baudrate konfigurierbar. Das einzige
was zu 230KBd fehlt, ist eine USB-UART-Firmware für den FX1.
Hayo W. schrieb:
> Hi,>> der Grund warum ich erstmal keine Sourcen beigelegt habe ist, dass ich> eine Abspaltung der Entwicklungslinie verhindern wollte. Wenn jemand die> Sourcen in die OS-Version mergen möchte lege ich die Sourcen aber gerne> bei.Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"
Hallo,
> Nee, auch im originalen Design von den Wittigs ist doch die 2. UART, die> mit dem FX1 verbunden ist, in ihrer Baudrate konfigurierbar. Das einzige> was zu 230KBd fehlt, ist eine USB-UART-Firmware für den FX1....
Ok... soweit logisch. Dachte allerdings das der FPGA die Daten dann auch
in der dementsprechenden Geschwindigkeit "weiter schieben" muss?! Oder
ist die Geschwindigkeit via FW anpassbar, also nicht via HW fix
vorgegeben?
Gruß, brunowe
Hallo brunowe,
>mein Vorschlag als einer der Ersten der das Projekt überhaupt zum Leben>gebracht hat...
Danke sehr dafür !
>melde dich bei SF an, und merge die Versionen!!!>Trotz SVN ist genau das die Arbeit, vor der sich derzeit jeder etwas>scheut...
Das ist wohl nicht der wirkliche Grund. Ich bin erstmal zufrieden, daß
ich mir die aktuellen Sourcen z.Zt.in einem Stück herunter laden kann u
hab jedenfalls keine Lust mich erst wieder durch seitenlange Help-Files
zu kämpfen und am Ende vom System unverständliche Fehlermeldungen zu
bekommen.
Gruß Jürgen
@ brunowe
Brunowe schrieb:
>Das USB Protokoll ist hier beschrieben:>http://sourceforge.net/apps/trac/welecw2000a/wiki/...
Diese Beschreibung ist doch wohl sehr unvollständig!
Was ist denn mit der original Protokollbeschreibung von Welec,
zusammengestellt von Jochen Schäuble?
http://schaeuble.info/de/category/jochen/w2000a
Das USB Protokoll funktioniert so noch in der OS 0.91. Allerdings ist
dieses Protokoll überhaupt nicht auf Geschwindigkeit optimiert.
Oder soll Deine GUI nur über RS232 laufen und das USB-Protokoll hat
darauf keinen Einfluß?
Beste Grüße,
Jürgen
Hi ...
Nach dem ich einige Tage Don Quichotte gespielt habe, nun einige
Kommentare zum Thema svn/sfn von mir:
Begriffsunterscheidung:
svn: Abkürzung für Subversion - System zur Versionsverwaltung
(Source-Code, Messdaten, Texte) - ich verwende dieses z.B.
für Messdaten ebenso wie für Texte (u.a. meine damalige DA)
als auch für Sourcen.
svn bietet hier die nette Möglichkeit, Änderungen zu
dokumentieren und ggf. wieder Rückgängig zu machen.
trac: System zur Verwaltung von Projekt-Daten - spielt wunderbar
mit svn, enthält u.a. ein Wiki ein Ticketsystem und bietet
die Möglichkeit, Änderungen im Source und Tickets zu
verlinken (damit mensch nachher sehen kann, wofür die
Änderung gemacht wurde (Bugfixes))
sfn: Plattform für Open-Source Projekte, u.a. mit verteilter
Distribution und Angebot, svn, und trac zu verwenden.
Wenn jemand nun auf die Seite:
http://sourceforge.net/apps/trac/welecw2000a/
geht, landet man im Trac-Wiki des SFN-Projektes und kann sich
z.B. die Sourcen (mit Änderungen) im svn oder offene/geschlossene
Tickets ansehen.
Oben auf der Seite steht:
"Visit project welecw2000a", ebenso wie "Welec W2000A". Beide
Links führen auf die Seite:
http://sourceforge.net/projects/welecw2000a/
Dort befindet sich eine Sektion "Files". In dieser Sektion
findet man die Releases - also die herausgegebenen Versionen.
Während im svn (derzeit) nur die Sourcen drin sind, sind hier
auch die compilierten Versionen (soweit verfügbar) drin, welche
sich dann einfach in das DSO hochladen lassen.
Die Sourcen einiger Releases (es sollten eigentlich alle sein ;)
findet man im svn unter:
http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/tags
Das Verzeichnis
http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/trunk
enthält den derzeitigen Entwicklungstand (der OS Version).
Über das Verzeichnis
http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/branches
können z.B. Abzweigungen im Source-Tree (tiefgreifende Änderungen,
Version 2.0, etc) verwaltet werden (um diese dann später wieder
in den trunk einzupflegen)
Wird auf Basis des svn(-Tree) gearbeitet, so lassen sich
Versionskonflikte zumeist sehr einfach lösen. Hier könnten wir aber das
Problem haben,
dass der Dateiaufbau der BF und der der OS sich unterscheiden. Falk
hatte damals die Änderungen von Hayo eingepflegt, das war aber eben mal
drei Stunden Arbeit (und händisches einpflegen ist eher fehleranfällig).
Die Arbeit mit svn scheint erstmal sehr viel Overhead zu haben,
hat sie aber nicht - ist der Client der Wahl (gerne auch cli) gefunden,
so ist die Lernkurve sehr steil (Nach dem Motto: einen Tag für den
Client der Wahl, 'nen viertel Tag für das svn) und die Vorzüge einer
Versionsverwaltung sind in einem Projekt (egal ob Text, Source oder
Messdaten) nicht zu unterschätzen (wer einmal Rohdaten weggeworfen hat
und sie nachher wieder brauchte wird dies bestätigen können).
Wenn ich mir die Tickets im Trac ansehe
(http://sourceforge.net/apps/trac/welecw2000a/report/1)
sieht man, dass sowohl in der BF als auch in der OS Fehler offen sind.
Wir können nun daraus zwei Baustellen machen. Oder gemeinsam an
einer
arbeiten.
Grüße,
rowue
PS: Zur Qualität der Änderungen: Ich arbeite hier gerade an einer
Abweichung von 1,8% ...
branadic schrieb:
>> PS: Zur Qualität der Änderungen: Ich arbeite hier gerade an einer>> Abweichung von 1,8% ...>> Dann möchte ich dich vielleicht auf den unteren Teil dieser Seite> aufmerksam machen:>> http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement
merci ;)
>> Gruß, branadic
Beste Grüße,
rowue
Hallo Leute!
Hat jemand von Euch mit dem Vinculum Board weitergearbeitet?
Der USB Stick hat leider sehr unterschiedliche Zugriffszeiten sodass
wahrscheinlich ein FIFO und ein Handshake in die Kommunikation mit dem
Oszi eingebaut werden muss.
Es wäre schön, wenn jemand der das bisherige Protokoll versteht es mal
im Klartext notieren könnte. Damit meine ich die den Teil der den
Screenshot einleitet, die Lauflängendekodierung und die Bilderstellung.
Dann könnte man das Protokoll in Richtung Handshake optimieren und auf
den Mikocntroller portieren.
Mfg,
Kurt
Hallo zusammen,
da viele scheinbar ja ein unglaubliches Problem mit der englischen
Sprache haben, gibt es jetzt im SourceForge phpBoard einen
deutschsprachigen Bereich.
Zu finden ist das Ganze hier:
http://sourceforge.net/apps/phpbb/welecw2000a/
Eine Anmeldung bei SourceForge ist natürlich notwendig, dafür sind die
wichtigen Diskussionen dann unmittelbar mit der Haupt-Projektseite
verbunden und nur wirklich Projektinvolvierte nehmen an der Diskussion
teil.
Das Forum bitte nicht mit sinnlosen Kommentaren füllen, die allgemeinen
Regeln einhalten und bei Fragen, einfach eine Mail an die Administration
senden, bspw. wenn ein neues Unterforum angelegt werden müsste/könnte.
Topics dürft ihr selbst starten. Bitte haltet die Struktur ein. Für
Anregungen ist euere Meinung aber gern gefragt.
Topics bitte hinreichend genau benennen, damit alles auch übersichtlich
bleibt. So ist im Firmware-Bereich die Struktur:
NIOS - Problemstellung
ZPU - Problemstellung
LEON3 - Problemstellung
denkbar, allerdings könnten hier auch extra Unterforen für die 3
Prozessoren angelegt werden.
Ich denke wir kommen damit den nicht englischsprachigen Leuten sehr weit
entgegen, nutzt die Plattform bitte auch.
Beste Grüße, branadic
Hi,
hat etwas gedauert mit der nächsten Version, aber zum Ende des Sommers
müssen halt erst die restlichen Arbeiten im Garten fertig werden, sonst
gibts Ärger von der Chefin.
Auch wenn sich oberflächlich außer der Fehlerkorrektur scheinbar nicht
so viel getan hat, sind die Änderungen unter der Haube recht
umfangreich.
Das DSO startet jetzt nach dem Ausschalten immer mit der letzten
(gespeicherten) Einstellung vor dem Ausschalten. Neu ist hierbei unter
Anderem die Unterstützung für den Math-Betrieb (auch FFT) und den
USTB-Betrieb.
Um etwas kompatibler zur OS-Version zu sein habe ich Falks aktuelle
Version der Remoteschnittstelle mit eingebaut. Ich habe es allerdings
nicht mehr geschafft die Screenshot-Version umzurüsten, daher bitte
wieder die beigelegte Version verwenden.
Da es letztens hier angefragt wurde lege ich die Sourcen diesmal bei.
Achtung - dies ist keine Entwicklerversion für das SFN! Nach
erfolgreichen Tests können die Änderungen je nach Zustimmung in die
SFN-Version übernommen werden. Ob ich das mache oder jemand anderes
können wir ja noch klären.
Gruß Hayo
Hallo zusammen,
ich habe ja lange nichts mehr von mir hören lassen. Aber ab nächster
Woche ist wieder mehr Zeit. Da werde ich sicher wieder die eine oder
andere Sache beisteuern können.
@Hayo
Leg dir doch im SFN einen branch an. Dann kannst du ungestört deine
Sourcen einpflegen, während du gleichzeitig alle Änderungen im trunk
mitbekommst.
Stefan E. schrieb:
> Hallo zusammen,>> ich habe ja lange nichts mehr von mir hören lassen. Aber ab nächster> Woche ist wieder mehr Zeit. Da werde ich sicher wieder die eine oder> andere Sache beisteuern können.
Super!
> Leg dir doch im SFN einen branch an. Dann kannst du ungestört deine> Sourcen einpflegen, während du gleichzeitig alle Änderungen im trunk> mitbekommst.
Da muß ich zu meiner Schande gestehen, dass ich noch keine Zeit gefunden
habe mich mit SVN und drumherum auseinanderzusetzen. Wenn ich
zwischendurch Zeit hatte hab ich nur an der FW rumgeschraubt. Muß ich
also noch ran. Dann werde ich Deinen Vorschlag mal aufgreifen.
Ansonsten noch an alle viel Spaß beim Testen,
Gruß Hayo
Hayo W. schrieb:
> Hi,> hat etwas gedauert mit der nächsten Version, aber zum Ende des Sommers> müssen halt erst die restlichen Arbeiten im Garten fertig werden, sonst> gibts Ärger von der Chefin.
Das wollen wir ja nicht! ;)
>> [1.2.BF.094.HE]
Ich habe die Version in's Ticket-System eingetragen,
dann können evtl. Fehler dort gleich eingetragen werden ;)
URL: http://sourceforge.net/apps/trac/welecw2000a/report>> Achtung - dies ist keine Entwicklerversion für das SFN! Nach> erfolgreichen Tests können die Änderungen je nach Zustimmung in die> SFN-Version übernommen werden. Ob ich das mache oder jemand anderes> können wir ja noch klären.
Vorschlag: lass uns beide das doch gemeinsam machen ;)
>> Gruß Hayo
Grüße,
rowue
Hayo W. schrieb:
> Ok,>> wie hattest Du Dir das vorgestellt?
Wir treffen uns Samstag (früher Nachmittag), erstellen
erstmal einen unified diff Deiner aktuellen Sourcen zum
Stand 0.88 (war glaube ich der, den Hayo zum einpatchen
vervendet hat) und patchen mit Hilfe dieses Diffs die
Sachen in das svn.
Treffen könne wir uns (von meiner Seite aus) bei Dir,
bei mir oder bei mir in der Firma. Zu Dir müsste ich
mit Bus/Bahn und (ggf.) Fahrrad.
Bei mir stände uns ein grosser Schreibtisch und eine seperate
Werkbank zur Verfügung. Da ich gerade zwei Geräte (W2014A,
W2022A) zur Verfügung habe, könnten wir die Patches auch
gleich auf beiden Geräte testen. Wenn Du das Tek mitbringst,
könnten wir uns ebenso die Ausgaben des HP auf den drei Geräten
ansehen.
Bei mir in der Firma hätten wir in der Werkstat viel Platz
und Internet bis zum Abwinken, müssten aber evtl. unsere
Geräte (falls wir was testen möchten) rantragen (ISP).
>> Gruß Hayo
Grüße,
rowue
Hi allerseits,
hier die aktualisierte 0.95HE - Bruno war aufgefallen dass die
Remoteschnittstelle nicht funktioniert, daher habe ich nochmal gesucht
und festgestellt, dass ich vergessen hatte die UART-ISR mit
nachzuziehen. Das sollte jetzt also funktionieren. Falls es noch
Probleme gibt immer raus damit.
@Rolf
Hört sich echt gut an, leider bin ich jetzt am WE komplett ausgebucht,
da ich Besuch aus dem Ruhrpott bekomme. Grundsätzlich können wir das
aber gerne machen. Welche der Örtlichkeiten wir dann wählen können wir
dann ja kurzfristig abstimmen.
Gruß Hayo
Hi Hayo,
konnte zwar gestern nur kurz testen, aber bei 1Gs/s-50ns/div und Noise
Filter on und im Single Shot wandert die die Anzeige im Stop
unweigerlich nach links aus dem Bildschirm hinaus. Passiert aber nur mit
eingeschaltetem Noise Filter. Bei Normal und Averaging nicht!
Gruß Jürgen
Hayo W. schrieb:
> Hi allerseits,>> [0.95HE]
Habe das Ticket-System angepasst (und die 0.94HE dort gelöscht)
Es wäre nett, wenn Fehlermeldungen (überwiegend) dort landen ;)
>> @Rolf>> [Besuch aus dem Pütt]
O.K. - wollen wir dann das nächste Wochenende (10./11.10.,
preferiert: Samstag, den 10.10) in's Auge fassen? ;)
>> Gruß Hayo
Grüße,
rowue
@Jürgen
Ok, habs mir mal angesehen. Scheint vorher noch niemendem aufgefallen zu
sein, denn das Problem müßte eigentlich auch bei den älteren Versionen
auftreten. Ich weiß auch schon so ungefähr woran es liegt.
Danke für den Hinweis
Hayo
Hayo W. schrieb:
> @Jürgen>> Ok, habs mir mal angesehen. Scheint vorher noch niemendem aufgefallen zu> sein, denn das Problem müßte eigentlich auch bei den älteren Versionen> auftreten.
Schau mal in's Ticket-System ;)
http://sourceforge.net/apps/trac/welecw2000a/report/1> Ich weiß auch schon so ungefähr woran es liegt.>> Danke für den Hinweis>> Hayo
Grüße,
rowue
Du meinst Ticket 39??
Das hatte ich nicht damit in Verbindung gebracht, da die Beschreibung
eher in eine andere Richtung wies. Werde ich dann resolven wenn die
Korrektur raus ist.
Hayo
So,
da nach über 50 Downloads jetzt keine weiteren Rückmeldungen vorliegen
scheint es zumindest keine gravierenden Schnitzer zu geben. Die
Remoteschnittstelle scheint daher wohl auch zu funktionieren.
Daher hier nochmals eine fehlerkorrigierte HE. Das wegdriftende Signal
im Stopmodus bei eingeschaltetem Noise-Filter ist gefixed. Bei der
Gelegenheit habe ich die Run/Stop/Single-Logik komplett überarbeitet, so
dass diese jetzt vernünftig funktioniert. Nebenbei habe ich noch weiter
das Coding aufgeräumt und tote Variablen und Coding gelöscht. Beim
ersten Start könnte es leichte Nebeneffekte geben, da sich das
Flashlayout mal wieder etwas geändert hat.
Ein einfaches Default-Setup sollte das aber beheben.
Gruß Hayo
Hayo W. schrieb:
> Du meinst Ticket 39??>
Jupp ;)
> Das hatte ich nicht damit in Verbindung gebracht, da die Beschreibung> eher in eine andere Richtung wies. Werde ich dann resolven wenn die> Korrektur raus ist.
Die Beschreibung war nicht allzu gut - sorry ...
ich hatte das Phänomen, dass am linken Rand (des Signals)
dieses bei Betätigen der Stop-Taste an den oberen Bildschirm-Rand
zog.
>> Hayo
Grüße,
rowue
PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt
Zum Singlemodus ist noch anzumerken, dass der Triggermode zwangsweise in
den Normalmodus geschaltet wird, damit auch wirklich nur dann ein neues
Ereignis ausgelöst wird wenn die Triggerschwelle überschritten wird.
Sollte da aber nichts kommen (zu hoher Triggerlevel oder so) wartet das
DSO natürlich bis zum Sankt Nimmerleinstag.
Der Singlemodus steht jetzt nur noch dann zur Verfügung wenn der
Single-Druckknopf grün hinterleuchtet ist - dazu muß man die
Run/Stop-Taste drücken. Im aktivierten Zustand ist der Druckknopf orange
hinterleuchtet. Nach erfolgtem Triggerereignis ist er wieder grün und
signalisiert damit Bereitschaft. Das Ganze wird durch erneutes Drücken
der Run/Stop-Taste beendet.
Gruß Hayo
Hayo W. schrieb:
> Rolf Würdemann schrieb:>> PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt>> Sind aber noch genug für alle da... ;-)
Wink verstanden ;)
Ich hoffe mal, dass ich Fr/Sa mit der Geschichte an der
ich gerade bin durch bin, dann kann ich mir das eine oder
andere "greifen" ;)
>> Gruß Hayo
Grüße,
rowue
Hallo,
ist es Absicht, dass wenn ich Quickmeasure aus und dann wieder
einschalte die Kanalwahl der einzelnen Messfunktionen überschrieben
wird? Denke ja hoffentlich mal nicht. Hab das mal rausgenommen. Jetzt
bleibt die Kanalwahl der einzelnen Messfunktionen beim Aus- und
Einschalten von Quickmeasurement erhalten.
Ich werde die Änderungen in den aktuellen trunk der OSS ablegen. Ich
hoffe odch, dass irgendwann hier auch mal deine Änderungen erscheinen.
Es ist schon ein Aufwand in zwei Verisonen immer nachzuschauen, ob
jemand anderes das Problem vielleicht schon gefixt hat.
@Hayo
Ich habe mich mal daran veruscht, die HE0.96 und die OSS.91
zusammenzuführen, damit wir wieder an einem Strang ziehen. Hat auch fast
alles geklappt. Kannst du mal schauen, ob noch alles drinnen ist, was du
die letzte Zeit gemacht hast. Außerdem habe ich bei der RS232-Verbindung
irgendwas vermischt. Jedenfalls geht die Screenshot-Funktion derzeit
nicht. In tc_vars.cpp Zeile 2570 & 2450 habe ich den Überblick verloren,
was den nun eigentlich ins Menü für den Screenshot rein muss. Bin da
gerade nicht so auf dem laufenden. Vielleicht kannst du die
Screenshot-Funktion wieder richten. Blicke da gerade nicht durch ;-)
Hallo Stefan, hallo Hayo,
schön das du am mergen bist Stefan! Ich hoffe du nimmst die Remote
Control Funktionen aus der OS.91 da die in der HE 0.96 definitiv noch
einige Probleme haben! Wollte ein Ticket aufmachen, da aber die 0.96
nicht im Ticketsystem ist, hab ich's erst mal gelassen (ob der Fehler
auch in der 0.95 auftaucht, hab ich nicht getestet).
Ich Hatte auch keine Lust das Ganze ausführlich zu testen, da mich das
bei meiner GUI Programmierung nur behindert.
Der "Dump data STX ASCII 03" liefert definitiv falsche Daten,
Die continious dump Befehle zeigen gar keine Wirkung...
Hier hab ich mal einen Screenshot der neuen GUI veröffentlicht, damit
man auch sieht wo das Ganze hinführen wird...
http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=18&t=34
Gruß, brunowe
Hallo brunowe,
ich hab nochmal ein paar Änderungen gemacht. Kannst du die nochmal mit
deiner GUI testen?
Die Screenshoot-Funktionen sind jetzt wieder aus der OSS und die
Remote-Steuerung habe ich veruscht komplett zu übernehmen. Wenn du und
grünes Licht gibst, dass dein Zeug noch funktioniert übernehme ich es
heute Abend in SF.
Stefan E. schrieb:
> Hallo brunowe,>> ich hab nochmal ein paar Änderungen gemacht. Kannst du die nochmal mit> deiner GUI testen?>> Die Screenshoot-Funktionen sind jetzt wieder aus der OSS und die> Remote-Steuerung habe ich veruscht komplett zu übernehmen. Wenn du und> grünes Licht gibst, dass dein Zeug noch funktioniert übernehme ich es> heute Abend in SF.
Committe meinetwegen einfach, wenn es Probleme mit der PC-Kommunikation
gibt, kümmere ich mich darum.
Falk
http://sourceforge.net/apps/phpbb/welecw2000a/
Hi,
besten Dank schonmal an Stefan für das Mergen der Versionen, ich weiß
nicht wann Rolf und ich sonst dazu gekommen wären.
Zur Remote-Schnittstelle: Da mir die Testmöglichkeiten fehlen habe ich
die OS-Sourcen nach offensichtlichen Änderungen durchsucht und diese
dann bei mir eingebaut. Kann gut sein, dass noch eine Kleinigkeit fehlt,
die mir nicht aufgefallen ist, hier sollte aber die OS-Version die
Vorgabe liefern.
Zum Screenshot: Ich hatte das Druckmenü bei mir so geändert, dass die
einzelnen Funktionen vom DSO aus anwählbar sind und daher die
Screenshotfunktionen mit einem Parameter versehen.
Um mit der aktuellen PC-Software kompatibel zu sein, müssen die
Screenshotfunktionen der OS-Version verwendet werden - auch die RLE
Encoderfunction!
Um das Ganze zu mergen gibt es zwei Varianten:
Entweder muß die Menüstruktur der OS-Version verwendet werden, dann
werden keine Parameter gebraucht, oder die Screenshotfunktionen und die
PC-Software werden um diese Parameter erweitert, dann kann meine
Menüstruktur verwendet werden (Definition in tc_vars 2450/2570/2607).
Die flash_t kann vermutlich komplett von mir übernommen werden, da dort
wahrscheinlich keiner etwas geändert hat.
In hardware_t gibt es die neuen Funktionen Reset_To_Default() und
Restore_From_Flash() die bei der neuen Startupsequenz genauso zum
Einsatz kommen wie bei der Recall-Funktion und der
Autoscale-Undo-Funktion.
-> handle_ADC() hat sich unter Anderem geändert!
In userif_t hat sich ebenfalls einiges getan, unter anderem die neue
Run/Stop/Single-Logik im Button handler.
commif_t kann größtenteils von der OS-Version übernommen werden, hier
habe ich nur im USB-Transfer einige tote Variablen entfernt (CH1_DAC_1
usw.)
In display_t haben sich die Draw-Routinen etwas geändert.
In signal_t hat sich die Noise Suppression etwas geändert (if-Bedingung
- siehe Ticket 39)
Ich werde aber noch mal über Deine gemergten Files drüberschauen und mal
sehen ob mir da was auffällt.
Gruß Hayo
Wollte eben mal Deine gemergten Sachen besichtigen, kann aber in den
ZIPs nichts finden. Hast Du eine exotische ZIP-Version, oder ist da
einfach was schiefgelaufen?
Gruß Hayo
Hayo W. schrieb:
> Wollte eben mal Deine gemergten Sachen besichtigen, kann aber in den> ZIPs nichts finden. Hast Du eine exotische ZIP-Version, oder ist da> einfach was schiefgelaufen?
Da sind nur ziemlich lange relative Pfade drin.
Ich habs mal für Winzip vorverdaut ;-)
Falk
@Falk
Danke.
@Stefan
Ich habe mal userif_t.cpp geprüft - es gibt noch 5 Stellen die geändert
werden müssen und je nach wunsch evtl. die Quick Print Menüfunktionen.
Ich prüfe noch die anderen und stelle die überarbeiteten Files dann hier
ein.
Gruß
Hayo
Hayo W. schrieb:
>> Bei der> Gelegenheit habe ich die Run/Stop/Single-Logik komplett überarbeitet, so> dass diese jetzt vernünftig funktioniert.
Mir gefiel das vorher besser!
Mit der 0.96HE ist es nicht mehr möglich das Signal im stop mode zu
analisieren (strecken, verschieben usw.) überdies wenn ich in den delay
modus wechsle sind die Signale weg!
grüss Martin
@Martin
Ich habe im Stop-Modus das Drehgeberinterface blockiert, da sich die
Nullpunktlage verschieben ließ, ohne dass das Signal folgte. Wenn das
vom Handling gefälliger ist mit der Möglichkeit was zu verstellen, kann
ich das auch wieder rausnehmen oder etwas feiner einschränken.
Gruß Hayo
Hayo W. schrieb:
> Martin H. schrieb:>>> wenn ich in den delaymodus wechsle sind die Signale weg!>> Das war mir noch nicht aufgefallen, ist in Arbeit...
Können wir vielleicht endlich mal versuchen, eine Version zu
pflegen?
Wer einen Bug findet, meldet den hier:
http://sourceforge.net/apps/trac/welecw2000a/report
Der wird dann gefixt, der Bugreport wird bearbeitet, die Änderungen
werden committed und ggfs. wird eine Release daraus gemacht, das man
dann unter http://sourceforge.net/projects/welecw2000a/ herunterladen
kann.
Sonst wird das Durcheinander noch größer.
Falk
@Falk
Wenn ich noch was ändere, baue ich das in die gemergte Version mit ein,
evtl. ändere ich aber auch erst nach dem Mergen direkt in der OS
Version.
Keine Sorge, ich mach jetzt deswegen keine neue Version auf.
Gruß Hayo
@Stefan
Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an
der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer
dabei.
@all
Sind diese Änderungen konsolidiert, oder ist das noch im experimentellen
Status?
Gruß Hayo
Hayo W. schrieb:
> @Stefan>> Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an> der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer> dabei.>> @all>> Sind diese Änderungen konsolidiert, oder ist das noch im experimentellen> Status?
Ich habe eben Stefans Files commited (revision 245).
Falk
Bruno We schrieb:
> Hallo Stefan, hallo Hayo,>> [....] Wollte ein Ticket aufmachen, da aber die 0.96> nicht im Ticketsystem ist, hab ich's erst mal gelassen (ob der Fehler> auch in der 0.95 auftaucht, hab ich nicht getestet).[...]
Habe die 0.96HE im Ticket-System nachgetragen
>> Gruß, brunowe
Grüße,
rowue
>@Stefan>Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an>der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer>dabei.
Das war ich. Hab mich wohl nicht eingetragen. Vorher wurden beim Ein-und
Ausschalten von QM die ausgewählten Kanäle der Messfunktionen geändert.
Das hab ich abgestellt.
>Können wir vielleicht endlich mal versuchen, eine Version zu>pflegen?>Wer einen Bug findet, meldet den hier:>http://sourceforge.net/apps/trac/welecw2000a/report>Der wird dann gefixt, der Bugreport wird bearbeitet, die Änderungen>werden committed und ggfs. wird eine Release daraus gemacht, das man>dann unter http://sourceforge.net/projects/welecw2000a/ herunterladen>kann.>Sonst wird das Durcheinander noch größer
Ganz meiner Meinung. Deshalb ja jetzt der "Gewaltschritt". Darauf kann
ich jetzt aufbauen. Habe am Schluss nicht mehr gewusst, was schon in
welcher Version behoben war.
@Hayo
Wenn du noch die letzten Änderungen schickst, aktualisiere ich das in
SF, bis du dich damit mal selber befasst. Lieber viele kleine Schritte,
als so ein großer. Danach würde ich die 0.92_OSS rausbringen, auf der
wir alle weiterentwickeln.
>Da sind nur ziemlich lange relative Pfade drin.>Ich habs mal für Winzip vorverdaut ;-)
Hab das unter OpenSuse gezippt. Das da dann überhaupt die Pfade mit
drinnen sind ist mir neu.
Das WinZip ein Mist ist dachte ich mir ja schon immer ... ;-)
@ Hayo
Danke für die Erklärung zum QuickMeasure mit mehreren Kanälen. Ich hatte
bis dahin nicht verstanden, dass das überhaupt möglich ist...
Wenn ich mal auf Energiereserven in mir stoße, fange ich vielleicht mit
einem kleinen Handbuch zur Firmware an, sicher haben andere auch
Probleme, alle Möglichkeiten zu entdecken.
Achja: bei mir funktioniert der delayed modus mit der 0.96 tadellos.
Ich fände es auch gut, wenn man im Stop Mode die Möglichkeit zum
Scrollen oder Zoomen (wo möglich) wieder bekommen könnte.
Gruß
Michael
Falk Willberg schrieb:
> Ich habe eben Stefans Files commited (revision 245).
Allein in der userif_t.cpp waren noch 5 fehlerhafte Stellen, die anderen
sind noch nicht geprüft.
Ist das so gewollt?
Gruß Hayo
Stefan E. schrieb:
> Ganz meiner Meinung. Deshalb ja jetzt der "Gewaltschritt". Darauf kann> ich jetzt aufbauen. Habe am Schluss nicht mehr gewusst, was schon in> welcher Version behoben war.
Damit testen kann, wer testen will, hier noch eine TomCat.ram aus den
SVN-Sourcen: http://falk-willberg.de/tmp/TomCat.ram.gz
Falk
Hallo werte W20xxA Besitzer und Interessierte!
Da der Thread hier schon sehr sehr sehr lange geworden ist, habe ich mal
einen zweiten Teil davon aufgemacht!
Bitte hier weiterschreiben:
Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
Danke !
l.G. Roberto
>Danke für die Erklärung zum QuickMeasure mit mehreren Kanälen. Ich hatte>bis dahin nicht verstanden, dass das überhaupt möglich ist..
Wir haben uns doch nicht irgendeinen billigen Oskar gekauft, bei dem QM
nur auf einem Kanal gleichzeitig möglich ist. ;-)
Ich denke, dass du dich auf #33 beziehst. Da hab ich versucht das zu
erklären. ;-)
Roberto schrieb:
> Hallo werte W20xxA Besitzer und Interessierte!>> Da der Thread hier schon sehr sehr sehr lange geworden ist, habe ich mal> einen zweiten Teil davon aufgemacht!> Bitte hier weiterschreiben:> Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
Ohne mich!
Falk
Oh, da habe ich doch glatt dem falschen die Lorbeeren zugeschustert, so
war das nicht gedacht.
Stimmt, du warst ja der QM-Fachmann! Dann also danke nochmal an dich für
die Erklärung und die gute Arbeit an den Messfunktionen.
Ein gutes Beispiel für die Nützlichkeit habe ich hier gerade laufen: ein
I2C Farbsensor, dessen Werte ich mit nem Controller als dreikanalige PWM
ausgebe (RGB). Da kann man sehr schön sehen und messen, was für
Farbanteile man da gerade hat. Jaja, die Welec-Kiste hat zwar noch ihre
Macken, aber irgendwie ist sie mir doch schon ans Herz gewachsen :)
Wie aufwändig ist es denn, die Messerei für die schnellen timebases zu
fixen?
Deinen Vorstoß zur Zusammenführung der Versionen finde ich auch klasse,
es bahnte sich ja schon der eine oder andere Streit an deswegen.
Gruß
Michael
Hayo W. schrieb:
> Falk Willberg schrieb:>>> Ich habe eben Stefans Files commited (revision 245).>> Allein in der userif_t.cpp waren noch 5 fehlerhafte Stellen, die anderen> sind noch nicht geprüft.
Dann pflege die Fixes doch ein.
> Ist das so gewollt?Ich wollte endlich wieder eine Basis haben, auf der ich sinnvoll
weitermachen kann. Es gibt da ein paar Erweiterungen, auf die jemand
wartet.
Falk
hi, wollte mal fragen, was schief läuft, wenn das screenshotprogramm nur
ganz kurz auf geht und dann gleich wieder weg ist?
ich hatte es schonmal, da liefs tip top... jetzt hab ich nen anderen
laptop und da gehts nur kurz auf und ist nach ner halben sekunde wieder
weg...
danke schonmal
ok, hat sich schon erledigt!
hab den falschen com-port gehabt.
(konnte nur die fehlermeldung nicht lesen, weils so schnell wieder weg
war...sogar zu schnell für nen screenshot. bin dann einfach mal auf der
entertaste geblieben, dass es so oft auf und zu ging dass ichs lesen
konnte)
Manuel schrieb:
> hi, wollte mal fragen, was schief läuft, wenn das screenshotprogramm nur> ganz kurz auf geht und dann gleich wieder weg ist?>> ich hatte es schonmal, da liefs tip top... jetzt hab ich nen anderen> laptop und da gehts nur kurz auf und ist nach ner halben sekunde wieder> weg...
Das screenshot-Programm ist ein Kommandozeilen-Tool. Im Terminal (oder
wie heißt das unter Win?) siehst Du auch die Fehlermeldung.
Wahrscheinlich ist das Problem, daß am Laptop keine COM1 vorhanden ist,
auf die das Tool ohne Parameter zugreift.
Alternativ installiere Linux, damit gehen auch andere Sachen besser.
Vielleicht könnte sich mal ein Windows-User des Screenshot-Tools
annehmen? Da sollte sich doch bei >95% Marktanteil jemand finden...
Falk
P.S.: Solche Fragen sind bei
http://sourceforge.net/apps/phpbb/welecw2000a/ besser aufgehoben.
...also was dann jetz? Mir geht das jetzt auf'n S..., wann sind wir uns
denn hier einich???
Ich versuche so gut wie möglich hier den Überblick zu behalten was aber
bald unmöglich sein wird, da der Thread hier wirklich schon 100km lang
ist!
Ich fände es jetzt nicht schlecht, wenn es, wie FALK es schon
vorgeschlagen hat, im SF weiter ginge, da ja schon 3 Thread's
(ENTWICKLER, HARDWARE, SOFTWARE) aufgemacht worden sind!!!
Ich selbst bin dort als KASTOR7 registriert(mike0815 war schon
vergeben)!
Bei Fragen oder Beiträgen von hier, kann ja verlinkt werden...
...das wäre jetzt mein Vorschlag, was hält denn der Rest davon???
Gruß Michael
Hallo Michael,
allein schon weil wir auf SF (innerhalb unseres Projekts) Admin Rechte
haben, bin ich stark dafür!
P.S.:
Ich hab mal hier:
http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=18&t=34
ein aktuelles Foto von der GUI eingestellt. Derzeit bin ich dabei einige
Programme der Profis zu analysieren, um mal zu sehen wie die das ein
oder andere Problem in der Programmierung und Darstellung gelöst haben.
Da ich derzeit schon ca. 3000 Zeilen Programmcode geschrieben habe
wird's langsam Zeit für eine ordentliche Programmstruktur...
Gruß, brunowe
Hallo zu allen!
entschuldigt sich für meinen bösesten Deutschen, aber ich habe ein
Problem mit dem W2012A und ich brauche eure Hilfe..
Ich versuchte die Fortbildung der Firmware mit der Software von Welec zu
machen (W2000-Update)und während es für Fehler entlud, schloß ich das
Fenster. es scheint jetzt, daß ich keine firware mehr installiert habe
und wenn ich wieder das Programm den upload losgehen lasse, fängt es
nicht an..
wie ich kann wiedergutmachen?
Sorry, konnte mich nicht zurückhalten - die Online-Übersetzter sind
manchmal so lustig ;-))))
"entschuldigt sich für meinen bösesten Deutschen"
Oooooohhohhohho, ROFL-ROFL :-D
Hallo an alle! Ich kaufte den Umfang von welec und ausgeliefert haben,
den Artikel regelmäßig bezahlt denn es ist eine Schande, nicht um E-Mail
zu reagieren.
Ich dachte, dass die Deutschen richtigen Leute waren. Enttäuschung
total!
Ich möchte eine Antwort von Ingenieur.
Hello everyone! I purchased the scope from welec and have shipped the
item regularly paid for it is a shame not respond to email.
I thought that the Germans were right people. Disappointment total!
Ciao a tutti ! Ho acquistato l'oscilloscopio dalla welec e non hanno
spedito l'oggetto regolarmente pagato è una vergogna non risponde ad
email .
Credevo che i tedeschi erano persone corrette .Delusione totale!
Hallo,
ich hatte bereits 2010 ein W2014A von Michael Wittig über ebay
ersteigert. Hardwareversion 1c9.0d, Softwareversion 1.4. wegen der
bekannten probleme satnd es bei mir jahrelang nahezu ungenutzt herum.
Nun bin ich endlich dazu gekommendie neueste BlueFlash firmware
1.2.BF.7.13C2 zu flashen und auch den External Trigger Mod und den
LB-Mod vorzunehmen. Das Gerät ist jetzt wirklich brauchbar! Vielen Dank
an alle Beteiligten für die große Mühe!
Leider zeigen sich zuweilen immer noch die lästigen Spikes. Im Forum
habe ich gelesen, dass unter Umständen ein Umflashen des FPGA auf
Version 8C7.0L Besserung versprechen könnte. Leider finde ich nirgendwo
das benötigte sof File für diese Version. Könnte mir jemand einen Link
benennen?
Vielen Dank!
Dietmar