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
@Stefan Komme vor morgen nicht zum Testen - sorry Hayo
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
Im Anhang ein BackUp vom FPGA eines W2024A mit Hardware 8C7.C9 und Firmware 1.4. Die Checksumme ist 0706BCDF.
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
Danke Kurt, werde ich am Montag mal mit rumspielen. Die Checksumme wird dann auch nachgeliefert.
Hallo Wie wird die Checksumme ermittelt? Wie kann man die Daten in die Liste eintragen ? l.G. Roberto
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
Hallo Michael, bitte poste nochmal deine genau Vorgehensweise. http://apps.sourceforge.net/trac/welecw2000a/wiki/USBBlaster Ich nehme an, diese Seite kennst du. Nach welchem Schritt tritt das erste Problem auf?
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? Die wird nirgends verwendet, und ich habe sie jetzt auch komplett rausgelöscht. Hayo
>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
@Crazor Schon den WELEC-Updater von Marcus als Not-Fallback probiert? 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 Hayo, in ramloader.bat und flashloader.bat fehlt das -w
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
So, hier meine Daten: W2024A - HarwareRev 1C9.0L - 1.2BF0.68 - ausgeliefert mit SoftwareRev 1.4 Bis auf Kanal 3 alle OK
@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
Achso Odic X., ganz vergessen: Möge die Macht mit dir sein. ;-)) 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
Hm, irgenwie wollte er die Datei nicht... also hier nochmal Hayo
Gibts doch nicht, ich nehme mal einen anderen Browser, scheint am Sicherheitszertifikat zu liegen. 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
Die Zusage dass ich das Gerät behalten kann habe ich erst vorgestern bekommen.
@Kurt: Die Zusage kann ich geben ;) Hat jemand Interesse an meinem 2012A?
@ 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
sigxcpu-Alex hat bei google groups ne frage: http://groups.google.com/group/welec-dso/browse_thread/thread/75f2cc08a26cd737#
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
@Crazor, kann ich das schon als konkretes Interesse deuten? Wenn ja, schicke mir bitte eine PN damit wir die Details klären können. Mfg, Kurt
Angehängte Dateien:
-
2nS.jpg
190 KB
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, Timebase = 0 ist also auch vergeben? ;-) Wie sieht das mit 1 V/div aus? Gespanntes Abwarten, Guido
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
Angehängte Dateien:
-
200mV_64Mhz.jpg
160 KB
Hier mal das bekannte 64 MHz Signal von gestern - alle Einstellungen gleich. Ich finde es ist schon ein deutlicher Unterschied. So und im nächsten...
Angehängte Dateien:
-
100mV_64Mhz.jpg
180 KB
...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
Das 2024 ist schon verkauft. Da war der Preis wohl doch zu niedrig. ;-)
>Da war der Preis wohl doch zu niedrig. ;-)
Sehr ärgerlich. :-))
Hast du etwa eine Geschäftsidee entwickelt?
Gruß, Guido
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
Ach ja, einen hab ich noch, für den Testsignalgenerator habe ich unterstützung für Signalkopplung (AC/DC/GND) eingebaut. 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
Ok Fehler schon gefunden, war nur ein falsch gesetztes Semikolon. Daher jetzt schon das Update Hayo
Hallo Hayo, kurze Frage, welchen Nutzen haben die Testsignale eigentlich? Sind ja keine Signale, die am ADC anliegen. Daher die Frage. Gruß, branadic
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
Bei mir hängt Ch2 immer ca 9ns hinten dran. Bei Vertauschen der Probes kommts das gleiche raus. Gruß, Stefan
Hallo zusammen, Ch1 ist ca. 10ns voraus, Ch2-Ch4 sind etwa gleichauf. Gruß Jürgen
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
@hayo Vermutlich hat Stefan recht, leider hängt die 0.17er Version bei mir (W2012A) aber bei der 0.48 ist der Versatz schon drin. Martin
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
Hat denn schon jemand bei Welec nachgefragt? Soll ich das übernehmen?
Hallo, Das war wie ein Déjà-vu, ich hab heute 5 mal versucht einen von WELEC zu erreichen, ohne Erfolg.... Ich bleib weiter dran. Gruß, brunowe
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.