Hallo zusammen,
den Thread verfolge ich jetzt schon eine Weile und muss erstmal meinen
Dank rüberbringen an alle Beteiligten. Ich habe ein W2022A und die
FW1.2.BF.0.68_beta drauf. Beim Testen ist mir aufgefallen, dass die
Timebase 500ms/div als 1us/div angezeigt wird.
Danke und macht weiter so!
Peter
Oha jetzt ist hier ja ordentlich was los. Bin zur Zeit bei der 0.69
zugange, dehalb hab ich erst jetzt mal reingeschaut. Durch die kurzen
Uploadzeiten kommt man ja zu nichts anderem mehr...
@Guido
Das sieht doch schon ganz geschmeidig aus. Der Stil ist erstmal nicht
wichtig, Hauptsache es funktioniert, ist übersichtlich und dokumentiert
(und natürlich schnell genug).
@Andre
Die Kanalsteuerung hab ich nicht geändert, da mir das so auch sinnvoll
erschien. Das sollte also bei der originalen FW genauso sein.
Das mit der Pulsweitentriggerung ist bei mir noch nicht aufgetreten.
Vielleicht mal das default Setup aufrufen und sonst mal bei Zeiten einen
Configdump einspielen. Der Configbereich wird in der Tat anders beackert
als im Original und hat sich auch zwischen den Versionen etwas geändert.
Die Sache mit der Triggersource muß ich mal checken.
@Stefan
Sehr interessant. Bin gespannt was Du rausfindest. Beachte aber dass Du
da im interpolierten Bereich arbeitest. Nicht das sich da ein Fehler in
meiner Interpol. Routine eingeschlichen hat. Also am besten immer mit
dem 50nS Bereich nochmal eine Sicherheitsüberprüfung machen
@Roberto
Doch gerade bei der 0.68 sollte es sogar besser funktionieren. Heute
kommt noch die 0.69 mit erweitertem Rollmode. Ach hier gilt erstmal
default Setup dann weitersehen evtl. mal einen Dump einspielen (geht ja
jetzt schnell).
Hallo,
hab jetzt auch den Kanal 2 wie den Kanal 1 hinbekommen, dass die Flanke
schön aussieht.
Könnt ihr mal bitte testen, ob bei euch das Signal auf Kanal 2, mit dem
internen Rechteckgenerator, wie das oben gepostete verbesserte Signal
von Kanal 1 aussieht. Es ist derzeit NUR Kanal 2 verbessert. Kanal 1
dadurch vorrübergehend verschlimmert worden.
Außerdem ist bei 10ns/div die Interpolation deaktiviert. Also nicht
wundern, wenn es eine leichte Klötzchenbildung gibt.
Vielleicht kann Bruno damit mal seinen Sinus messen.
Danke,
Stefan
So hier schnell die 0.69 Beta mit erweitertem Rollmode.
Da die Signalausgabe als Zeitkonstante so stark eingeht, mußte ich für
die Refreshrate auch noch eine Fallunterscheidung für die aktiven Kanäle
einbauen. D.h. je weniger Kanäle gleichzeitig aktiv sind, desto höher
die Refreshrate. Die Refreshrate ist noch nicht ganz ausgeknautscht,
hatte ich keine Zeit mehr zu. Ebenso bei Timebase 500mS/Div und 3 + 4
Kanalbetrieb, wo die Zeitbasis nicht ganz korrekt ist.
@Stefan
Hab leider heute keine Zeit mehr zu testen,
Gruß Hayo
Es ist mir ein absolutes Raetsel, was mein Geraet da macht.
Ich habe gerade eine Stunde(!) versucht, das Bild zu erzeugen, das
Stefan da gezeigt hat. Der Trigger wollte auf allen Kanaelen einfach gar
nichts tun. Bis ich irgendwann wild auf Run und Single herumgedrueckt
hab: ploetzlich funktionierte es.
Nach genuegend langem Herum drehen an allen an Zeitaufloesung und
Triggerzeitpunkt habe ich es nun auch erreicht, dass der
Triggerzeitpunkt sich von der linken Div bis nach links ausserhalb des
Schirms schieben laesst. Weiter nacht rechts komme ich allerdings nicht
:D. Ist das ein verstecktes Feature, das ich nicht kenne oder hakts da
echt? :D
@Hayo
Stimmt. Es war auch frueher nicht machbar, dass ALLE Kanaele
ausgeblendet werden. Habs mit der OriginalSW getestet. Halte ich
persoenlich fuer ein fragwuerdiges Verhalten.
Gruessle
André
Hallo André,
>Ist das ein verstecktes Feature, das ich nicht kenne oder hakts da>echt? :D
Jepp, ist ein Feature, nennt sich PreTrig im Triggermenu. Wenn du
das hochdrehst, kannst du die Vergangenheit anscheuen.
Gruß, Guido
Hallo Stefan,
die Verbesserungen mit deiner FW-Version konnte ich bei mir jetzt nicht
nachvollziehen, sieht immer noch genauso wüst aus wie auf deinem ersten
Photo.
Gruß, branadic
Die Funktion Pretrig ist mir natuerlich nicht unbekannt :). In diesem
speziellen Fall hat sie jedoch nichts bewirkt. Irgendwie "hing" einfach
alles, ich bekomms aber leider auch nicht reproduziert.
Viele Gruesse
André
Hallo brandiac,
das habe ich befürchtet ;-) Wobei es bei mir wirklich super
funktioniert. Vielleicht kannst du mal ein Foto machen, wie es bei dir
genau aussieht? Also mit der Testfirmware und evtl. mit Hayos. Wäre echt
super.
Stefan
Hallo Stefan,
ich hab jetzt noch mal Hayo's 0.69er aufgespielt, da sehen die Flanken
so aus, wie auf deinem zweiten Photo.
Das mit der Pretriggerfunktion habe ich bisher immer als lästiges
Hindernis gesehen, denn als Vorteil. Gerade wenn man eine Flanke schön
auf Bildschirmmitte haben möchte ist das ein Krampf.
Beste Grüße, branadic
Hallo branadic,
hab bei mir auch mal die 69er getestet und bei mir schaut es wie immer
verschoben aus. Irgendwie kommen bei mir bei Kanal 1 die Daten von ADC4
um eine Periode zu früh und auf Kanal 2 die von ADC2 um zwei Perioden zu
früh.
Jetzt würde mich interessieren, bei wem das Problem überhaupt auftritt.
Egal auf welchem Kanal. Nicht das ich der einzige bin ;-)
Gruß,
Stefan
So, jetzt habe ich auch zum ersten Mal Eure Firmware (0.69) getestet. ->
SUPERARBEIT!
Genial auch der Ram-Loader. Von einem Linux-Netbook über USB-Serial hat
es etwa 210 Sekunden gedauert.
@Stefan:
Du bist nicht der einzige. Sieht bei mir ähnlich aus. Kanal 1 hat diese
Verschiebungen, Kanal 2 ist in Ordnung (W2022A).
Keep on the good work!!!
Michael
Hallo
Habe jetzt auch 0.69 getestet.
Roll-mode geht jetzt wieder (ab500ms). Leider ist die Anzeige nicht
kontinuierlich sondern es werden immer so ca. 2 Kästchen nacheinander
gezeigt.
Bei der 0.66 zeigte er die Linie kontinuierlich an. (ab 5s)
(Geladen mit dem .flash - FW)
l.G. Roberto
Hallo,
nur mal so eine Idee: Kann die unterschiedliche Darstellung bei der
Flanke vielleicht mit den verschiedenen "Hardware-Versionen", die ja
bereits im FPGA-Design vermutet worden sind, zusammenhängen? Das in den
unterschiedlichen Hardware-Versionen die Reihenfolge, in der die ADCs
ausgelesen werden, vertauscht worden ist?
Vielleicht sollten wir, zur FW-Version mit der dieser Effekt auftritt,
dazu schreiben welche Hardware-Version zugrunde liegt, dann ließe sich
vielleicht leichter eine Schlussfolgerung ziehen.
Ich kann es nur leider gerade nicht, da ich auf Arbeit bin.
Gruß, branadic
@Roberto
Ja das ist korrekt, wie ich schon angedeutet habe geht die
Graphikroutine als Zeitkonstante sehr stark in das Gesamttiming mit ein.
Daher war ich gezwungen die Graphikausgabe je nach Zeitbasis und Anzahl
der aktiven Kanäle solange auszusetzen zwischen den einzelnen
Meßwerterfassungen, dass in den etwas schnelleren Zeitbasen bis zu 400
Punkte ohne Ausgabe erfaßt werden. Dieses Refreshtiming ist noch nicht
ganz ausgereizt sondern erstmal konservativ ausgelegt um ein stabiles
Timing zu garantieren. Zur nächsten Version werde ich das in Richtung
kontinuierliche Ausgabe optimieren.
Gruß Hayo
branadic schrieb:
> nur mal so eine Idee: Kann die unterschiedliche Darstellung bei der> Flanke vielleicht mit den verschiedenen "Hardware-Versionen", die ja> bereits im FPGA-Design vermutet worden sind, zusammenhängen? Das in den> unterschiedlichen Hardware-Versionen die Reihenfolge, in der die ADCs> ausgelesen werden, vertauscht worden ist?
Das ist in der Tat nicht auszuschließen und sollte auf jeden Fall näher
untersucht werden.
> Vielleicht sollten wir, zur FW-Version mit der dieser Effekt auftritt,> dazu schreiben welche Hardware-Version zugrunde liegt, dann ließe sich> vielleicht leichter eine Schlussfolgerung ziehen.
Das macht mich jetzt auch neugierig, denn ich hab bei meinen beiden
Geräten die HW-Version noch garnicht verglichen.
> Ich kann es nur leider gerade nicht, da ich auf Arbeit bin.
Dito, werde mich morgen dazu äußern.
Hayo
Hallo zusammen,
ich habe im Trac eine Seite eingerichtet, wo der Gerätetyp, die
Hardware-Version, die FW mit der getestet wurde und ob die Darstellung
der Flanke in Ordnung ist festgehalten ist. Ich wäre euch dankbar, wenn
sich freiwillige finden würden und mir an
branadic (ät) users (pünktchen) sourceforge (pünktchen) net
ihre Daten zukommen lassen würden.
Die Übersicht findet ihr unter:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
Dies könnte entscheidene Aufschlüsse über Unterschiede bringen und alle
können davon nur profitieren.
Wir haben uns zu dieser Seite vor allem entschlossen, damit nicht jedes
mal neu nachgefragt werden muss welches Gerät und welche
Hardware-Version zugrunde liegt. Die Seite kann jederzeit beliebig
erweitert werden, sodass Rückschlüsse schneller getroffen werden können.
Wenn ihr euren µC-Nickname und/oder euren Sourceforge-Nickname ebenfalls
mit preisgeben wollt, so werde ich auch dies mit einpflegen.
Ich werde nachher auch meine Info's dazu dort festhalten.
Beste Grüße, branadic
Hallo,
das mit den Hardware-Revisionen habe ich mir auch schon gedacht.
Meines (W2022A 8C7.0L) ist mit der 1.3 FW ausgeliefert worden. Habe aber
die 1.4 FW aus dem Forum hier mal installiert. Evtl. liegt da noch etwas
im Config-Flash, das der FPGA selbst ausliest und bei mir jetzt falsch
eingestellt ist?
Meine 1.3er kann ich leider nicht mehr aufspielen um das zu testen ;-)
Vielleicht hat ja noch jemand eine 1.3er mit gesichertem Config-Bereich
für mich? Dann könnte ich das mal ausprobieren.
Der Effekt ist absolut reproduzierbar. Auch nach Aus- und Einschalten.
Sobald die ADCs zeitlich verschoben sind in der FW, passts.
Servus branadic,
super Idee. Ich kann die Bilder auch kleiner machen, wenn du willst ;-)
Dann wirds etwas übersichtlicher.
Wichtig ist evtl. auch, welche Kanäle betroffen sind und welche Firmware
im Original drauf war.
Hallo Stefan,
hab deine Daten mal mit aufgenommen. Welche FW im Original mal drauf war
sollte keine Rolle spielen.
Ein komplettes Backup vom Protected Bereich und vom Config Bereich
findest du hier in diesem Thread auch irgendwo. Das hatte Hayo mal
hochgeladen.
Welche Kanäle betroffen sind kann man natürlich hinzufügen. Ich hab es
bei mir auf allen Kanälen probiert und mit Hayo's FW ist das in Ordnung.
Gruß, branadic
Hallo branadic,
bei meinem W2012A mit HW 8C7.0F ensteht dieses Problem mit
Hayos Betas auch nicht (beide Kanäle o.k.). Original war die
FW 1.4 drauf, falls da jemand Statistik führen möchte.
Gruß, Guido
ja wir führen Statistik-s.o.
und weil es mit Fotos gleich viel offensichtlicher ist, anbei meine
Version.
Bei wem tritt das im Foto gezeigte/ beschriebene Problem mit den Probes
noch auf?
Gruß, brunowe
>Welche FW im Original mal drauf war sollte keine Rolle spielen.
Eben da bin ich mir nicht sicher. Es gab ja auch Probleme mit der ersten
Serie und der Firmware der A-Serie. Da gingen die Drehknöpfe nicht mehr.
Vielleicht gabs ja zwischenzeitlich wieder ein kleines Update im FPGA.
Und der neue Config-Bereich, den ich mir mit den Update auf 1.4
aufgespielt habe, bringt mein Oszilloskop durcheinander. Wäre doch auch
ein Grund, warum die 1.4 nie im Internet veröffentlicht wurde.
Hi branadic,
ich hoffe es ist ok, dass ich ebenfalls nicht maile sondern hier poste.
Ich kann gleich beide Varianten anbieten. Übrigens für alle die auch
testen wollen aber den Trigger nicht hinkriegen - bei mir hat der
Trigger nur gegriffen wenn ich auf Normal Mode geschaltet hab.
- W2022A / 8C7.0L gekauft 10.2008 mit FW1.3 getestet mit 1.2.BF.0.69
Kanal 1 - Flanke völlig vermurkst
Kanal 2 - Flanke ok
- W2014A / 8C7.0L gekauft 03.2009 mit FW1.4 getested mit 1.2.BF.0.70
Kanal 1 - 4 Flanke ok
Foto spar ich mir, da es im Fall 1 genauso aussieht wie auf den hier
veröffentlichten. Meinen Nickname kennst Du ja ;-)
Hayo
Es ist definitiv irgendwann in der Modellreihe einmal etwas an der ADC
Reihenfolge vertauscht worden. wer sich da noch dran erinnern kann- das
von Stefan beschriebene Problem hatte ich auch. Bei mir kam es
folgendermaßen dazu: Ich hab mir bei meinem W2022A mit 8C7.0E den config
Flash.- Bereich zerlegt und dann eine config von Hayo (welche wohl
ursprünglich von Markus stammt) drauf gespielt. Erst als ich mein
eigenes Flash-config wieder drauf hatte, war alles wieder ok.
Bei den Flanken- Messungen ist uns aufgefallen das es gravierende
Unterschiede zwischen den einzelnen Probes im x1 Bereich gibt. Die
Anstiegszeit des Cal. Signal unterscheidet sich damit tw. gewaltig von
Probe zu Probe (wohlgemerkt im x1- Bereich). Deshalb hier nochmals der
Tip, wenn's um Signale über 10MHz geht, oder um die Messung von
Anstiegszeiten- dann unbedingt im x10 messen.
gruß, brunowe
Hallo
Habe jetzt auch mal probiert.
Zuerst waren alle Signale nicht gut.
Dann öfters. Calibrate ADC /DCA gemacht.
Dann Flanke gemessen.. Flanken waren nicht sehr schön..
(Was ist das eigentlich für eine komische 3mm Buchse für die Probe..?)
Habe dann den Taskopf mit den zwei CO.Trimmer (neben CNC-Buchse)
eingestellt.
Da kriegt man dann die Flanke so hin, dass dieser Spike nur noch ca.
alle 3-4 sek aufblitzt. (Bei allen Kanälen komme ich da so hin)
Wenn der Tastkopf schlecht einstellt ist, werden genau diese Spikes
gößer.
Also dürfte es sich da um Störsignale von Außen handeln?!
Es mach auch schon was aus, wenn man die Masseleitung beim Tastkopf
anschließt und neben der Probe-Buchse, auf Masse legt!
l.G Roberto ( W2024A; HW.:8C7.0L ; FW.: 0.66)
>Ich hab mir bei meinem W2022A mit 8C7.0E den config>Flash.- Bereich zerlegt und dann eine config von Hayo (welche wohl>ursprünglich von Markus stammt) drauf gespielt. Erst als ich mein>eigenes Flash-config wieder drauf hatte, war alles wieder ok.
@Bruno
Genau so wird es bei mir auch passiert sein. Beim sichern gab es bei mir
allerdings ein Problem und die Datei ist futsch. Ich hab mal deine
W2000.flash von GoogleGroups probiert (V1-10-03). Hat aber nichts
geholfen. Hast du zufällig noch eine andere?
Nachdem das Problem jetzt ja wohl eher nur bei mir liegt, will ich euch
nicht weiter mit dem Testen von meiner Firmware nerven. Trotzdem Danke
für alle Rückmeldungen. Notfalls muss ich das bei mir halt irgendwie mit
einbauen einbauen ;-)
Muss keiner hier demnächst eine Diplomarbeit schreiben und sucht noch
ein Thema? Wie wärs mit "Neuentwicklung der FPGA-Software für W2000" g
Gruß,
Stefan
Hallo,
Damit unseren Programmierern die Arbeit nicht aus geht...
Es gibt unter:
http://apps.sourceforge.net/trac/welecw2000a/wiki/FWwishlist
eine Wunschliste für SW Erweiterungen.
Im Rahmen der Flanken- Messung ist mir aufgefallen wie praktisch die an
jedem analogen Oszilloskop vorhandene variable Verstärkung ist. Um die
Höhe eines Sprungsignals exakt auf 5 Div einstellen zu können, und damit
leichter die 10%-90% risetime ablesen zu können, ist so eine Streckung
in der y-Achse sehr praktisch.
Das Ganze ist in SW bestimmt mit mittleren Aufwand machbar. Allerdings
muss ein neuer Menüeintrag erzeugt und bei Anwendung der nicht
normierten Verstärkung klar darauf hingewiesen werden. Vielleicht fasst
sich ja mal ein Berufener ein Herz?
Gruß, brunowe
Und nochmal ich ;-)
Mir ist gerade noch aufgefallen, dass Hayo und ich die selbe
Hardware-Revision haben. Das ist schon komisch, vorallem weil Hayos
Geräte unterschoedlich alt sind und scheinbar viele verschiedene
Revisionen gibt. Ich gehe davon aus, dass wir beide die selbe Sicherung
verwendet haben (die hier im Forum irgendwo liegt.) Da wird wohl die
Revision mit abgespeichert sein. Also auch nur bedingt aussagekräftig.
Einspruch,
ich habe mir auch mal meine FW zerschossen. Hatte seinerzeit mal meine
Sicherung meines W2014A hier eingestellt und diese hat Hayo, dem Chaos
auf dem eigenen PC sein dank, mir wieder zur Verfügung gestellt. Diese
habe ich bei mir auch wieder eingespielt. Demnach müsste ich die gleiche
Hardware-Revision haben. Hab ich aber nicht.
Gruß, branadic
Hi, die Hardwareversion wird nicht aus dem Flash geladen sondern aus dem
FPGA. Es gibt eine eigene Funktion dafür Read_Version().
Wie viele gibt es denn jetzt mit vermurkster Flanke außer Stefan und
mir?
Hayo
@Stefan
Lass mir doch mal Deine Korrektur zukommen, eventuell kann ich eine
Funktion einbauen die über einen Testschalter die Geräteversion (mit
vermurkster Flanke oder ohne) ins Flash schreibt und dann die Korrektur
aktiviert oder nicht. Dann haben wir da auch wieder Gleichstand.
Hayo
Ehe man weiß, wie es zusammenhängt und was der Grund ist, ist so ein
"Ausgleich" für einen Fehler keine gute Idee. Das verleitet dazu, die
Ursache nicht weiterzusuchen.
/Hannes
@Bruno
Die Idee mit der variablen Verstärkung ist nicht schlecht, die fand ich
an meinem analogen Oszi auch ganz praktisch. Muß mal sehen wo ich das
ich die Prioliste einsortiere...
Hayo
@Hannes
Ich denke Stefan ist an der Sache dran. Wenn er da nähere Erkenntnisse
hat können wir weitere Maßnahmen einleiten. Zudem scheint mir die
Ursache soweit ich das verstanden habe zu sein, dass die FPGA-Logik die
ADC-Daten in der falschen Reihenfolge einsortiert, oder?
Hayo
Mein Einwand war eher genereller Natur. Ich hatte das nicht so
verstanden, als wenn schon Einigkeit darüber bestünde, was der Grund für
das Problem mit der verdrehten Auslesereihenfolge der ADC ist bzw. woran
man es festmachen kann, ob es besteht oder nicht. Aber vllt hab ich da
nur was überlesen.
Lass dir mal von mir nicht reinreden. :D
/Hannes
So,
Bruno hat mir sein Backup zugeschickt. Mit dem sind die Flanken jetzt
wieder "schön" ;-)
Übrigens hab ich jetzt mit dem Config die Hardware-Revision 8C7.0E
(vorher L) und, soweit ich mich erinnern kann, wieder eine andere
SerienNr.
Muss also doch letztendlich irgendwo im Flash stehen.
Gruß,
Stefan
@Stefan
- die Hardwareversion wird nicht aus dem Flash gelesen, kann man sich im
Coding ansehen, die wird durch einen Zugriff auf das PIO-Interface
ermittelt.
- Die Seriennummer wird aus dem Flash gelesen
- hab ich das richtig verstanden, das Du nur durch das Einspielen eines
anderen Flashdumps das Gezackere wegbekommen hast??? Dann würde ich
den Dump auch gern mal ausprobieren.
Ich war der Meinung ich hätte in beiden Geräten den gleichen Dump
eingespielt, muß ich mal checken wenn ich zuhause bin.
Hayo
Hallo,
da fehlt uns noch Einiges am Verständnis. Dass der Config-Bereich
mir die Buttomplane versaut hat ist ja leicht einzusehen. Aber dass
auch die Fehler bei der Invertierung hieraus resultierten?
Ich denke, die (und andere) werde ich bald wieder sehen, wenn ich
READOUTADC_ALL in C teste. :-)
Gruß, Guido
>die Hardwareversion wird nicht aus dem Flash gelesen, kann man sich im> Coding ansehen, die wird durch einen Zugriff auf das PIO-Interface> ermittelt.
Glaube ich dir ja auch sofort. Nur der FPGA kann sie ja auch wieder aus
dem Flash lesen. Sie hat sich bei mir halt definitiv geändert nach einem
kompletten Neubeschreiben mit einem anderen Backup.
>Ich war der Meinung ich hätte in beiden Geräten den gleichen Dump>eingespielt, muß ich mal checken wenn ich zuhause bin.
Kann durchaus sein. Wenn das eine etwas älter ist (so wie meines),
scheint es mit nen Einstellungen eines neueren Config-Bereiches Probleme
zu geben.
Vielleicht gibt hier ein Diff des Config-Bereichs genauer etwas
Aufschluss. Außerdem kann ich mal probieren, meinen FPGA temporär zu
updaten und mit einem 1.4er Config-Bereich zu betreiben.
Wenn also jemand sowiso schon ein Backup von seinem FPGA zu Hause
rumfliegen hat, weil er mit slogs Software experimientiert hat UND bei
ihm ab Werk die 1.4er Firmware drauf war, würde ich mich über die Datei
sehr freuen ;-)
Gruß,
Stefan
Ich bin gerade dabei für den Rollmode/Shiftmode das Timing und die
Refreshrate genau zu kalibrieren.
Dabei mußte ich feststellen, dass das Timing für die 500mS TB so stark
von der Zeichenroutine beeinfußt wird, dass die Funktion hier nicht
sinnvoll einsetzbar ist. In der nächsten Version werde ich also auf TB
1S zurückrudern mit der dann der USTB-Modus automatisch einsetzt. Die
500mS TB wird dann wieder konventionell ausgegeben.
Gruß Hayo
@Stefan
Das wäre jetzt mein nächster Ansatz gewesen, nämlich den FPGA auf einen
aktuellen Stand zu bringen um dadurch das Gezackere wegzukriegen.
Allerdings habe ich mich mit der FPGA-Thematik noch nicht weiter
auseinandergesetzt, so dass ich mich da erst einarbeiten müßte um zu
wissen wie man das macht und welche Tools man dazu braucht. Wenn Du da
weiter bist gib doch mal eine Kurzanleitung raus.
Hayo
@ Stefan:
Wenn ich's schaffe, werde ich am Wochenende meinen FPGA sichern. Hab ein
2024A, die Firmware war wohl 1.4...
Bin dieses Wochenende leider ausgebucht (heute Hochzeit, morgen Umzug),
wird wohl erst morgen Nacht was. Hatte beim letzten Öffnen vergessen,
den kleinen Widerstand für das JTAG zu brücken :-/
Außerdem wollte ich gerne noch den Lüfter tauschen. Der nervt mich
langsam...
Michel
Hallo,
eine Anleitung über das dumpen/ flashen des FPGA- Config Flash findet
ihr hier:
http://apps.sourceforge.net/trac/welecw2000a/wiki/FPGAConfigFlash
Die Sicherungsdatei eines W2022a EPCS16 findet ihr bei den Google
Groups. Die Datei heißt: EPCS16_W2022A.JIC.rar
gruß, brunowe
@Michael
Super. Mach dir keinen Stress. Bin vor Montag auch nicht mehr zu Hause.
@Bruno
Die Tastkopf-Geschichte habe ich nicht vergessen. Werde ich mal testen.
@ Hayo: Ich bin dann mal soweit mit den 4 C-Funktionen. Habe den
Eindruck, der ADC-Abgleich ist vermurkst, aber vllt. siehst du
das viel schneller als ich. Auch der 5 ns/div Bereich scheint
noch etwas Nacharbeit zu benötigen.
Viel Spaß damit, Guido
Hallo Guido und Hayo,
PREPARE_READADC ist dann überflüssig. Die hat der Entwickler nur
gebraucht, weil die Übergabe von mehr als 8? (bin mir nicht ganz sicher)
Parametern in ASM nicht ganz trivial ist. Da hat er die Übergabe einfach
auf zwei Funktionen aufgeteilt. Einfach löschen,weil du die
Korrekturwerte ja direkt aus dem Array ausliest.
Gruß,
Stefan
Hi,
komme heute nicht mehr dazu, hab mir das aber mal runtergeladen. guck
ich mir morgen mal an. Wenn ich soweit komme bastel ich das in die
Wochend-Beta mit rein.
Gruß Hayo
Hallo Hayo,
keine Hektik, da sind bestimmt noch genügend Fehler drin. Bei
hohen Frequenzen sieht es ganz schlimm aus.
Was anderes: wo finde ich floatstr_t.h?
Gruß, Guido
Moin, moin,
danke Kurt, werd ich mal ausprobieren. Inzwischen habe ich ausgiebig mit
diversen Config-Files die ich noch rumliegen hatte experimentiert, alles
am W2022A, mit folgendem Ergebnis:
- Erstmal muß ich Stefan Recht geben - die Hardwareversion wird
offensichtlich über Umwege doch aus dem Flash gelesen. Bei mir wechselte
die Hardwareversion mit jedem Config-Dump den ich eingespielt hab.
- 8C7.0L Flanke vermurkst (1.2.BF.0.70)
- 8C7.00 Flanke vermurkst (1.2.BF.0.70)
- 8C7.0G Flanke ok!! (1.2.BF.0.70) (stammte von einem Gerät das
ebenfalls wie meins etwa 10.2008
ausgeliefert wurde)
- 8C7.00 Flanke vermurkst (aus einem W2014A als Komplettdump mit FW1.3)
Was mir dabei völlig unklar ist: Wie kann der Config-Bereich das
Auslesen des ADC beeinflussen??? Greift die Flashkonfiguration in den
FPGA-Ablauf mit ein?? Ist das evtl. auch der Schlüssel für die
Beseitigung der Schwingungen und Störungen die ja im anderen VHDL-Design
nicht auftreten?
Fragen über Fragen...
Hayo
Hallo,
Wir haben hier ja schon eine Aufstellung der Flanken-integrität und der
EPCS16-Checksum einiger Geräte gesammelt:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
Da sich die Checksum der dort aufgeführten W2022a und W2012a nicht
unterscheidet, ist es eigentl. auch nicht möglich das dort irgendwelche
gerätespezifische Daten (Seriennr., HW-Version usw.) abgespeichert ist.
Es wäre hilfreich wenn noch mehr Leute ihre Checksum dort eintragen,
vielleicht hilft uns das die Zusammenhänge besser zu verstehen.
Der FPGA liest auch Daten aus dem Config Flash des AM29LV. Ohne den VHDL
Code wird es allerdings sehr schwierig werden das genau zu ergründen.
gruß, brunowe
Hallo Roberto,
Die Checksum wird von Quartus bzw. dem standalone programmer automatisch
beim erstellen des EPCS16 Backup erzeugt.
Wie dieses dumping funktioniert ist unter:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
ausführlich beschrieben.
Man benötigt dazu aber etwas Vorarbeit, man muss im Prinzip erst einmal
die Toolchain für VHDL installieren. Also Quartus bzw. den standalone
programmer, den USB Blaster driver für Cypress FX1 oder man benötigt den
Altera USB Blaster. wie das genau geht ist ebenfalls unter SF
beschrieben.
Um die Checksum eintragen zu können benötigt man einen SF- Account.
Dann einfach bei dieser Seite:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
unten links auf editieren und eigene Werte eintragen.
Wer keinen SF-Account hat darf seine Checksum natürlich auch gern hier
posten.
Gruß, brunowe
Hi,
wo bekomme ich denn den originalen USB-Treiber für das Scope her? Bei
mir findet Windows (XP SP3) den Treiber nicht ('Unbekanntes Gerät'). Ich
dachte, der ist in der Winpows Anwendung integriert - war aber leider
nix. Oder läuft die nur mit dem Seriellen Port (nicht der Updater)?
Auch ein Einbinden des USB-Blaster Treibers funktionierte nicht :-(
Nu' hab' ich extra die Brücke am JTAG-Interface gelötet und kann da sgar
nicht nutzen... :-(
Michel
Ach ja, noch 'ne Frage zum Triggermode:
Zum Messen der Anstiegsflanke für das Userinstruments - Form habe ich
gemerkt. dass der Trigger im Auto-Modus nur funktioniert, wenn
mindestens 1,5 Perioden auf den Schirm passen (ca.). Im Normal-Modus
ließ sich die Flanke dann korrekt messen. Allerdings blieb die Anzeige
stehen (eingefroren!), wenn ich das Signal vom Probe genommen hatte. Das
ist doch sicherlich nicht gewollt, oder?
...und zur Firmware:
Wenn ich die gesamten Abgleiche gespeichert habe, bleiben die beim
Firmwareupdate erhalten oder muß ich die jedesmal wieder neu
durchführen? vom Gefühl her bleiben sie aber ich lass' mich gerne
belehren.
Ansonsten habe ich das Gefühl, dass man mit dem Teil mittlerweile
richtig arbeiten kann. War schon kurz davor es wieder zu verkaufen und
ein Rigol oder so zu ordern.
Mit dem Max038 wollte ich mir einen simplen Funktionsgenerator aufbauen
und ein wenig rumspielen. In einem Youtube Video hatte ich gesehen, dass
die Amplitude des gemessenen Signals bei steigender Frequenz immer
kleiner dargestellt wurde (verglichen mit einem Tek). Ist das wirklich
so?
Michel
Dass die Flanke im Normal-Mode stehen bleibt, ist normal. Dabei wird der
Schirm nur dann neu geschrieben, wenn das Triggerereignis auch wirklich
eingetritt.
Im Auto-Mode dagegen wird zuneaechst aktualisiert, wenn das
Triggerereignis eintritt. Allerdings auch dann, wenn es NICHT
eingetreten ist, aber eine gewisse Zeit vergangen ist (ca 0.3s).
Den Eindruck, dass Auto ein bissl spinnt, hab ich auch :).
Gruessle
Michael schrieb:
In einem Youtube Video hatte ich gesehen, dass
die Amplitude des gemessenen Signals bei steigender Frequenz immer
kleiner dargestellt wurde (verglichen mit einem Tek). Ist das wirklich
so?
Nein, das Video habe ich gefaked, weil ich Langeweile hatte... :D
Selbstverständlich ist das so, ansonsten hätten wir das nicht
eingestellt. Wobei man sagen muss, dass der Tastkopf auf 1:1 stand und
nicht auf 10:1.
@ Hayo
Ich habe nach wie vor ein gewaltiges Problem mit meinem Kanal 3. Bei
Zeitbasen >5µs hab ich gewaltige Spikes auf dem Kanal. Bei Zeitbasen
kleiner gleich 5µs sind diese wie von Geisterhand verschwunden.
Ich glaube weniger, dass das auf ein Problem der Hardware zurückzuführen
ist, als vielmehr auf ein Problem in der VHDL oder FW. Möglicherweise
ist es die besagte Assembler Routine?
Was ich mir sehr wünschen würde ist, wenn unter dem Menü-Punkt "Utility"
einer der frei gewordenen Softbuttons die Funktion bekommen würde das
Probe-Signal an- bzw. abzuschalten. Die Frage ist, wie tiefgreifend die
Abschaltung machbar ist. Eigentlich müsste man einen direkten Zugriff
auf die Signalerzeugung im FPGA haben. Hintergrund ist es
herauszufinden, inwieweit dieses Probesignal Störungen auf den Kanälen
produziert.
Lässt sich hier etwas derartiges realisieren?
Beste Grüße, branadic
branadic schrieb:
> Nein, das Video habe ich gefaked, weil ich Langeweile hatte... :D>Wobei man sagen muss, dass der Tastkopf auf 1:1 stand und> nicht auf 10:1.
Also doch gefaked ;-)
Hallo Hayo,
ich bin gerade noch ein wenig am Testen mit der aktuellen FW. Dabei sind
mir noch ein paar Dinge aufgefallen.
Mein Messaufbau besteht aus einem DDS-10 Board. Auf Kanal 1 hab ich ein
50-Ohm-Kabel mit 50-Ohm Abschlusswiderstand. Auf Kanal 2 einen Tastkopf
eingestellt auf 1:1 und auf Kanal 4 einen Tastkopf 10:1.
Alle drei Signale hängen an der gleichen Signalquelle. Wenn man jetzt
auf einen der Kanäle triggert sollte man meinen, dass die Flanken
halbwegs sauber übereinander liegen. Dem ist aber nicht so.
Durch den Spannungsteiler im Tastkopf von 10:1 sind mir wieder diese
Schwingungen aufgefallen. Diese liegen in der Tat nicht auf dem internen
Probesignal, sondern werden irgendwo nach dem Tastkopf erzeugt.
Im konkreten Fall mit einem Testsignal von 1kHZ Rechteck kann ich einen
Sinus-Anteil auf meinem Rechtecksignlal von etwa 100MHz feststellen, der
zusätzlich noch einmal mit einem Sinus von etwa 6,66MHz
amplituden-moduliert ist.
Weiterhin ist mir aufgefallen, dass der Trigger bei der
Spannungsbereichumstellung nicht nachgeführt wird. Soll heißen, trigger
ich bei 200mV/div auf dem Wert 100mV, dann sollte das auch noch so sein,
wenn ich den Bereich auf eine höhere oder niedrigere Spannungsbasis
umstellen. Tatsächlich bleibt der Triggercursor aber auf dem Bildschirm
an exakt der gleichen Stelle stehen. Das wiederum heißt, stelle ich den
Spannungsbereich um, Trigger ich plötzlich auf ein anderes Event. Das
ist natürlich nicht korrekt.
Der manuelle Trigger funktioniert nur bis zur Spannungsbasis 10ns/div,
bei 5ns/div leider nicht mehr.
Weiterhin habe ich mit einem 1kHz-Dreiecksignal getestet. Mir ist
aufgefallen, dass das Gerät zum Teil echten Quark anzeigt, wenn ich die
Zeitbasis verstelle. Erst wenn ich dann die Triggerquelle abziehe und
erneut anklemme wird das Signal auf der neuen Zeitbasis wieder richtig
angezeigt. Auch funktioniert hier der Trigger irgendwie nicht richtig??
Mit Dreiecksignalen überfordert?
Vielleicht aber nicht nur Negatives. Ganz gut finde ich, dass der
Trigger-Level für jeden Kanal einzeln einstellbar ist.
Gruß, branadic
Auch auf die Gefahr hin das das hier ein Monolog wird. Mir ist noch
etwas grundsätzlich bei der Menu-Darstellung aufgefallen.
Bei Kanal 3 passiert es mir regelmäßig, dass die Kanalzahl in der oberen
Menuleiste nicht mehr zu lesen ist, sonder schwarz ist. Drücke ich dann
Default Setup, passt die Darstellung wieder und Kanal 3 ist als Zahl
auch wieder lesbar. Weiterhin ist mir aufgefallen, dass die Zahlen im
oberen Menu zum Teil ein blaues Shining haben. Kann das jemand
bestätigen? Irgendwie scheinen die Planes da auch nicht korrekt zu sein.
Gruß, branadic
Hallo branadic,
dann störe ich mal deinen Monolog etwas. Vermutlich muss sich Hayo erst
erholen, von meinen C-Funktionen. Wenn er aus dem Lachen wieder raus
ist, wird er sich melden.
Mit den Planes gibt es in der Tat größere Probleme, die könnten auch
vom FPGA-Design kommen (Adresslinien vertauscht?). Wenn ich etwas
mehr Zeit habe schau ich mir das noch mal an.
In dem Bereich um 5 µV/div passieren noch mehr Merkwürdigkeiten.
Z.B. zeigt der Browsebalken hier nur noch etwas mehr als ein Fenster
an und weiter kann auch nicht gescrollt werden (es werden aber
immer noch 16 kB pro Kanal verarbeitet). Vllt. finden wir das mit
den C-Routinen, da kann man mal schnell was ausprobieren.
Die Probleme mit dem Dreiecksignal kann ich nicht nachvollziehen.
Ich habe zwar nur 2 Kanäle aber mit denen klappts (Triggerung o.k.,
keine Mist wird dargestellt). Das mit den Schwingungen muss ich
mal probieren. Ist das überlagerte 6,88 MHz-Signal nicht etwa ein
Alias?
Gruß, Guido
@ branadic
Das mit den falsch dargestellten Kanalzeilen in der Titelzeile kann ich
bestätigen, speziell bei Kanal 3.
Da ich noch relativ wenig Messequipment habe, sind die Tests, die Ihr so
durchführt für mich schwierig nachstellbar.
@ Kurt
Ich dachte, dass in der PC-Anwendung von Wittig ein USB-Treiber
enthalten ist. Als ich das Gerät angeschlossen hatte, zeigte mir Windows
erst ein neues Gerät an und sogar die Meldung, dass ich es jetzt
benutzen könnte.
Nach ein paar Sekunden kam aber die Meldung, dass das Gerät nicht
korrekt funktioniert und jetzt ein Treiber von Nöten sei. Das alles noch
VOR der Installation des USB Blaster.
Teufel auch: gerade habe ich's nochmal getestet und jetzt zeigt der
Rechner keine Probleme an und die Anwendung scheint das Teil auch
steuern zu können, nur ein Signal sehe ich nicht auf dem Schirm (der
Anwendung). Ich hab' nix gemacht, war nur mit'm Hund zwischendurch
spazieren ;-)
Ok, jetzt werde ich mich weiterhangeln bis zu den FPGAs...
Michel
Hi,
war heute unterwegs - daher keine Rückmeldung von mir. Dafür aber schon
eine Ankündigung: Es gibt gleich das nächste Wochenendrelease u.a. mit
Guidos C-Routinen.
@Branadic
> Ich habe nach wie vor ein gewaltiges Problem mit meinem Kanal 3. Bei> Zeitbasen >5µs hab ich gewaltige Spikes auf dem Kanal. Bei Zeitbasen> kleiner gleich 5µs sind diese wie von Geisterhand verschwunden.
Konnte ich bei mir nicht nachvollziehen. Bei mir ist auf allen Kanälen
das ganz normale Rauschen zu sehen. Nur auf Kanal 4 habe ich bei
warmgelaufenem Gerät starke Störungen.
> Was ich mir sehr wünschen würde ist, wenn unter dem Menü-Punkt "Utility"> einer der frei gewordenen Softbuttons die Funktion bekommen würde das> Probe-Signal an- bzw. abzuschalten.
Ich weiß leider nicht ob eine Abschaltung via Software möglich ist, oder
ob der Signalgenerator einfach in Hardware realisiert ist. Wenn es dazu
nähere Infos gibt baue ich das gerne mit ein.
> Alle drei Signale hängen an der gleichen Signalquelle. Wenn man jetzt> auf einen der Kanäle triggert sollte man meinen, dass die Flanken> halbwegs sauber übereinander liegen. Dem ist aber nicht so.
Muß ich mal prüfen. Einen derartigen Testaufbau hatte ich bislang noch
nicht - interessant!
> Weiterhin ist mir aufgefallen, dass der Trigger bei der> Spannungsbereichumstellung nicht nachgeführt wird.
Da gebe ich Dir recht. Das ist ein weiterer Punkt der
verbesserungswürdig ist. Evtl. ein Fall für die Wishlist.
> Auch funktioniert hier der Trigger irgendwie nicht richtig??> Mit Dreiecksignalen überfordert?
Hab bislang nur mit Sinus und Rechteck getestet - muß ich mal prüfen
> Bei Kanal 3 passiert es mir regelmäßig, dass die Kanalzahl in der oberen> Menuleiste nicht mehr zu lesen ist, sonder schwarz ist.
Ja das ist bei mir auch so, allerdings auch bei der FW1.4 - da scheint
ein Fehler zu sein der sich durch alle FW-Versionen zieht. Da mir das
aber nicht so tragisch erschien hab ich das erstmal in der Prioliste
weiter hinten einsortiert.
> Weiterhin ist mir aufgefallen, dass die Zahlen im> oberen Menu zum Teil ein blaues Shining haben.
Bei mir nicht
@Guido
> Z.B. zeigt der Browsebalken hier nur noch etwas mehr als ein Fenster> an und weiter kann auch nicht gescrollt werden (es werden aber> immer noch 16 kB pro Kanal verarbeitet).
Ein Blick in die Timebasetabelle meiner Programming Maps bringt die
Lösung: Die Zeitbasen 1µS/2µS/5µS werden nicht über eine entsprechende
reale Abtastrate erzeugt, sondern (warum auch immer) durch einen
entsprechenden Faktor von 20 bzw. 25. Da bleiben dann nur noch 819 bzw.
655 Werte von den 16K übrig - da ist dann nicht mehr viel mit browsen.
@Michael
Die USB-Übertragung zum PC sollte ohne Treiber funktionieren, ist aber
in der Beta FW völlig ungetestet - heißt ich hab es noch nie
ausprobiert.
Hayo
Bevor ich in die Wanne steige hier die 0.71 beta.
Wesentliche Änderungen:
- Der USTB-Bereich fängt jetzt ab 1S/Div an, darunter ist kein stabiles
Timing machbar
- Guidos C-Routinen sind implementiert und können per Testschalter 1
(shift + S) an bzw. ausgeschaltet werden. Defaultmäßig sind die
Assemblerroutinen aktiv. Leider sind die C-Routinen noch deutlich
langsamer als die Assemblerroutinen und haben auch noch kleinere
Abweichungen in der Null-Lage.
Hayo
Oje was ist denn da geschehen?
Neue 0.71 Version -mit bzw. auch ohne C-Routine.
Diese hässlichen Spikes kommen mir doch irgendwie bekannt vor.
Es gibt übrigens gravierende Unterschiede in der Darstellung mit und
ohne C-Routinen bei höheren Freq. ... aber richtig gut sieht keine aus-
nicht nur wegen der Spikes.
Gruß, brunowe
P.S.: morgen teste ich ausführlich
Hallo Bruno We,
in den C-Routinen sind ganz offensichtlich noch Fehler. Mit
höheren Frequenzen sehe ich nur noch Murks. Keine Ahnung was
schuld ist, aber das werden wir schon noch rauskriegen. Z.B.
stimmt bei mir der ADC-Abgleich nicht mehr ...
Gruß, Guido
Uuups,
nach einem kurzen Test habe ich die .69 Version wieder eingespielt. Die
Rauschpegel der Kanäle 2 und 3 waren erheblich höher als bei den letzten
Versionen. Die 5er Bereiche waren ja schon fast glatt, jetzt ist bei
Kanal 2 der Rauschteppich ca. doppelt so hoch wie bei 1 und bei Kanal 3
nochmal höher (etwa 4x wie bei Kanal 1). In den 1er und 2er Bereichen
ist das Rauschen allgemein höher geworden (mein Empfinden), die 2er
Bereiche fast nicht nutzbar... :-/ Schade
Michel
Nachtrag:
also mit der 0.69 Version sind diese Spikes definitiv nicht da.
Das mit dem Rauschpegel kann ich so eigentlich nicht bestätigen- der
sieht bei mir nur deshalb höher aus weil ich definitiv den einen
Ausreißer ADC habe (auf beiden Ch).
Aber irgendwo ist da noch grob der Hund drin...
Was aber interessant ist- die C-Routine hat massiven Einfluß auf das
festgestellte oszillieren bei höheren Frequenzen. Vielleicht geht ja
doch was?
Ich seh schon... das Projekt wird immer umfangreicher... und
interessanter.
Gruß, brunowe
Als Anhang noch ein kurzer, 500kB großer Videoclip, der das Rauschen mit
Hayo 0.71 und Abschirmung wie im HW Thread beschrieben, zeigt.
>Was aber interessant ist- die C-Routine hat massiven Einfluß auf das>festgestellte oszillieren bei höheren Frequenzen. Vielleicht geht ja>doch was?
Genau meine Meinung. Ich habe versucht die Assembler-Routinen
1:1 in C zu übersetzen. Gut möglich, dass ich dabei Fehler
produziert habe. Das müssen wir noch prüfen, ich brauche dazu erst
etwas Abstand.
Falls aber logische Fehler im Programm stecken, lassen sich die
dann halt in C viel leichter erkennen.
Gruß, Guido
Hi,
kann mir vielleicht jemand mit dem ByteBlaster helfen? Ich bekomme immer
das USB HID angezeigt. Einmal kurz hatte ich ein NIOS mit Fragezeichen
im Gerätemanager aber das bekomme ich nicht mehr hin. Als Nicht PNP wir
der Altera ByteBlaster aufgelistet (versteckte/nicht sichtbare
Komponenten).
Installiert habe ich den Quartus II 9.0sp1 Programmer und der findet
logischerweise keine Programmierhardware...
Kann ich alles wieder in den Urzustand versetzen und von vorne beginnen?
Mit der Sourceforge-Anleitung bin ich nicht weitergekommen... :-/
Michel
Moin, moin,
die Störungen auf den Signalen im Assemblerbetrieb werden indirekt durch
die C-Routinen verusacht. Ich habe diese einfach per Fallunterscheidung
mit in die gleiche Subroutine gepackt. Die Assemblerroutinen arbeiten
mit dem PFX-Befehl, der allerdings je nach Ausgangszustand einiger
Register unterschiedliche Auswirkungen hat. Durch das zusätzliche Coding
in der Subroutine wird der Ablauf hier offensichtlich gestört. Das läßt
sich nur durch getrennte Routinen entkoppeln. Ich werde mal sehen, dass
ich heute oder morgen eine neue Version zur Verfügung stelle.
Hayo
Hallo,
>Die Assemblerroutinen arbeiten>mit dem PFX-Befehl, der allerdings je nach Ausgangszustand einiger>Register unterschiedliche Auswirkungen hat.
unwahrscheinlich.PFX als Immediate-Befehl ist unabhängig von
Registerinhalten. In manchen Funktionen wird C-switch mit asm
kombiniert, das könnte dann auch nicht funktionieren.
>die Störungen auf den Signalen im Assemblerbetrieb werden indirekt durch>die C-Routinen verusacht.
Durch eine leicht verändertes Timing? Ich kann mir langsam alles
vorstellen.
Gruß, Guido
Hallo,
Guido wrote:
>Ich kann mir langsam alles vorstellen.
Prima, dann sind wir ja schon zu Zweit.
Sind alle aktuellen Assembler -> C Umsetzungen in readadc.cpp enthalten?
So umfangreich sind diese Funktionen gar nicht (hätte ich mir schlimmer
vorgestellt) Will damit sagen- so auf die Schnelle sehe ich keinen Grund
wieso der C-Code solche massiven Änderungen hervorruft- ADC Fehlabgleich
etc...
Bin gespannt was die nächsten Tage diesbezüglich zum Vorschein bringen.
Gruß, brunowe
@Guido
wie ich schon sagte - alle Assemblerroutinen arbeiten mit dem PFX-Befehl
und dieser ist, wie Du ja auch schon sagtest, registerabhängig.
Daher werde ich das in separate Routinen verpacken, dann kann ich auch
gleich sinnvollere Namen vergeben.
Hayo
@ Hayo,
PFX ist wie ich schon sagte unabhängig von Registerwerten. ;-)
@ Bruno We: Ja, schön kompakt ist es in C schon, das war der
Grund für die Mühe. Fehler können leicht entstehen, wenn ich
den Assemblercode falsch interpretiert habe. So war ich mir
z.B. ganz sicher, dass für Timebase >= 7 nur 1024 Longwords
bearbeitet werden. Dann wurde dort nur ein Viertel des
Schirms aktualisiert und ich habe nicht mehr gefunden, wie
ich auf die Idee gekommen bin.
Die Verzögerungen sind zum Teil leicht zu erklären: Schleifen
statt aneinandergehängten Code. Wenn es soweit ist, kann das
leicht optimiert oder sogar wieder in Assembler umgesetzt
werden.
Gruß, Guido
@ Hayo. Was mir gerade noch einfällt: Wir könnten doch die
Variablen in meinen Funktionen alle als static deklarieren.
Das könnte schon etwas beschleunigen.
Gruß, Guido
@Guido
Hab nochmal die PFX Sache nachgeschlagen, da hatte ich wohl was in den
falschen Hals bekommen. Aber irgendwie beeinflußt das C-Coding den
Assemblerablauf.
Und zwar kann man die Auswirkungen des C-Codings ganz gut sehen wenn man
in READADC_ALL2() (Zeile 18880) die Reihenfolge von C-Coding und
Assembler ändert. Ich habe nämlich das C-Coding hinter die
Assemblerroutine gepackt weil sonst der Nullpunkt des Signals komplett
um die halbe Gridhöhe verschoben wird.
Kannst ja mal ausprobieren. Evtl. kann man das Ganze auch dadurch
stabilisieren, dass man in den anderen Funktionen ebenfalls die
Reihenfolge ändert.
Gruß Hayo
@ Hayo: Tja, wenn wir verstehen, was da passiert, sind wir wohl
schon ein gutes Stück weiter. Ev. werden in READADC_ALL globale
Register verwendet, das werde ich mal anschauen.
Ich habe mal alle C-Variablen static deklariert und auch stat.
Kopien von DataArray1 verwendet. Das scheint etwas schneller zu
gehen, aber immer noch deutlich langsamer als der Assemblercode
(hoffentlich bilde ich mir das nicht nur ein).
Gruß, Guido
>Warum hast Du eigentlich die Funktion EXTRACTADCVAL() umgesetzt?
Fingerübungen, erstmal mit einer kurzen Funktion anfangen.
Gute Nachrichten: Die Störungen bei hohen Frequenzen stammen
aus READADC_ALL2. Das sollte die Fehlersuche erleichtern.
Gruß, Guido
So liebe Leute, nach dem Aufschrei der Empörung jetzt die überarbeitete
Version mit gekapselten C-Routinen, die Euch hoffentlich wieder milde
stimmt.
Die Umschaltung zur C-Routine geht wie gehabt via shift + S - allerdings
nur für Kanal 1.
Hayo
Hallo,
habe heute probiert den FPGA zu updaten. Leider ohne Erfolg,da das
Backup von Kurt von einem 4-Kanal-Gerät ist ich aber nur 2 habe :-( Muss
also noch warten, bis mir jemand ein passendes Backup schickt.
@Bruno
Das mit den Unterschieden der Tastköpfe kann ich nicht bestätigen.
Ich warte sehnsüchtig auf deine Abschirmanleitung ;-)
Momentan versuche ich die ganze ZPU-Geschichte bei mir zum laufen zu
bekommen. Das klingt interessant.
Gruß,
Stefan
Hi,
bei mir sind in der .72 FW die Kanäle 2 und 3 wieder besser geworden.
Danke Hayo ;-)
So'n Schönheitsfehler hab ich noch beim Grid gesehen:
Wenn man unter Display -> Grid das Grid auf 100% dreht (nur zur besseren
Sichtbarkeit), sieht man im unteren Rahmen so im mittleren Drittel ein
paar Unterbrechungen/schwarze Pixel. Hier scheint es auch noch Probleme
mit den verschiedenen Panes zu geben. Mit der Zeit füllen sich die
Löscher im Rahmen (die Unterbrechungen schließen sich)... Strange, Stört
allerdings nicht großartig, nur Kosmetik.
Dann werde ich jetzt mal weiter versuchen den ByteBlaster zum Laufen zu
bringen.
Gerade habe ich am PC den USB-Blaster installiert bekommen. Vielleicht
schaff' ich's ja gleich endlich auf meinem T41... :-/
Michel
Hallo,
anbei ein paar Fotos mit der aktuellen FW 0.72. Die Assembler- Routinen
laufen jetzt wieder so wie vor 0.71er Zeiten, die C-Routinen sind so
noch nicht zu gebrauchen- irgendwie überschreiben diese C-Routinen sogar
meine ADC- Kalibrierung so dass ich auch nach Umschalten auf Assembler
erstmal wieder kalibrieren muss. Noch sehr seltsam was da abgeht...
Hoffe meine Fotos helfen etwas bei der Klärung des Mysterium.
@Stefan: du versuchst gerade den FPGA zu updaten? was soll ich mir
darunter bitte vorstellen? Was für ein Backup brauchst du denn?
Abschirmanleitung- ich hab mir heute nochmal ein Stückchen Alu- Blech
besorgt, werde das morgen? mal ordentlich hinbiegen und dokumentieren-
es kann zumindest nix schaden.
Und... das mit den Tastköpfen sieht bei dir also nicht so aus?
du meinst diese (eins- zwei) zusätzlichen Schwingungen?
Du versuchst die ZPU- Geschichte zum Laufen zu bringen? Wo hängt's denn
genau? Du kannst dann auch gern von mir noch so 5-15 unveröffentlichte
(Test-) Versionen habe.
Gruß, brunowe
... irgendwie bin ich zu blöd für den ByteBlaster...
Wenn ich das Scope vom Rechner nehme (USB) und dann wieder verbinde,
meldet der Gerätemanager wieder ein unbekanntes Gerät :-/ Sehr
unbefriedigend diese USB-Geschichte :-(
Michel
Hallo,
dass mit den C-Routinen die ADC-Kalibrierung nicht mehr stimmt ist
klar, habe ich auch schon geschrieben. Dass sie aber diese
überschreiben? Ich muss mir die Speichermap nochmal anschauen. Die
Fehler zu finden wird durch die Grafik fast unmöglich gemacht. Wenn
ich auf 5 ns/div schalte erwarte ich ohne Vektoren 5 Pixel/div.
Angezeigt werden aber ca 25. Kommen die Fehler vllt. einfach daher?
Gruß, Guido
@Stefan:
was genau benötigst du für ein Backup?
Ich habe ein 2 Kanal 200 MHz Welec Oszi,
gekauft ca. 07/2008, original FW 1.3.
Leider bin ich erst jetz hier hinzugestoßen.
Wenn Du mir sagst, was Du genau brauchst, wär ich gerne bereit Dir
weiter zu helfen.
Gruß,
Michael
@Michael
>was genau benötigst du für ein Backup?
Ich bräuchte zum Testen ein Backup des FPGAs von einem 2-Kanal-Gerät mit
Original-Firmware 1.4. Aber trotzdem Danke für das Angebot.
@BrunoWe
>@Stefan: du versuchst gerade den FPGA zu updaten? was soll ich mir>darunter bitte vorstellen? Was für ein Backup brauchst du denn?
Ich würde ausprobieren, ob sich die Software des FPGAs von einem neueren
Gerät in ein älteres übertragen lässt. Evtl. sind ja Verbesserungen im
FPGA durchgeführt worden. Das es Unterschiede gibt, zeigt ja das Problem
mit dem nicht passenden Config-Bereich.
>Und... das mit den Tastköpfen sieht bei dir also nicht so aus?>du meinst diese (eins- zwei) zusätzlichen Schwingungen?
Nein, keine zusätzlichen Schwingungen im 10x-Bereich. Sind die beiden
zusätzlichen Einstellschrauben in den dicken Gästen auch zur Anpassung
des 10x-Bereichs an das Oszi? Hab ich sonst noch nirgens gesehen.
Vielleicht ist ja da was verdreht.
>Du versuchst die ZPU- Geschichte zum Laufen zu bringen? Wo hängt's denn>genau? Du kannst dann auch gern von mir noch so 5-15 unveröffentlichte>(Test-) Versionen habe.
Genau die Geschichte: Ich fass mal zusammen, wie ich es versuche:
- Kompilieren
- Mit dem Programmer den Ram updaten
- Oskar startet mit schwarzem Bildschirm
- Mit dem "In-Memory-..."-Tool die gerade erstellte "zpu" mit einem
Programm laden.
Bin ich soweit richtig?
Für die Zpu-Software brauche ich noch die Zpu-Toolchain. Da habe ich
gestern aufgehört. Gibts da keine einfache Zip-Datei oder so? Ich finde
die Dateien nur in einem Repository auf opencores.org
Verwendet zum Kompilieren habe ich die Dateien aus SourceForge.
Gruß,
Stefan
Hallo,
@Guido: Die von mir auf den Fotos
(http://www.mikrocontroller.net/attachment/52204/Hayo072.pdf) gezeigten
Fehler lassen sich selbstverständlich auch im 50ns- Bereich und auch mit
Vektordarstellung "off" nachvollziehen. Ein Fehler in der Interpolation
schließe ich deshalb eigentlich aus.
@Stefan: Das in den letzten 12 Monaten Verbesserungen im FPGA Design
durchgeführt wurden, halte ich eher für unwahrscheinlich. Deshalb denke
ich auch nicht, das du durch so ein Update viel gewinnst, aber man kann
es versuchen, da hast du natürlich recht.
Ehrlich gesagt ist mir nicht so ganz klar, wo es im Moment bei dir hängt
(bzgl. ZPU- Design).
1.) Schaffst du es ein vorkompiliertes SOF- File zu programmieren (via
Quartus Programmer)? Zu Testzwecken kannst du z.B. von den Google-Groups
das Hello_W2000_v0_1_4.zip ausprobieren.
2.) Kannst du das in SF abgelegte ZPU- Design erfolgreich kompilieren?
http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/fpga/zpu/quartus.tar.gz?view=tar
3.) Gehst du nach folgender Beschreibung vor:
http://apps.sourceforge.net/trac/welecw2000a/wiki/InSystemMemoryContentEditor
Derzeit ist das unter SF abgelegte Design nicht sonderlich interessant.
Viel besser ist es, wenn du dich aktiv am FPGA- Neuaufbau beteiligen
willst, dich mit der aktuellen, inoffiziellen Testversion zu
beschäftigen.
(Z.B. das, welches ich für das Youtupe Video:
http://www.youtube.com/watch?v=Ma7Yoz7AHhI verwendet habe.)
Wenn du Frage 1.) mit Ja beantworten konntest, dann sollten auch unsere
Testversionen laufen. Schreib mich einfach an, wenn du diese Version
haben willst, offiziell ins SF wollen wir es erst stellen, wenn noch ein
paar Fehler ausgemerzt sind.
Gruß, brunowe
Hallo BrunoWe,
also das HelloW2000... von slog läuft bei mir. Außerdem kann ich den
Code aus SF kompilieren. Also zweimal ja bei 1 und 2.
Danach ist mir nicht ganz klar, was ich machen muss. Ich laden die
kompilierte W2000.sof mit dem Programmer in den Ram. Das klappt auch.
Danach bleibt der Bildschirm schwarz.
Jetzt gehe ich in den In-Content-Manager (wie in dem Link unter 3.
beschrieben), sehe als einzige Instanz die ZPU.
An dem Punkt hänge ich jetzt. Welchen Code muss ich da hochladen? Ich
dachte, ich muss eine Art Firmware hochladen, die dann in dem im
FPGA-erstellten ZPU-Core läuft.
Ich glaube, es wäre hilfreich, wenn du mir eure Testversion mal
schickst.
Ich bin absoluter Neuling in VHDL. Interessiert mich aber brennend.
Deshalb möchte ich halt einfach mal damit ein bisschen rumspielen und
den Einstieg damit schaffen.
Gruß,
Stefan
@stefan: du musst während des uploads des programms die ZPU im reset
halten. dazu hälst du die linken beiden softbuttons (f1/f2) gedrückt,
während du im mem editor auf hochladen drückst. Siehe auch hier:
http://apps.sourceforge.net/trac/welecw2000a/wiki/InSystemMemoryContentEditor
solche kurzfristigen dinge können wir am besten per skype klären. mein
skype name: crazor01
@hayo: ich habe jetzt zwar gerade noch 0.63 drauf und werde sicher auch
nochmal mit der aktuellen testen, sobald das flashen wieder klappt, aber
mir ist aufgefallen dass die samples scheinbar immer ein pixel links von
der jeweiligen gridline dargestellt werden, sowohl mit als auch ohne
aktivierter vektordarstellung...
...und noch zwei Fragen an die Programmkundigen:
1.) Was macht eigentlich der Button- "Vektor off" bei Timebase <50ns?
Eigentlich sollte man erwarten das keine interpolierten Werte
dargestellt werden, dem ist aber offensichtlich nicht so. Es scheint so
als ob nur die schrägen Verbindungen fehlen.
Gerade für Testzwecke wäre es gut, wenn wirklich nur die gemessenen ADC
Werte dargestellt werden.
2.) Was macht der Button- "Switch Drawing" am Oszilloskop? Irgendwie
kann ich da leider keinen Unterschied in der Darstellung erkennen. Eine
optische Rückmeldung via via Display wäre natürlich gut, damit man auch
weiß was man denn eingestellt hat, sofern die Fkt mal geht.
Lässt sich die Anzeige "unmöglicher Werte" im Quick Measure Menü nicht
unterbinden? Ich wundere/ ärgere mich jedes mal über eine
Frequenzanzeige über 250MHz.
Gruß, brunowe
Ich hab ein Problem mit dem aktuellen GERMSloader. Und zwar ist ja wie
bereits erwähnt mein serieller Port etwas flaky, ab und an wird ein
Zeichen verloren oder doppelt übertragen. Nun seh ich ab und zu mal
einen Punkt in die Statusanzeige reinhüpfen und wieder verschwinden.
Soweit läuft dann alles weiter. Irgendwann bekomme ich aber:
Writing line 004277 of 023377: .X............0 sec / 134 sec left
Error: Timeout while reading response from DSO!
Response was: 'S219815B3D34<#33><#13>
'
Firmware update was NOT successful!
Please fix the connection issue and retry!
Momentan funzt aber auch der von mir neulich gepatchte
flashloader-with-retries nicht, das Problem scheint zu sein dass bei
einem Retry keine Antwort vom Gerät mehr kommt.
Hilfe!
Bruno We schrieb:
> ...und noch zwei Fragen an die Programmkundigen:> 1.) Was macht eigentlich der Button- "Vektor off" bei Timebase <50ns?> Eigentlich sollte man erwarten das keine interpolierten Werte> dargestellt werden, dem ist aber offensichtlich nicht so.
Ich gebe zu, dass das vieleicht ganz hilfreich wäre, allerdings ist es
nicht im Sinne der eigentlichen Funktion und auch nicht ganz einfach zu
realisieren.
Der Sinn der Funktion ist es keine Vektoren (Verbindungslinien)
darzustellen sondern nur die einzelnen Punkte. Im Falle der TB < 50nS
sind das die Werte die bei der Interpolation errechnet werden.
Die Interpolation ist nicht Bestandteil der Grafikroutine sondern findet
separat statt. Die Grafikroutine "weiß" also nicht einmal ob sie jetzt
gerade interpoliert darstellt oder nicht.
> 2.) Was macht der Button- "Switch Drawing" am Oszilloskop? Irgendwie> kann ich da leider keinen Unterschied in der Darstellung erkennen.
Na er schaltet halt den Zeichenmodus um (im Vektormodus) zwischen
Ausgabe via Line() Funktion und Connect_Pixels() Funktion. Die Line()
Funktion verbindet zwei aufeinander folgende Meßwerte miteinander, also
ein echter Vektor. Connect_Pixels() ist eine der alten Funktionen der
orig. FW und zeichnet (um Zeit zu sparen) im Prinzip nur nebeneinander
liegende senkrechte Linien. Dadurch ist die Darstellung etwas grober,
besonders in den Spitzen (man schon etwas genauer hinsehen).
Der Geschwindigkeitsvorteil der Connect_Pixels() Funktion ist
mittlerweile nicht mehr vorhanden seit ich die Line() Funktion mit dem
Bresenham Algorithmus ordentlich aufgebürstet habe. Daher ist die Line()
Funktion auch die Default-Einstellung.
> Lässt sich die Anzeige "unmöglicher Werte" im Quick Measure Menü nicht> unterbinden? Ich wundere/ ärgere mich jedes mal über eine> Frequenzanzeige über 250MHz.
Die Funktion benutze ich zur Zeit nicht, da ich an anderen Baustellen
zugange bin -> ich implementiere gerade die neue FFT. Das neue Grid ist
schon fertig. Daher hoffe ich dass es sich verschmerzen läßt wenn das
erstmal so bleibt.
Gruß Hayo
@all
Ich bin übrigens auf eine interessante Routine beim Trigger gestoßen.
Das Triggerweitenregister wird mit dem - jetzt haltet Euch fest -
Farbwert des Grids geladen!?!?
Fragt mich nicht was das soll, das kann nicht im Sinne der Funktion
sein, daher werde ich das mal ändern. Ihr könnt das ja mal testen,
theoretisch müßte sich die Triggerung ändern je nach Gridintensität.
Sachen gibts...
Hayo
Hallo Hayo,
Zusammenfassend kann man als Antwort auf meine Fragen also sagen:
1.) Für TB<50ns ist die Fkt "Vektor off" praktisch sinnlos- und das wird
auch so bleiben.
2.) Die Fkt "Switch Drawing" bleibt so wie sie ist, auch wenn (nicht nur
ich) da keinen Unterschied erkennen kann und man nie weiß in welcher
Stellung man sich gerade befindet.
3.) Wird im Rahmen der neuen FFT bereinigt.
trotzdem noch frohes Schaffen,
brunowe
Bruno We schrieb:
> Hallo Hayo,> Zusammenfassend kann man als Antwort auf meine Fragen also sagen:> 1.) Für TB<50ns ist die Fkt "Vektor off" praktisch sinnlos- und das> wird auch so bleiben.
Sinnlos finde ich das nicht. Wenn aber die Mehrheit der Meinung ist dass
es Sinnvoller ist nur die realen Stützwerte darzustellen ändere ich das
natürlich. Wäre dann ein Punkt für die Wishlist.
> 2.) Die Fkt "Switch Drawing" bleibt so wie sie ist, auch wenn (nicht> nur ich) da keinen Unterschied erkennen kann und man nie weiß in> welcher Stellung man sich gerade befindet.
Also ich kann da schon einen deutlichen Unterschied sehen wenn ich etwas
dichter rangehe. Was soll es denn sein? Eine dauerhafte Zustansanzeige
oder ein Popup beim Umschalten?
> 3.) Wird im Rahmen der neuen FFT bereinigt.
Nein, komme ich nicht zu. Vielleicht legt einer der Anderen in der
Zwischenzeit Hand an, dann baue ich das mit ein.
Hayo
Bruno We schrieb:
> Hallo Hayo,> Zusammenfassend kann man als Antwort auf meine Fragen also sagen:> 1.) Für TB<50ns ist die Fkt "Vektor off" praktisch sinnlos- und das> wird auch so bleiben.
Sinnlos finde ich das nicht. Wenn aber die Mehrheit der Meinung ist dass
es sinnvoller ist nur die realen Stützwerte darzustellen ändere ich das
natürlich. Wäre dann ein Punkt für die Wishlist.
> 2.) Die Fkt "Switch Drawing" bleibt so wie sie ist, auch wenn (nicht> nur ich) da keinen Unterschied erkennen kann und man nie weiß in> welcher Stellung man sich gerade befindet.
Also ich kann da schon einen deutlichen Unterschied sehen wenn ich etwas
dichter rangehe. Was soll es denn sein? Eine dauerhafte Zustansanzeige
oder ein Popup beim Umschalten?
> 3.) Wird im Rahmen der neuen FFT bereinigt.
Nein, komme ich nicht zu. Vielleicht legt einer der Anderen in der
Zwischenzeit Hand an, dann baue ich das mit ein.
Hayo
Hallo miteinander,
ich möchte an dieser Stelle erst einmal allen danken, die sich bisher an
unserer Umfrage zum Gerät beteiligt haben.
Ich würde es begrüßen, wenn noch weitere ihre Gerätedaten schicken
würden, unabhängig davon, ob der Flankentest durchgeführt wurde oder
nicht.
Gern sind auch Leute gesehen, die ein W20xx ohne "A" haben. Diese sind
scheinbar ganz in der Versenkung verschwunden, weil man von ihnen gar
nichts mehr hört.
Um so mehr würde ich mich auch darüber freuen, wenn gerade diese Leute
mal versuchen würden das veröffentlichte Slog-Design aufzuspielen und
Aussagen darüber zu treffen, ob ihr Oszi damit läuft oder nicht.
Beste Grüße, branadic
Kurt Bohnen schrieb:
> Hallo Hayo,> in ramloader.bat und flashloader.bat fehlt das -w
Ups, da ist mir wohl eine alte Version reingerutscht - sorry
Hayo
So, ich glaube das lag an der Temperatur. War 2 Stunden weg, nun hat's
Flashen auf Anhieb geklappt. Zwar mit meinem alten Skript, aber bei der
nächsten FW teste ich mal das neue ;)
Hab aber mal ne Frage zum neuen DAC-Abgleich. Gibt es nur drei Werte, je
einen für den 1er, 2er und 5er-Bereich? oder muss man tatsächlich auch
durch alle 1V/100mV/10mV-Bereiche durchgehen? Zumindest kommen bei mir
für die verschiedenen Größenordnungen die gleichen Kalibrierwerte
heraus. Oder sind das nicht die Werte, die beim Kanalwechsel als
CH*_DAC_Offset angezeigt werden?
Crazor schrieb:
> Hab aber mal ne Frage zum neuen DAC-Abgleich. Gibt es nur drei Werte, je> einen für den 1er, 2er und 5er-Bereich?
Genau, und das jeweils für jeden Kanal
Hayo
Crazor schrieb:
> Writing line 004277 of 023377: .X............0 sec / 134 sec left> Error: Timeout while reading response from DSO!> Response was: 'S219815B3D34<#33><#13>> '
Da muss mir mal ein GERMS-Kundiger weiterhelfen. Was bedeutet es, wenn
der Monitor mit '!' antwortet? Darauf muss ich sicher nur korrekt
reagieren und dann ginge es weiter.
/Hannes
Hallo zusammen,
zwar besitze ich derzeit (noch) kein Welec- Scope, verfolge eure
Entwicklungen aber bereits eine Weile. Leider bin ich beruflich im
Moment ziemlich im Stress, als kleine "Entspannungsübung" habe ich aber
mal einen Blick auf eure Veränderungen, genauer gesagt auf die neuen C-
Routinen von Guido geworfen.
Vielleicht hilft euch ja folgender Denkanstoß weiter:
In ADC_ReadData() wird ein Puffer 4096 * 4 Byte gefüllt. In
ADC_ProcessData() sollte dieser - wie ich vermute - in der inneren
Schleife byteweise ausgelesen werden. Der Code dazu sieht folgendermaßen
aus:
byte_data = *(chan_addr + i); //load one byte
Mal abgesehen davon, daß hier ein (sinnvoller) cast fehlt (wie an
anderen Stellen in der Funktion auch), könnte euch in dem Fall die
Endianess einen Strich durch die Rechnung machen. Falls die Werte little
endian im Speicher liegen, wird statt 0, 1, 2, 3, 4, 5, 6, 7, 8, ...
die Reihenfolge 3, 2, 1, 0, 7, 6, 5, 4, ... ausgelesen.
Beste Grüße,
odic
Hallo odic,
auf die Idee mit der Endianess bin ich auch schon gekommen und
habe das vorhin probiert.
Aber der Tip mit dem cast ist richtig gut, da werde ich nochmal
mit beiden Änderungen probieren müssen.
Gruß, Guido
Was je nach µC (oder Softcore) auch noch problematisch ein könnte wäre
das alignment. Vielleicht schaffst du es überhaupt nicht, mit einem
ULONG-pointer auf die gewünschten Werte zuzugreifen...
Falls du statt dessen einen UBYTE-pointer verwendest und zudem noch eine
andere Lösung für die Fallunterscheidung bzgl. highspeed findest,
könntest du dir diese Problem und zudem auch die geschachtelten for()-
Schleifen sparen...
Viele Erfolg noch,
odic
@Hannes
Ich habe mir mal den Assembler des GERMS angeschaut (vom nios forum),
das '!' scheint ein checksum error zu sein. Ich glaube es sollte reichen
die zeile wo das '!' auftrat noch einmal zu senden.
Martin
So, zur Mitte der Woche (Mittag quasi) hier die 0.73 als
Zwischenversion. Wesentliche Änderungen:
- Ich habe, was eigentlich schon lange mal fällig war, einen
Testsignalgenerator eingebaut den Ihr im Utility-Menü findet. Auf allen
vier Kanälen werden unterschiedliche Signale generiert. Damit kann man
z.B. die Cursor prüfen und Ähnliches (und nicht ganz zuletzt auch die
bald verfügbare FFT).
- Für die FFT habe ich schon einiges vorbereitet. Es gibt ein neues Grid
mit einer Breite von 512 Pix und eine neue FFT-Graphikroutine. beides
kann man sich schon ansehen, nur das noch kein echtes Spektrum
ausgegeben wird. Als Demo ist es aber schon ganz ok denke ich.
Übrigens die Sache mit dem Triggerweitenregister geht noch weiter.
Nachdem ich mich ja schon gewundert hatte, dass dieses Register mit der
Gridintensität geladen wird (in SetupADC()), habe ich jetzt
rausgefunden, dass über dieses Register tatsächlich die Gridhelligkeit
(Gridfarbe) gesteuert wird. Schon etwas obskur oder?
Gruß Hayo
Hallo Odic X.,
danke für die Tips, die laufen ja schon auf Optimierung hinaus.
Eine Änderung von "chan_addr" auf "unsigned char" hat den erhofften
Erfolg gebracht. Probleme mit der Endianess gibt es wohl nicht,
ich bin aber nicht sicher, ob die ADC-Korrekturwerte richtig
zugeordnet werden. Das teste ich weiter, es ist aber recht schwer
zu erkennen.
Die doppelte Schleifenstruktur lasse ich vorerst, sie ist zwar
ganz sicher nicht optimal für die Geschwindigkeit, aber ich kann
damit sehr schnell kleine Tests durchführen. Zu diesem Zweck
mache ich mir ja die ganze Arbeit.
Gruß, Guido
Hallo Guido,
wußte gar nicht, daß mein Nick irgendeine Bedeutung hat...
Wieder was gelernt...
Ein paar Fragen noch zu der Funktion:
1.) Das Thema Averaging handelst du in folgenden Zeilen ab:
temp_int = temp_byte + ((byte_data - temp_byte) >> averageval);
if (temp_int < 0) temp_int = 0; //limit to byte ???
else if (temp_int > 255) temp_int = 255;
byte_data = temp_int;
Funktioniert das korrekt? Wenn ich es richtig verstehe, dürfte
"byte_data - temp_byte" nur in jedem zweiten Fall das gewünschte
Ergebnis bringen. Da averageval maximal 1 ist (soweit ich gesehen habe),
sollte folgendes genügen:
byte_data = (unsigned char)(((unsigned short)byte_data + (unsigned
short)temp_byte) >> 1);
2.) Die Zeile "temp_int = (zero << 1) - byte_data;" erschließt sich mir
nicht ganz, kannst du mir da auf die Sprünge helfen?
3.) Was ist der Hintergrund der unterschiedlichen Ablage im Zielpuffer
in Abhängigkeit von highspeed?
4.) Wie groß ist int in eurem core eigentlich?
5.) Nutzt ihr noch irgendeine andere Kommunikationsplattform für solche
Entwicklungsdetails? Dann müßte ich hier nicht den Thread zumüllen...
Fragen über Fragen.... ;-)
Beste Grüße und einen schönen Abend,
Odic
Martin H. schrieb:
> das '!' scheint ein checksum error zu sein. Ich glaube es sollte reichen> die zeile wo das '!' auftrat noch einmal zu senden.
Alles klar, danke. Das werd ich mal schnell reinbauen.
/Hannes
Odic X. schrieb:
> Hallo Guido,> 4.) Wie groß ist int in eurem core eigentlich?
4 byte (d.h int = long int)
> 5.) Nutzt ihr noch irgendeine andere Kommunikationsplattform für solche> Entwicklungsdetails? Dann müßte ich hier nicht den Thread zumüllen...
Das ist hier der Thread für genau diese Themen, Du bist hier schon ganz
richtig. Für Hardwarelastige Angelegenheiten gibt es extra den
Hardware-Thread.
Hayo
Hallo Odic X.,
1.) Da habe ich mich noch garnicht drum gekümmert, es passiert nichts
katastrophales wenn ich den Button drücke. ;-)
So wie ich das sehe, ist es Geschmacksache: deine Version wichtet den
alten Wert ebenso stark wie den neuen, die Originalversion wichtet
den neuen Wert nur halb so stark wie den alten Mittelwert.
2.) Zur Invertierung wird die Differenz zwischen Zerolevel und
Signal zum Zerolevel addiert. Ergibt insgesamt
2 * Zerolevel - Signal.
3.) Großes Rätsel. Mir scheint, dass abhängig von der Timebase
die Daten im FIFO unterschiedlich angeordnet sind. Von
READADC_ALL2 werden sie noch 1:1 übertragen und in READADC_ALL
werden sie dann so sortiert, dass sie für die Grafik immer in
gleicher Reihenfolge stehen.
4.) Größer als ein Byte, das reicht. ;-) (Hayo weiß das besser,
s.o.)
5.) Nö, das sind wir zu altmodisch zu. Es sollen ja auch alle
mitlesen und, so wie du auch, ihre Meinung äußern können. Je
mehr Leute sich das anschauen, umso leichter werden die Fehler
entdeckt.
Gruß, Guido
Guido schrieb:
> 3.) Großes Rätsel. Mir scheint, dass abhängig von der Timebase> die Daten im FIFO unterschiedlich angeordnet sind. Von> READADC_ALL2 werden sie noch 1:1 übertragen und in READADC_ALL> werden sie dann so sortiert, dass sie für die Grafik immer in> gleicher Reihenfolge stehen.
Ohne mir das Coding angesehen zu haben: Mit scheint es ganz logisch,
dass abhängig von der Timebase die Reihenfolge variiert. Denn es kann
gut sein dass je nach gewünschter Abtastrate 1, 2 oder 4 ADC verwendet
werden. Entsprechend müssen die Daten dann in der richtigen Reihenfolge
zusammengestellt werden.
Gruß Hayo
Hallo Guido,
1.) So ich die bisherige Implementierung verstehe, wird die Differenz
zwischen altem und neuem Wert halbiert und zum alten Wert hinzuaddiert.
Dabei sind beide Werte gleich gewichtet. Am Ergebnis sollte sich also
durch die andere Implementierung nichts ändern, nur an der Performance.
Wenn es bei byte_data < temp_byte tatsächlich nicht zu extremen Fehlern
aufgrund des Überlaufs kommt, könnte ich mir höchstens vorstellen, dass
die Differenz bereits in einem signed int gebildet wird und das shiften
des Vorzeichens in diesem Fall ja kein Problem darstellt. Das
funktioniert dann aber nur "zufällig" problemlos. ;-)
4.) Für die Funktion reichts, für die Performance heißt unnötig groß
eben oft auch unnötig langsam. Außerdem möchte ich ja nicht, dass sich
short diskriminiert fühlt... ;-)
Beste Grüße,
odic
Das würde bedeuten, daß man sich die Weiterverarbeitung der Daten, die
keine sind, sparen könnte. Das war auch der Hintergrund meiner Frage.
Wenn man an der Stelle eine pauschale Fallunterscheidung machen könnte,
wären evtl. die vielen relativen Speicherzugriffe unnötig, die 16384 Mal
ausgeführt werden...
Hallo odic,
1.) Du hast Recht, die Gewichtung ist in beiden Fällen gleich.
Manchmal hilft es doch, wenn man es sich arithmetisch hinschreibt.
Dann kann ich die Rechnung ja gleich im Byte machen und spare den
cast (data_byte = (data_byte >> 1) + (temp_byte >> 1);)
4.) Das ist völlig richtig und das habe ich auch vor, sobald ich
kapiere welche Werte tatsächlich zur Anzeige kommen. Ich vermute
grundsätzlich die ersten 4096, tatsächlich werden in dem Bereich
(Timebase = 7) aber nur wenige hundert Pixel angezeigt. Das muss
ich mal mit Hayo klären, der weiß das wahrscheinlich auswendig.
Gruß, Guido
Guido schrieb:
> tatsächlich werden in dem Bereich> (Timebase = 7) aber nur wenige hundert Pixel angezeigt. Das muss> ich mal mit Hayo klären, der weiß das wahrscheinlich auswendig.
In den Programing Maps in der Timebasetabelle findest Du die benötigten
Werte. Ich werde mal eine aktualisierte TB-Tabelle mit den neuen
Rollmode-Werten rausgeben.
Hayo
> Dann kann ich die Rechnung ja gleich im Byte machen und spare den> cast (data_byte = (data_byte >> 1) + (temp_byte >> 1);)
Wäre natürlich besonders elegant, geht aber leider nicht. So verlierst
du den Übertrag, wenn die untersten beiden Bits 1 sind...
Hallo Hayo,
freue mich schon auf die FFT. Meinst du es ist möglich in allen
Zeitbereichen die "Zoom"-Möglichkeit bereitzustellen? Z.B. im
2us-Bereich ist es schon dürftig.
@Guido,
vielleicht läuft die ADC_readdata schneller, wenn du unten den
Feldzugriff durch einen Byte-Zeiger austauscht?
Nur so eine Idee.
Gruß,
Stefan
Hallo odic,
>Wäre natürlich besonders elegant, geht aber leider nicht. So verlierst>du den Übertrag, wenn die untersten beiden Bits 1 sind...
Da hast du natürlich auch wieder recht. Naja, im Moment komme ich
sowieso nicht dazu viel zu ändern (das wird ja da Einfachste, weil
ich es von oben kopieren kann. :-) ).
@ Stefan: das erledigt sich von selbst, wenn ich nach odics
Vorschlag die Fallunterscheidung "richtig" mache. Besteht denn
Interesse an einer optimierten C-Funktion?
@ Hayo: Mit der Timebase-Table komme ich nicht gut klar, da mir
die Spaltenüberschriften zum Teil nichts sagen. Auch die Werte
in der Klammer bleiben mir schleierhaft.
Gruß, Guido
Hallo Guido,
bevor du weiter Zeit investierst wäre es vielleicht mal interessant zu
sehen, wie die Darstellung hochfrequenter Signale jetzt aussieht. Soweit
ich verstanden habe war ja einer der Gründe für deine Mühe ein
vermuteter Fehler in den ASM- Routinen....
Grüße,
odic
Hallo Hayo,
in Zeile 19362, hardware_t.cpp habe ich in der if-Abfrage das erste
Argument (timebase<7) entfernt. Gibt es einen Grund, warum das da
drinnen steht? Solange das da drinnen steht, trifft bei mir der Trigger
nicht sauber bei größeren Zeitbasen. Und ohne klappts einwandfrei.
Bemerke keinen Unterschied.
Gruß,
Stefan
Hi Stefan,
wie so einiges in diesem Coding ist dieses Statement anscheinend
ziemlich sinnbefreit. Wenn Du sagst dass es ohne besser läuft werde ich
das mal einfach übernehmen. Falls es da Probleme geben sollte werden
wohl schon entsprechende Rückmeldungen kommen. Ich hatte das bislang
unverändert gelassen, da sich mir der Sinn nicht direkt erschlossen hat
(zumal die Timebase 7 selbst überhaupt nicht verwendet wird).
Gruß Hayo
So hier die aktualisierten Programming Maps.
Unter die Timebasetabelle hab ich für die bessere Verständlichkeit eine
Legende geschrieben. In Kürze hier nochmal:
- Ta = Abtastrate
- Factor = Schrittweite in der for() Schleife über die 16384 Werte,
also der wievielte Wert tatsächlich verwendet wird.
Bei den interpolierten TB ist dieser Wert zwar 1, aber
da hier zusätzliche Werte eingefügt werden gibt es einen
Pseudofaktor in Klammern
- Sample Depth = Anzahl der tatsächlich verwendeten Werte, ergibt sich
aus 16384 / Factor. Bei den interpolierten TB stehen
die vollen 16384 Werte zur Verfügung, allerdings auf
dem Bildschirm immer nur Gridbreite * Pseudofaktor
d.h. bei TB 5ns - 600 * 1/10 = 60 reale Werte
- TB-Idx = der Index mit dem die Registerwerte aus dem Array gelesen
werden. Das entspricht dem Wert der Variablen
Selected_Timebase.
- TB-Register = das sind die Werte die aus dem Array gelesen
werden und ins TB-Register geschrieben werden.
Übrigens habe ich festgestellt, dass in Open Office die schraffierten
Flächen (interpolierte TB) nicht dargestellt werden.
Gruß Hayo
Ich habe jetzt ein W2024A abzugeben.
Hardware 8C7.0H
Firmware 1.4
Das Gerät hatte einen Kurzschluss zwischen Main/Delayed und
Mode/Coupling Taste den ich beseitigt habe. Außerdem wurde der JTAG
0-Ohm Widerstand eingelötet.
Das Zubehör ist Orginalverpackt. Preis 350,50€ + 5,90€ Versand.
Bezahlung per Überweisung, PayPal möglich. Wenn der Käufer verspricht
sich an der FPGA Entwicklung zu beteiligen, entfallen die Versandkosten!
Hi Kurt,
was willst Du mit so vielen Oszis? Einen Laden aufmachen ? ;-)
Im Ernst:
Ich hab einige Probleme den FPGA auszulesen (s.o.). Kannst Du mir einen
Tipp geben? Für einen Moment bekomme ich die Treiber für den USB-Blaster
installiert und wenn ich das Gerät vom USB nehme und wieder verbinde,
geht nix mehr. Im Gerätemanager steht immer: Unbekanntes Gerät und ich
bekomme keine Verbindung mehr hin, die Altera-Software findet dann
natürlich keinen Programmer. Normalerweise habe ich keine Probleme
solcher Art aber diesmal sind sie wirklich hartnäckig.
Irgendwas fehlt noch und ich krieg's nicht raus...
Meine Config: Windows XP SP3, Thinkpad T41 Laptop
Michel
Hallo Michael,
hast du schon ein anderes USB Kabel probiert?
Wieso viele Oszis? Ein 2022A und ein 2024A. Das zweite 2024A stammt aus
einem Deal mit Wittig und wird jetzt verkauft. ;-)
@Kurt
Ein faires Angebot, davon kosten ja allein schon die 200 MHz Tastköpfe
80 Euronen. Wenn ich das eher gewußt hätte, wären wir ins Geschäft
gekommen. Jetzt hab ich ja das 2014A schon seit ein paar Wochen und kann
es nicht mehr zurückschicken.
By the way, hatte nicht vor einiger Zeit ein netter WELEC-Besitzer
angeboten praktische Taschen herzustellen? Da hab ich seit dem nichts
mehr von gehört.
Hayo
@ Hayo
Wegen der Taschen:
Ich such' immer noch ein Muster im Netz. Wenn Ihr Vorschläge habt: Immer
raus damit. Ich wollte eigentlich nur eine oder zwei Versionen nähen und
nicht soviel rumexperimentieren.
Daher jetzt konkret die Frage: Was soll denn alles dran sein? Hauptfach
für das Scope, oben mit Reißverschluß und an einer Längsseite zwei
aufgenähte Taschen mit Klettverschluß für die Kabellage. Über die
Schmalseite Verbindungen/Ösen für einen Schultergurt?
Michel
Michael W. schrieb:
> Daher jetzt konkret die Frage: Was soll denn alles dran sein? Hauptfach> für das Scope, oben mit Reißverschluß und an einer Längsseite zwei> aufgenähte Taschen mit Klettverschluß für die Kabellage. Über die> Schmalseite Verbindungen/Ösen für einen Schultergurt?
Das wäre ja schon mehr als ich zu hoffen wagte - echter Luxus quasi. Das
würde mir schon gefallen!
Wenn ich da nicht jemandem eine Tasche "wegschnappe" würde ich sogar
zwei nehmen.
Hayo
Hallo Hayo,
danke für die Legende. Bei mir sieht es unter OpenOffice
eigentlich ganz gut aus. Jetzt verstehe ich das besser und
kann schon erste Schlüsse ziehen. Ganz offensichtlich kann
die Zeitbasis auf alle benötigten Teilfaktoren eingestellt
werden. Dies wird aber nicht immer so gemacht und stattdessen
z.T. auf Samplingtiefe verzichtet. D.h., es muss bei der
Entwicklung schon klar gewesen sein. dass es Probleme mit
der Kombination der ADCs gibt. Diese wurde nur dort eingesetzt,
wo es wg. Geschwindigkeit unausweichlich war.
@ odic: Klar will ich die Fehler finden. Ich habe auch schon
einiges probiert (das geht gut nebenher ;-) )aber bisher ohne
Erfolg. Ich werde jetzt erstmal die innere for-Schleife
auflösen, dann kann ich gezielt ADCs ausblenden. Mal sehen.
Gruß, Guido
Hi Folks,
für die HF-Freaks hier schon mal ein kleiner Vorgeschmack auf die
morgige Wochenend-beta 0.74.
Was Ihr seht ist ein 64 MHz Signal von einem Quarzoszillator an einem
10:1 Tastkopf. Achtet mal auf die Zeitbasis :-)
Zur Zeit arbeite ich noch an einer besseren Interpolation, die nicht so
stufig ist.
Guats Nächtle
Hayo
Hallo Hayo,
macht es ernsthaft Sinn 24 Werte mit Interpolation auf dem Bildschirm
anzuzeigen? Was man da sehen kann ist doch kaum noch aussagekräftig
oder? Ich würd es verstehen, wenn man mit 5GS/s daherkommen würde, dann
kann man auch in den ps-Bereich vorstoßen. Verstehen würd ich es auch,
wenn man nicht real-time, sondern equivalent-time darstellt.
(http://www2.tek.com/cmswpt/tidetails.lotr?ct=TI&cs=Application+Note&ci=14295&lc=EN)
Wie schaut es eigentlich mit der Interpolation aus? Momentan wird doch
noch linear interpoliert, wenn ich das richtig sehe. Sollte nicht die
Sin(x)/x eines der nächsten Ziele sein?
Möglicherweise auch die Wahl zwischen keiner, linear und Sin(x)/x im
Display-Menu. Nur so als Vorschlag.
Beste Grüße, branadic
Also 24 Werte zu interpolieren ist noch im völlig normalen Bereich und
wird von anderen DSO-Herstellern auch angeboten. Zur Zeit verwende ich
eine sehr einfache an die lineare angenäherte Interpolation, die jedoch
bei größeren deltas schlechter wird und Stufen erzeugt. Daher habe ich
sie jetzt durch eine echte Linearinterpolation (nach Bresenham - hatten
wir ja schon in der Line() Funktion) ersetzt - sieht erheblich besser
aus jetzt.
Die Sin(x)/x macht erst Sinn bei erheblich weniger Abtastwerten, da dann
ein natürlicherer Verlauf ohne Ecken interpoliert wird - mit einem
erheblichen Nachteil:
Die Sin(x)/x Berechnung ist sehr Zeitaufwändig, d.h. die Signalausgabe
würde extrem verlangsamt.
Du siehst ich hab mir da auch schon Gedanken in diese Richtung gemacht,
aber die Linearinterpolation ist für diese kleinen Deltas der beste
Kompromiss zwischen akkurater Darstellung und Bildwiederholrate.
Ich stelle gleich mal ein Bild mit dem Signal von Gestern ein allerdings
mit neuer Interpolation, dann hat man den direkten Vergleich.
Hayo
Also ich finde Interpolation in jedem Fall legitim, da es dem Auge dann
in jedem Fall erleichtert wird, den Signalverlauf schnell zu erfassen.
Punktwolken sind da viel schwieriger ;)
Natürlich sollte jeder wissen, was das Gerät gerade macht und wie viel
von den Daten denn nun echt und was interpoliert ist, aber evtl. wäre es
sinnvoll, die tatsächlichen Messwerte z.B. heller darzustellen als die
interpolierten.
Bzgl. der sinc-Interpolation (und auch für den Bresenham) suche ich noch
eine anständige Beschreibung der Mathematik dahinter, habe bisher
zumindest im Netz immer nur Beispielimplementierungen gefunden. Infos
über günstige Hardware-Realisierungen wären natürlich auch toll, aber
die kann ich notfalls auch selbst ersinnen ;) Ich glaube ich muss mal
wieder in die Uni-Bib gehen...
Hallo Hayo,
Crazor schrieb:
> aber evtl. wäre es sinnvoll, die tatsächlichen Messwerte z.B. heller> darzustellen als die interpolierten.
Na also... da haben wir's wieder! Hatte ich das nicht schon vor 4-5
Monaten angeregt? Vielleicht findet sich ja doch noch eine Möglichkeit
der Umsetzung?
Doch noch was Anderes: Hans und Crazor konnten das Problem in unserem
Softcore endlich lösen. Das bedeutet das die Weiterentwicklung des neuen
FPGA Design jetzt in großen Schritten vorwärts gehen kann....FREUDE...
Gruß, brunowe
Hallo,
uih, dann muss ich mich irgendwann auch noch mit dem Altera-Kram
auseinandersetzen.
@ Hayo: der 2-ns-Bereich ist natürlich immer sinnvoll. Auch wenn
er ev. keine weitere Information bietet, erlechtert er unter
Umständen das Kästchen-Zählen. Lass dich nicht beirren.
Gruß, Guido
Nicht falsch verstehen, wollt den Hayo weder bekehren noch beirren. Als
Wissenschaftler liegt es in meiner Natur erst einmal alles in Frage zu
stellen, that's it.
Gruß, branadic
Ist auch völlig korrekt. Man muß nicht alles was machbar ist auch
umsetzen. Die Fragen nach Sinn und Unsinn ist durchaus gerechtfertigt
und stehe dazu auch gerne Rede und Antwort. Es wäre auch nicht das erste
Mal das man sich da in etwas verrennt, das keinen Sinn macht. In diesem
Fall muß ich aber sagen, das es wirklich gut aussieht und hilfreich ist.
Auch die anderen interpolierten Bereiche profitieren von der neuen
Interpolationsroutine, sieht schon deutlich besser aus.
Foto kommt gleich.
Hayo
...für Guido das Ganze bei 100mV an 1/10 Tastkopf.
Man kann deutlich den zusätzlichen Schwinger erkennen der anscheinend
von der Eingangsstufe erzeugt wird.
Hayo
Bruno We schrieb:
> Doch noch was Anderes: Hans und Crazor konnten das Problem in unserem> Softcore endlich lösen. Das bedeutet das die Weiterentwicklung des neuen> FPGA Design jetzt in großen Schritten vorwärts gehen kann....FREUDE...
Ok, eigentlich wollte ich die Ankündigung zusammen mit der Herausgabe
eines neuen Testdesigns machen, aber wenn's nun schonmal soweit ist,
vielleicht noch ein paar Informationen:
Das Problem war ja, dass die ZPU, die wir als Softcore einsetzen,
partout nicht aus dem SRAM heraus booten wollte. Lesen/Schreiben bei
Programmausführung aus dem FPGA-internen Blockram war allerdings OK.
Letztlich hat Hans durch viel Simulation einen Bug in der ZPU entdeckt,
der bei Back-To-Back-Writes auf langsamere Speicher zum Überspringen von
Instruktionen führte. Der Bug ist mittlerweile behoben.
Aktuell gibts also das altbekannte Slog-Design mit einem Open Source
Softcore (statt des NIOS, den wir ja nicht ohne weiteres nutzen dürfen),
der die Benutzerschnittstelle implementiert. Die Signalerfassung und
-darstellung erfolgt also nach wie vor ausschließlich in Hardware, der
Softcore legt quasi die Benutzerschnittstelle mittels eines
Zeichengenerators oben drüber. Der Prozessor führt anfangs einen
Bootloader ähnlich dem GERMSmonitor aus, der es erlaubt, die Software
aktuell per serieller Schnittstelle zu übertragen (später wird die
Software dann aus dem Flash geladen werden können, aber den rühren wir
bisher noch nicht an).
Da die Softwareentwicklung bis zur Behebung des Bugs nicht wirklich
voranschreiten konnte (so ein FPGA hat verdammt wenig Blockram), habe
ich in der Zwischenzeit große Teile der Signalerfassung neu geschrieben,
da Slogs Code doch etwas schwer nachvollziehbar war (hauptsächlich die
Signalbenennung war sehr unintuitiv, was ich mal auf die Sprachbarriere
schiebe, außerdem keine Hinweise über Unzulänglichkeiten der aktuellen
Implementierung usw.). Die Signaldarstellung liefert nun
nachvollziehbare Time Bases, der Downsampler ist neu geschrieben und ein
neuer Trigger ist im Ansatz vorhanden.
Ich hoffe, in den nächsten Tagen eine Programmierdatei zum "Spielen"
veröffentlichen zu können, damit man sich ein Bild vom aktuellen Zustand
machen kann.
Viele Grüße
Daniel
Ok, hier ist sie die Wochenend Beta.
Diesmal habe ich viele kleine Baustellen beackert. Gleich vorweg, die
FFT ist noch nicht dabei, ich wollte erstmal weiter aufräumen.
Dafür sind für Bruno gleich zwei Sachen dabei ;-)
- bei der Umschaltung des Zeichenmodus wird jetzt ein Popup angezeigt
- bei interpolierten TB werden im Pixelmodus die interpolierten Werte
unterdrückt und nur die echten Werte angezeigt
Weiterhin gibt es Folgendes:
- die neue TB 2ns (wie angekündigt)
- ich habe die Steuertabellen für den Triggeroffset korrigiert. Für TB
5nS und 2nS wird jetzt korrekt getriggert
- geändertes Scrollverhalten für Pretrigger und Memorybrowsing für
komfortableres Bedienung (sonst kurbelt man sich ja nen Wolf)
Spaßeshalber hatte ich bei der Interpolation mal die alte
FIR-Interpolation von vorher eingebaut - gruselig. Könnt Ihr ja mal mit
der originalen FW vergleichen :-)))
Viel Spass
Hayo
Oh, ich sehe gerade es ist mir noch ein kleiner Bug im
Testsignalgenerator auf Kanal 3+4 durchgerutscht. Kommt weil ich auf dem
2022A getestet habe. Ich reiche morgen ein Update nach.
Hayo
Noch eine kurze Meldung Hayo...
Die ADC werden aktuell offensichtlich sequentiell ausgelesen, weswegen
es eine zeitliche Verschiebung zwischen den Kanälen gibt, legt man an
alle Kanäle das gleiche Signal. Hier wäre eine zeitliche Kompensation
notwendig. Angenommen man schaut sich verschiedene Signale einer
Testbench an, dann sollte allen der gleiche zeitliche Nullpunkt zugrunde
liegen, um eine Aussage treffen zu können. Ließe sich das in einer
zukünftigen FW hinzufügen?
Hier hat das neue FPGA-Design klare Vorteile, da gibt es "keine"
zeitliche Verschiebung zwischen den Kanälen, da die ADC der einzelnen
Kanäle parallel ausgelesen werden.
Beste Grüße und guten Morgen ;)
branadic
Oh
und ich dachte schon, ich bin der Einzige, dem sich der Nutzen der
Testsignale nicht schließt. Kann man ja auch gleich ein paar Animationen
zeigen. Praktischer fände ich eine Selbstdiagnose oder einen
automatischen Nullinien/ADC/DAC Abgleich durch alle Bereiche...
Heute habe ich endlich auch meinen USB-Seriell Adapter zum Flaschen zum
Laufen gebracht: Ich hatte das serielle Kabel dazwischen immer
weggelassen. So kann's kommen ;-)
Die Signale sehen jetzt wirklich deutlich besser aus, gerade in den
starken Vergrößerungen ... Die Firmware macht wirklich große
Fortschritte.
Jetzt muss ich nur noch in den FPGA kommen...
Michel
Zum Testsignal:
Ich hatte ja schon mal geschrieben wofür man das gebrauchen kann. Es
handelt sich nicht nur um bunte Bildchen, sondern an der Stelle wo sonst
die Signale aus dem ADC-Register gelesen werden, generiert der
Testsignalgenerator Ersatzwerte. Für den Rest der Firmware ist es also
genauso als wäre das Signal aus dem ADC ausgelesen worden. Man kann
damit z.B die Cursorfunktion testen, die QM-Funktion, die
Autoscalefunktion, die Übertragung zum PC und so weiter. Unter Anderem
hatte ich den Generator auch geschrieben um die FFT zu Testen, da ein
sauberes Testsignal die Möglichkeit gibt genau zu kontrollieren ob die
FFT korrekt arbeitet. Beim direkten Vergleich zwischen Testsignal und
realem Signal kann man z.B. sehen ob man am ADC ein Interleaving-Problem
hat.
Zum Auslesen der ADC:
Das die ADC zeitlich versetzt ausgelesen werden ist völlig egal. Wichtig
ist nur, dass sie parallel die Signale abtasten. Wenn dann der AQU_READY
Interupt ausgelöst wird ist das quasi wie ein Schnappschuß dieses
Zeitpunkts der in den ADC-Puffern liegt. Ob die dann gleichzeitig
ausgelesen werden oder nicht ist dann unerheblich, ein gemeinsames
Signal liegt dann auf jeden Fall im gleichen Nullpunkt.
Hayo
Hallo Hayo,
danke für deine Erklärung zu beiden Themen. Wie aber erklärst du dir
dann den zeitlichen Versatz zwischen den Kanälen, der ja nicht ganz
unerheblich ist? Oder bin ich der einzige bei dem das so ist?
Gruß, branadic
Also der zeitliche Versatz ist mir noch nicht aufgefallen. Müßte ich mir
mal genauer ansehen, gebe aber zu dass ich da außer bei der
XY-Darstellung noch kein so großes Augenmerk drauf gelegt habe.
Sollte es tatsächlich einen zeitlichen Versatz geben, so ist das jedoch
nicht auf das zeitlich versetzte Auslesen zurückzuführen, vielmehr gibt
es hier zwei andere Erklärungen:
- die Signalwerte werden in der falschen Reihenfolge aus dem Buffer
gelesen
- die Hardwareansteuerung der ADC ist falsch ausgelegt. Theoretisch
sollten jeweils die korrespondierenden ADC auf einer Taktflanke liegen
-> (Channel.ADC) 1.1/2.1/3.1/4.1 und 1.2/2.2/3.2/4.2 usw.
Wenn das nicht richtig umgesetzt wurde hat man natürlich einen
zeitlichen Versatz - das wäre allerdings ziemlich übel.
Gruß Hayo
Hayo W. schrieb:
> - die Hardwareansteuerung der ADC ist falsch ausgelegt. Theoretisch> sollten jeweils die korrespondierenden ADC auf einer Taktflanke liegen> -> (Channel.ADC) 1.1/2.1/3.1/4.1 und 1.2/2.2/3.2/4.2 usw.> Wenn das nicht richtig umgesetzt wurde hat man natürlich einen> zeitlichen Versatz - das wäre allerdings ziemlich übel.
Das wäre garnicht so übel wie es scheint. Von nichtdeterministischem
Verhalten mal abgesehen wäre so der Fehler ein für alle Mal bestimmbar
und aus der Welt schaffbar. Wenn es am Auslesecode-Timing läge, dann
müsste man den Versatz nach jeder Änderung der Ausleseroutinen erneut
anpassen.
Hallo,
also Hayo es gibt definitiv einen zeitl. Versatz. Bei meinem Scope
beträgt dieser delay ziemlich genau 7ns. Ch2 ist immer um diesen Versatz
"später dran", unabhängig von der gewählten TB und vom Signal. Man kann
diesen Versatz sogar mit dem internen 1kHz Rechteck entdecken, wobei da
evtl. unterschiedl. Probes zu Verfälschungen führen (untersch.
Flankensteilheit).
Bei höherfrequenten Signalen ist dieser delay natürl. noch
augenfälliger.
wäre interessant ob dieser delay bei jedem 7ns beträgt, oder ob's da
Unterschiede gibt. Evtl. können wir da auch einen SW- Abgleich dafür
basteln, bzw. diesen delay von vornherein rausrechnen.
Im neuen VHDL Design tritt dieser delay nicht auf. Also liegt es wohl
entweder am Welec VHDL, oder doch an der SW.
Gruß, brunowe
No sorry,
so genau kann ich nicht messen. Schon 1 m Kabel bedeutet ja
ca. 6 ns Verzögerung.
@ Hayo: Was ganz interessantes: die Grafik bremst garnicht so
stark wie befürchtet. Bei meinen Spielereien habe ich durch
Programmierfehler schon knapp Screens/s geschafft. Ich glaube
ich werde mal timebase in READADC_ALL genauer auswerten.
Gruß, Guido
@Guido
Na wenigstens sind die ausgelieferten Tastkopfkabel gleich lang! ;-)
@Hayo
Hatte gestern irgendwie Probleme mit dem Ch3 und der
Vertikalauflösung/Verstärkungsumschaltung. Habe deshalb in der SW
gesucht und in der Funktion "Hardware::SetSwitches(..)" eine
Unregelmäßigkeit gefunden: Entweder stimmen die Adressen oder die
KOmmentare? Ch3 tanzt aus der Reihe! Vielleicht hast Du dort schon
"tiefer gebohrt". Scheint aber trotzdem zu funktionieren?!
Gruß,Jürgen
Hallo,
ich habe mal die Kanäle meines W2014A mit den mitgelieferten Tastköpfen
und den Signalen eines 10 MHz und eines 25 MHz Quarzoszillators
vergliechen. Bei mir ist Kanal 2 8ns hinter Kanal 1, Kanal 2 4 ns hinter
Kanal 3 und Kanal 4 3 ns hinter Kanal 3.
Auch das Vertauschen der Tastköpfe hat nichts geändert.
Gruß Kristian
Hallo,
> Na wenigstens sind die ausgelieferten Tastkopfkabel gleich lang! ;-)
DANKE Jürgen - das war Guido offensichtlich nicht bewusst ,-)
Man kann also auf jeden Fall nen Trend erkennen. Scheint also überall
so, das Ch2 ca. 6- 10ns hinter Ch1 liegt. (und ggf. Ch4 hinter Ch 3)
Mal sehen was wir diesbzgl. noch für Erkenntnisse gewinnen (VHDL oder
SW- Problem)
Gruß, brunowe
Hallo,
ich fürchte, ich muss noch deutlicher werden: Bei einem
Eingangswiderstand des Tastkopfes von 1 MOhm diskutiert ihr
über eine Kapazität von ca. 10 fF. Macht das wirklich Sinn?
Gruß, Guido
Hmm,
wenn ich das hier so lese (ohne selbst nachgemessen zu haben - muß ich
mal nachholen) dann scheint es ja tatsächlich ein Timingproblem bei der
ADC-Ansteuerung zu geben, oder unser WELEC-Programmierer hat einen
kapitalen Bock beim Sortieren der ADC-Werte geschossen (also einer von
den Jungs hat sich da jedenfalls nicht mit Ruhm bekleckert).
Eigentlich müßte das ja im XY-Modus zu sehen sein, denn der
Laufzeitunterschied verursacht ja eine Phasenverschiebung die sich dann
als Oval (bei Sinus) zeigen müßte wenn man auf beide Eingänge das
gleiche Signal legt - schon ausprobiert?
Zur Zeit kämpfe ich selbst mit einem Stack-Overflow oder einem
Buffer-Overflow in der FFT und bin deswegen nicht so richtig in Stimmung
das ADC-Timing zu prüfen, aber interessieren würde es mich ja schon.
Übrigens wenn die FFT durchläuft sieht es schon richtig gut aus, war
zwischendurch schon mal am überlegen ob ich einen Screenshot einwerfe -
mußte dann aber zugunsten eines Besuches beim Griechen verzichten.
Gruß
Hayo
Hallo,
nein Guido, wir sprechen nicht von 10fF. Wir sprechen von einem delay
von 7ns welche uns ein tiefer gehendes Problem (wo auch immer das
steckt) offenbart. Da es keinen technologischen Grund für so eine
Verschiebung gibt (unser VHDL zeigt das es auch ohne delay geht),
sollten wir doch versuchen dieses Problem auszumerzen. Evtl. erledigt
sich damit auch noch das Ein oder Andere? Die Oszillation bei höheren
Frequenzen z.B.- das konnte ich ja im VHDL auch nicht nachweisen.
Gruß, brunowe
Hallo,
Auch ich kann den Versatz von ca. 8..10ns mit der SW von hayo
nachvollziehen (Tastkopf unabhängig). Wenn ich zu der FW 1.3 zurück gehe
ist der Versatz weg! Scheint also ein SW problem zu sein.
Martin
> Auch ich kann den Versatz von ca. 8..10ns mit der SW von hayo> nachvollziehen (Tastkopf unabhängig). Wenn ich zu der FW 1.3 zurück gehe> ist der Versatz weg! Scheint also ein SW problem zu sein.
Ich meine mich auch zu erinnern, dass ich mal (Google Sprachtools sei
dank) im russischen Forum eine Diskussion über Phasenverschiebungen
zwischen den Kanälen gesehen habe. Die Quintessenz damals war dass es
zwischen 1+2 und 3+4 keine gibt, aber zwischen 2+3 ein kleiner
"Restoffset" vorhanden war. Vermutlich ist also in der Originalfirmware
wirklich schon eine Kompensation der Verzögerungen drin gewesen und
(möglicherweise im Zuge der Umstellung auf die in C geschriebenen
ADC-Routinen?) verloren gegangen.
Da gibt es jetzt wieder mehrere Möglichkeiten:
- Stefan hatte die Assemblerroutinen wegen der Invertierung und der
Averageberechnung geändert. Die Änderungen sind seit der 0.63 aktiv.
Wäre interessant ob bei den davor liegenden FW-Versionen auch dieser
Versatz auftritt.
- Eine weitere Möglichkeit ist die Grafikroutine. Ich hatte ja die
Graphikroutinen komplett neu geschrieben, weil das Ganze ein so kruder
Haufen unüberschaubarer Codeaneinanderreihungen war, dass eine Wartung
völlig unmöglich war. Es ist durchaus möglich, dass da versteckt hart
codiert eine Korrektur drin war die den zeitlichen Versatz wieder
geradegebogen hat (von hinten durch die Brust ins Auge quasi).
Auch das läßt sich prüfen indem man eine Uraltversion testet. Ich hab
mal die 0.17 angehängt, da sind noch die alten Routinen aktiv.
Ich bin z.Zt. in der Firma und komme nicht zum Testen, aber vielleicht
hat ja einer von Euch die Gelegenheit.
Hayo
Ich glaube nicht, dass es mit den Assemblerroutinen zu tun hat. Außerdem
ist dort auch nichts versteckt, was einen Delay erzeugt oder ausgleicht.
Ich tippe auf einen Bugfix, der ab der 1.3er FW das Delay ausgleicht. Da
wir ja von der 1.2er ausgehen wird er da wohl noch nicht enthalten sein.
Ist eigentlich gerade jemand dabei die "Quick Measurment"-Funktionen zu
überarbeiten? Sonst schau ich da mal drüber.
Stefan
In der 0.48 sind auch schon die neuen Grafikroutinen aktiv. Zwischen
0.28 und 0.33 habe ich die wesentlichen Routinen umgestellt.
Anbei die Ausgangsversion 1.2.AF von Andreas Fellnhofer. Damit könnte
man nochmal testen.
Gruß Hayo
Grundsätzlich besteht natürlich die Möglichkeit eine solche Korrektur in
unsere Open Source FW mit einzubauen. Dazu müßte man das aber genauer
untersuchen und folgendes klären:
- welche Kanäle sind betroffen?
- ist es immer der gleiche Laufzeitunterschied oder variiert das von
Gerät zu Gerät?
- gibt es Unterschiede zwischen den 2 Kanalgeräten und den 4
Kanalgeräten?
@Stefan
Also ich komme erstmal noch nicht dazu die QM und Cursorroutinen zu
korrigieren, da ich erstmal die FFT fertigmachen möchte bevor ich mich
an die Bugliste mache.
Außerdem wollte ich dann die Cursor gleich für die FFT erweitern.
Wenn Du da weiterkommst ist das doch schon mal ein großer Fortschritt.
Hayo
Jürgen schrieb:
> Hatte gestern irgendwie Probleme mit dem Ch3 und der> Vertikalauflösung/Verstärkungsumschaltung. Habe deshalb in der SW> gesucht und in der Funktion "Hardware::SetSwitches(..)" eine> Unregelmäßigkeit gefunden: Entweder stimmen die Adressen oder die> KOmmentare?
Ja solche Unregelmäßigkeiten finden sich in der originalen Source zu
Hauf. Da scheint an etlichen Stellen einfach mit verschiedenen Werten
experimentiert worden zu sein und dann wurde das einfach vergessen.
> Ch3 tanzt aus der Reihe! Vielleicht hast Du dort schon> "tiefer gebohrt". Scheint aber trotzdem zu funktionieren?!
Nein, da war ich noch nicht dran, wenn Du da Hinweise findest immer her
damit.
Hayo
@hayo
Ok die Version geht (kein Vergleich zu den fortschritten die du gemacht
hast!)
In dieser Version ist bei mir der Versatz besser (Kanal 2 ca. 2ns
voraus, vorher war Kanal 2 ca. 8..10ns hinterher!)
Vermutlich wurde da wirklich was in den Grafik-Routinen korrigiert.
Martin
Eine Korrektur würde sich dann ja als Ergänzung für Guidos C-Routinen
anbieten. Hier müßte dann abhängig von der Time-base der Array-Index des
betroffenen Kanals mit einem Offset versehen werden.
Bei 8nS wäre das in den 1GSa/S Bereichen ein Index-Offset von 8, in den
500MSa/S Bereichen ein Index-Offset von 4 usw.
Gruß Hayo
Hallo liebe Gemeinde,
auch wenn es ein kurzer Themenbruch ist, so denk ich doch, dass er hier
am besten platziert ist.
Ich hatte heute ein sehr informativess Gespräch mit einem Mitarbeiter
von Altera. Die "NIOS-Lizenzfrage" ist geklärt. Demnach gibt es seitens
Altera keinen Grund dafür, dass Wittig/Welec seine FPGA-Sourcen nicht
veröffentlicht. Der Embedded Softcore liegt nicht in Form von Sourcen,
sondern einer Netlist vor und ist damit für uns quasi nicht brauchbar.
Einziger Grund die Sourcen nicht zu veröffentlichen besteht also seitens
Welec selbst, dass sie ihren Sourcecode schlichtweg nicht hergeben
möchten.
Weitere Einzelheiten des Gespräches kläre ich dann in den nächsten Tagen
mit Bruno und Daniel.
Beste Grüße,
branadic
Wenn wir das FPGA-Design von WELEC bekämen hätte das natürlich den
Vorteil, das wir das vorhandene Design in kleinen Schritten verändern
könnten und dann auch gleich FW-Seitig nachziehen könnten. Dann hätten
wir nicht so einen abrupten Übergang und es gäbe für die geänderten
FPGA-Designs auch immer eine passende FW.
Das könnte interessant werden, aus zwei Richtungen parallel zu
entwickeln.
Gruß Hayo
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang