Forum: Mikrocontroller und Digitale Elektronik Wittig(welec) DSO W20xxA Open Source Firmware


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Peter (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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).

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

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

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von André (Gast)


Lesenswert?

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é

von Gast (Gast)


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

@Andre
PreTrig im Edge-Menü schon ausprobiert?

von branadic (Gast)


Lesenswert?

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

von André (Gast)


Lesenswert?

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é

von Stefan (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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

von Michael (nocheiner) (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@Stefan

Komme vor morgen nicht zum Testen - sorry

Hayo

von Roberto (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Blue F. (blueflash)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

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.

von Stefan E. (stefan_e)


Lesenswert?

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.

von branadic (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Stefan (Gast)


Lesenswert?

>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.

von Blue F. (blueflash)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Roberto (Gast)


Lesenswert?

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)

von Stefan E. (stefan_e)


Lesenswert?

>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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

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.

von branadic (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Johannes S. (demofreak)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Blue F. (blueflash)


Lesenswert?

@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

von Johannes S. (demofreak)


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Guido (Gast)


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

>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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Michael W. (slackman)


Lesenswert?

@ 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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

@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.

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

@ 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

von Stefan (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

Oops,

sorry in der Beta 0.68 gefunden.

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Im Anhang ein BackUp vom FPGA eines W2024A mit Hardware 8C7.C9 und 
Firmware 1.4.
Die Checksumme ist 0706BCDF.

von Blue F. (blueflash)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

Danke Kurt,
werde ich am Montag mal mit rumspielen.

Die Checksumme wird dann auch nachgeliefert.

von Roberto (Gast)


Lesenswert?

Hallo
Wie wird die Checksumme ermittelt?
Wie kann man die Daten in die Liste eintragen ?
l.G. Roberto

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Michael W. (slackman)


Lesenswert?

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

von Michael W. (slackman)


Lesenswert?

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

von André (Gast)


Lesenswert?

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

von Kurt B. (kurt)


Lesenswert?

Hallo Michael,
bitte poste nochmal deine genau Vorgehensweise.

http://apps.sourceforge.net/trac/welecw2000a/wiki/USBBlaster

Ich nehme an, diese Seite kennst du. Nach welchem Schritt tritt das 
erste Problem auf?

von branadic (Gast)


Lesenswert?

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

von Kurt B. (kurt)


Lesenswert?

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 ;-)

von branadic (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Michael W. (slackman)


Lesenswert?

@ 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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Michael W. (slackman)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.

von Guido (Gast)


Lesenswert?

>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

von Michael W. (slackman)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Guido (Gast)


Lesenswert?

@ 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

von Guido (Gast)


Lesenswert?

@ 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

von Blue F. (blueflash)


Lesenswert?

@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

von Guido (Gast)


Lesenswert?

@ 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

von Blue F. (blueflash)


Lesenswert?

Warum hast Du eigentlich die Funktion EXTRACTADCVAL() umgesetzt? Die 
wird nirgends verwendet, und ich habe sie jetzt auch komplett 
rausgelöscht.

Hayo

von Guido (Gast)


Lesenswert?

>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

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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

von Michael W. (slackman)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Michael W. (slackman)


Lesenswert?

... 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

von Guido (Gast)


Lesenswert?

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

von Michael (Gast)


Lesenswert?

@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

von Stefan E. (stefan_e)


Lesenswert?

@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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

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

von Crazor (Gast)


Lesenswert?

@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...

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

...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

von Crazor (Gast)


Lesenswert?

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!

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@Crazor

Schon den WELEC-Updater von Marcus als Not-Fallback probiert?

Hayo

von Blue F. (blueflash)


Lesenswert?

@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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Kurt B. (kurt)


Lesenswert?

Hallo Hayo,
in ramloader.bat und flashloader.bat fehlt das -w

von branadic (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Crazor (Gast)


Lesenswert?

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?

von Blue F. (blueflash)


Lesenswert?

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

von Johannes S. (demofreak)


Lesenswert?

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

von Odic X. (odic)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Odic X. (odic)


Lesenswert?

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

von michaelk (Gast)


Lesenswert?

So, hier meine Daten:

W2024A - HarwareRev 1C9.0L - 1.2BF0.68 - ausgeliefert mit SoftwareRev 
1.4
Bis auf Kanal 3 alle OK

von Martin H. (martinh)


Lesenswert?

@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

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

Achso Odic X.,

ganz vergessen: Möge die Macht mit dir sein. ;-))

Gruß, Guido

von Odic X. (odic)


Lesenswert?

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

von Johannes S. (demofreak)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von odic (Gast)


Lesenswert?

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

von odic (Gast)


Lesenswert?

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...

von Guido (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von odic (Gast)


Lesenswert?

> 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...

von Stefan E. (stefan_e)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Odic X. (odic)


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

Hm, irgenwie wollte er die Datei nicht...

also hier nochmal

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Gibts doch nicht, ich nehme mal einen anderen Browser, scheint am 
Sicherheitszertifikat zu liegen.

Hayo

von Kurt B. (kurt)


Lesenswert?

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!

von Michael W. (slackman)


Lesenswert?

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

von Kurt B. (kurt)


Lesenswert?

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. ;-)

von Blue F. (blueflash)


Lesenswert?

@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

von Kurt B. (kurt)


Lesenswert?

Die Zusage dass ich das Gerät behalten kann habe ich erst vorgestern 
bekommen.

von Crazor (Gast)


Lesenswert?

@Kurt: Die Zusage kann ich geben ;) Hat jemand Interesse an meinem 
2012A?

von Michael W. (slackman)


Lesenswert?

@ 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

von Crazor (Gast)


Lesenswert?


von Blue F. (blueflash)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Kurt B. (kurt)


Lesenswert?

@Crazor,
kann ich das schon als konkretes Interesse deuten? Wenn ja, schicke mir 
bitte eine PN damit wir die Details klären können.

Mfg,
Kurt

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Guido (Gast)


Lesenswert?

Hallo Hayo,

Timebase = 0 ist also auch vergeben? ;-)

Wie sieht das mit 1 V/div aus?

Gespanntes Abwarten, Guido

von Blue F. (blueflash)


Lesenswert?

Das möchtest Du nicht sehen...

Hayo

von branadic (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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...

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hier mal das bekannte 64 MHz Signal von gestern - alle Einstellungen 
gleich.

Ich finde es ist schon ein deutlicher Unterschied.

So und im nächsten...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...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

von Cra Z. (crazor)


Lesenswert?

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

von Kurt B. (kurt)


Lesenswert?

Das 2024 ist schon verkauft. Da war der Preis wohl doch zu niedrig. ;-)

von Guido (Gast)


Lesenswert?

>Da war der Preis wohl doch zu niedrig. ;-)

Sehr ärgerlich. :-))

Hast du etwa eine Geschäftsidee entwickelt?

Gruß, Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

Ach ja, einen hab ich noch,

für den Testsignalgenerator habe ich unterstützung für Signalkopplung
(AC/DC/GND) eingebaut.

Hayo

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok Fehler schon gefunden, war nur ein falsch gesetztes Semikolon.

Daher jetzt schon das Update

Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

kurze Frage, welchen Nutzen haben die Testsignale eigentlich? Sind ja 
keine Signale, die am ADC anliegen. Daher die Frage.

Gruß, branadic

von branadic (Gast)


Lesenswert?

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

von Michael W. (slackman)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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.

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

Bei mir hängt Ch2 immer ca 9ns hinten dran. Bei Vertauschen der Probes 
kommts das gleiche raus.

Gruß,
Stefan

von Jürgen (Gast)


Lesenswert?

Hallo zusammen,

Ch1 ist ca. 10ns voraus, Ch2-Ch4 sind etwa gleichauf.

Gruß Jürgen

von Guido (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

Nachtrag: knapp 20 Screens/s.

Uups, Guido

von Jürgen (Gast)


Lesenswert?

@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

von Kristian T. (krissy1983)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Martin H. (martinh)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

> 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.

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

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

von Martin H. (martinh)


Lesenswert?

@hayo

Vermutlich hat Stefan recht, leider hängt die 0.17er Version bei mir 
(W2012A) aber bei der 0.48 ist der Versatz schon drin.

Martin

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Martin H. (martinh)


Lesenswert?

@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

von Blue F. (blueflash)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Kurt B. (kurt)


Lesenswert?

Hat denn schon jemand bei Welec nachgefragt? Soll ich das übernehmen?

von Stefan (Gast)


Lesenswert?

Brunowe wollte heute fragen...

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

Das war wie ein Déjà-vu, ich hab heute 5 mal versucht einen von WELEC zu 
erreichen, ohne Erfolg....
Ich bleib weiter dran.

Gruß, brunowe

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.