>Hmm, whats going wrong? Doesn't it start or doesn't it start after>triggering a screen shot? Did You switch to the BF-Version in the Quick>Print menu?>On my Suse Linux 11.1 it works without problems (AMD Mainboard 3 Ghz>direct RS232 connection - no USB-converter)>Hayo
I think it's my problem. Now I'm using a Debian system temporarily when
the computer system reinstall everything and try to determine if my
problem or not.
Using a USB-RS232 converter, I give the command:
w2000 *-c / dev/ttyUSB0
is ok? The program starts but does not appear the text "Waiting for
Screenshot or Trace ..."
Tanks, gyppe :)
Hi gyppe,
for RS232 the start command must be:
./w2000a-screenshot -c /dev/ttyS0 (ttyS1, ttyS2...)
for USB converter:
./w2000a-screenshot -c /dev/ttyUSB0 (ttyUSB1...)
You need to have admin authority when You are calling the screenshot
program to be able to open the port (admin console).
Hayo
Hi Hayo,
Hayo W. schrieb:> Ich hab mal etwas genauer getestet. Das könnte der Gleichspannungsanteil> des Rauschens sein. Der Offset der da auftritt ist abhängig von der> Stärke der Filterung und ist nur maximal so groß wie der Rauschpegel.
Das meine ich mit "nicht bias-frei". Eigentlich sollte der gefilterte
Wert beim Mittelwert des Rauschens liegen (Cursorlinien) und nicht
irgendwelche Gleichspannungsanteile erzeugen...
Der "Gleichspannungsanteil des Rauschens" sollte doch per definitionem
null sein.
Rainer
Hi Hayo,
Hayo W. schrieb:>> Folgendes Schönheitsproblem hat sich da noch aufgetan:>> Nach Signalerfassung (Single) greift die Darstellungsroutine nach einer>> Verkleinerung des Zoom-Faktors unter bestimmten Bedingungen anscheinend>> am Ende auf ungültige Speicherbereiche zu. Das passiert sowohl mit als>> auch ohne Filter.>> Hmm, hat bei mir irgendwie nicht geklappt.
Komisch, bei mir "funktioniert" das sicher.
Ich versuch's nochmal:
1. Signal Probe Comp mit Trig Normal, PreTrig 0.0
2. TB 1 MSa/s 200us/s
3. Single shot oder STOP
4. Pan ganz nach rechts (alles ok, DataShift1.png)
5. TB auf 100us/div (Zoom in, auffällig: PreTrig springt auf -49.9 us))
6. Pan ganz nach rechts (bis auf PreTrig ok, DataShift2.png)
7. TB zurück auf 200us/div (Zoom out), auffällig:
- PreTrig springt zurück,
- am rechten Ende treten die falschen Daten auf,
- angezeigtes Signal liegt ca. 60 us weiter links als bei (4),
DataShift3.png)
8. Pan einen "Knack" nach rechts (angezeigtes Signal springt auf
Ursprungslage (4), Darstellung ok, DataShift4.png)
Die falsche Anzeige läßt sich ohne neue Messung einfach durch TB
Änderung reproduzieren.
Edit: wenn man nach (7) neu mißt (Single bzw. Run) wird auch die
laufende Messung mit den falschen Daten am rechten Ende angezeigt (wie
DataShift3.png)
p.s. Die Screenshots sind unter WinXP mit der OS version gemacht. Hast
du da eine Idee mit der fehlenden Ebene (z.B. Label Softbutton
"Externel")?
Gruß
Rainer
Hi Rainer,
ich jetzt (noch) nicht so der Filterexperte. Ich habe einfach ohne große
Hintergrundrecherche den Algorithmus von Alex implementiert.Warum da die
Filterroutine einen Gleichspannungsoffset erzeugt ist mir auch nicht
ganz klar. Da muß ich wohl mal etwas Tiefenforschung betreiben.
-> Hat einer von den Anderen da eine Idee?
-> does someone know why the IIR-algorithm which is used here produces
DC offset?
Zur fehlerhaften Anzeige:
Ich habe wegen des Fehlers von gyppe und Luc etwas an der
Memory-Steuerung gespielt. Die neue Version gibts nachher. Probier dann
doch mal ob es weg ist. Wenn nicht werde ich da noch mal genauer
nachforschen.
Die OS-Screenshotversion habe ich sowohl in der Firmwar als auch die
PC-Software so übernommen wie sie ist. Da ich nur an der BF-Version
Änderungen vorgenommen habe kann ich da momentan nicht helfen.
@all
hat da evtl. jemand Ambitionen?
Hayo
Hayo, i use sudo, I also tried on a su console does not work. The
program crashes like this:
***************************************
Screenshot V1.6.BF.0
***************************************
|
and does not respond to any commands from the dso.
Can someone please try a distro like debian and confirm whether it works
or not?
I tried the version that bf os 1.6 that both the old 1.1. Also tried
another system with debian / testing certainly well-functioning and
nothing, not even work there.
Can anyone confirm if it works on debian?
maybe be You have to recompile it. So You need gcc on your system. Then
go to Your Screenshot directory delete the old w2000a-screenshot and
type in: make unix. The compilation should run and a new file should be
created.
Hayo
Niente, non riesco a risolvere in nessun modo. Comunque Hayo non
preoccuparti, pensa alle altre cose più importanti. Io temporaneamente
posso anche usare win su virtualbox.
Grazie per l'interessamento :)
No, I can not resolve in any way. Hayo not worry about Anyway, think
about other more important things. I can also use a temporary win over
virtualbox.
Thanks for your interest:)
Ok guys,
now I go making sports and have a nice time in our greek restaurant.
After that I will publish the corrected BF.2.3
German:
Wenn ich vom Sport und vom Griechen wieder da bin gibts die BF.2.3 - da
hat sich einiges getan.
Hayo
Ok, back from greece ;-)
new corrected version BF.2.3
New Memory control.
Das Problem war unter anderem, dass ich von falschen Voraussetzungen
ausgegangen bin.
Ich dachte, dass über alle Zeitbasen 16K Werte zur Verfügung stehen (ich
weiß, in der WELEC Produktbeschreibung steht es drin - aber ich dachte
das ist bestimmt ein Irrtum), aber es stehen tatsächlich ab 10µs - 500ms
nur 4K Werte zur Verfügung. Ich denke dass hier vom 4 ADC-Betrieb auf
Single ADC-Betrieb umgeschaltet wird und jeder ADC hat anscheinend fest
verdrahtet Speicher für 4K Werte zur Verfügung.
Prüft das mal, bei mir sah es erstmal ganz gut aus.
Nevertheless check it out and let me know if it is better now or if
something is going wrong.
Hayo
man kann es gar nicht oft genug sagen, danke.
Mir ist gerade etwas aufgefallen.
Single-Shot Aufnahme 10mSek, langsames Scrollen ist wirklich sehr
langsam wen man die Aufnahme aber mit 5mS oder 2mSek betrachtet geht das
scrollen viel leichter von der Hand. Vielleicht lässt sich die
Mindestscrollgeschwindigkeit erhöhen, liegt wahrscheinlich daran das nur
jeder xte Wert angezeigt wird.
Seht ihr das genauso oder braucht ihr so ein langsames scrollen bei
einer großen Zeitbasis?
@ Hayo
Wow ich komme gar nicht mehr hinterher mit dem Testen der neuen
Versionen - klasse was für Fortschritte da in letzter Zeit gemacht
wurden!
Was den Speicher angeht - war da nicht mal was, dass je nach Zeitbasis
und Abtastrate entweder der interne BlockRam des FPGAs oder der externe
SRAM verwendet wird?
Gruß
Michael
@Thomas
> Single-Shot Aufnahme 10mSek, langsames Scrollen ist wirklich sehr> langsam wen man die Aufnahme aber mit 5mS oder 2mSek betrachtet geht das> scrollen viel leichter von der Hand.
Ja ich weiß. Ich war da gestern auch schon an der Kennlinie dran, habs
dann aber nicht mehr fertig bekommen. Also hab ich erstmal wieder die
alte Kennlinie eingesetzt - ich bin da aber dran. Ich arbeite an einer
variablen Kennlinie je nach Speichertiefe.
@Michael
> Was den Speicher angeht - war da nicht mal was, dass je nach Zeitbasis> und Abtastrate entweder der interne BlockRam des FPGAs oder der externe> SRAM verwendet wird?
Ist mir nicht bekannt, aber ich bin interessiert. Falls sich der Beitrag
oder die Doku noch findet - immer her damit, dann kann ich das mit zur
Geräte und Firmwaredoku packen.
Die beigelegte Exceltabelle habe ich auch schon auf den neuesten Stand
gebracht. Da sind die "neuen" Speichertiefen bereits eingetragen.
Gruß Hayo
Hallo zusammen,
kann der "Pulse Width" Trigger eigentlich auch neg. Pulse detektieren?
Eine Invertierung scheint nicht die Lösung zu sein.
Muß ich den PreTrigger (dessen Verhalten ich immer noch unglücklich
finde) für den Pulsbreiten-Trigger im Edge-Menü ändern?
Viele Grüße,
Rainer
@Mirko
Verd... das war gestern wohl ein Ouzo zuviel. Hab anscheinend vergessen
die Datei mit in den Ordner zu kopieren. Liefere ich nach sobald ich
zuhause bin - sorry.
@Rainer
da fehlt jegliche Implementierung. Das einzige was ich gefunden habe ist
das Symbol für den Softbutton. Die ganze Pulsweitentriggerung ist
ziemlich Stiefmütterlich implementiert - sowohl hardwareseitig, als auch
softwareseitig.
Die Funktion ist leider völlig undokumentiert und daher auch schwer zu
erweitern bzw. nachzurüsten.
Gruß Hayo
ich hätte noch einen Verbessrungswunsch, wenn ich eine Single Shot
Aufzeichnung betrachte und die Zeitauflösung höher stelle also von z.B.
von 10µSek auf 5µSek dann wird mittig in das Signal gezoomt, vielleicht
könnte man die Position eines Signal z.B. Low/High Flanke eines
Rechteckes beibehalten und das Signal nach rechts Strecken, also zoomen
aber das Signal weiter nach rechts schieben.
ich probiere es mal zeichnerisch
vorher: ______|-|_______
nachher:____|-----|_____
gewünscht:____|-----|___
...das finde ich ist ein guter Vorschlag!
Dasselbe Problem tritt manchmal beim zoomen ab 1Gsa/10nS bis 2nS auf.
Die linke Signalflanke(Rechteck) wandert nach links aus dem Bilschirm
und ein "nachholen" nach rechts geht nur begrenzt, d.h. das Ansteigen
der Flanke von links ist kaum noch sichtbar!
Ich hoffe, das ich das Problem verständlich erklärt habe, ansonsten
mache ich mal einen Shot.
Gruß Michael
Aber wie soll das funktionieren?
Mal angenommen, rechts, in der Mitte und Links ist ein Impuls - was
dann?
Oder ein verwaschenes analoges Signal?
Viele Grüße,
Mirko
Es sollte einfach die erste Speicherstelle auch auf dem gezoomten Bild
links angezeigt werden, das Signal also entsprechend nach rechts
geschoben werden so das man beim zoomen kein wanderndes/springendes
Signal hat.
Angenommen Bild besteht von links nach rechts aus
Speicherstelle1, Speicherstelle5, Speicherstelle10, Speicherstelle15
dann sollte es nach dem Zoomen so aussehen
Speicherstelle1, Speicherstelle3, Speicherstelle6, Speicherstelle9
und nicht
Speicherstelle4, Speicherstelle8, Speicherstelle12...
...das sollte so funktionieren, das das Signal beim verstellen der
Zeitbasen auf derselben Stelle bleibt und zum untersuchen einer Periode
nach links u. rechts, weit genug verschiebar ist, oder?
Gruß Michael
@Mirko: Dann sollen die Signal nach rechts aus dem Bildschirm wandern
nicht nach links und rechts.
Also L/H-Flanke linkes Signal soll genau an der gleichen Stelle stehen
bleiben.
Ach so, ich dachte, ihr wollt das irgendwie auf das Signal
synchronisieren (das mit der LH Flanke war da (zumindest für mich) etwas
zweideutig formuliert).
Wenn man das aber so macht, erhält man nicht das Bild von Thomas O.
sondern:
vorher: ______|-|_______
nachher:____|-----|_____
gewünscht:______________________________|-----|_____________________ !!!
dargestellt wir also folglich:________________
Das ist auch der Grund, warum man es so macht, wie es ist - man sieht
das "Ereignis" noch.
Wenn mehr "Inhalt" auf den Schirm ist, könnte das aber eventuell auch
sinnvoll sein - vielleicht kann das Hayo ja als Option einbauen.
Viele Grüße,
Mirko
wie ist das bei anderen Herstellern gelöst, vielleicht hat ja jemand
beruflich viele Oszi unter den Fingern und kann dazu etwas sagen, wie es
die verschiedenen Hersteller praktizieren.
Und dann werfe ich noch etwas hinterher, ich finde die Menüstruktur
etwas umständlich z.B. muss man bei den Noisefiltern mehrmals die
gleiche Taste drücken um zw. verschiedenen Einstellungen zu wechseln.
Ein Menü mit z.b. 5 Scrolloptionen, man befindet sich auf Punkt 2 und
will auf Punkt 1 dann muss man 6 mal die Taste drücken um wieder auf
Punkt 1 zu landen.
Kennt ihr das Bedienkonzept der ältere Beckerradios(weiß nicht obs heute
noch so ist) bei Mercedes. Da wurde bei der Anwahl eines Menüs gleich
alle Einstellungen angezeigt so das man direkt mit dem nächsten
Handgriff das machen kann was man will. z.B. Sound und man erhält - Bass
+ - Treble + - Balance +
Ich habe mal ein Bild angehängt damit man es sich leichter
veranschaulichen kann. Von Menüpunkt 2 auf 1 zu springen benötigt hier
nur eine Tastenbedienung da man nicht alle anderen Menüpunkte
durchwählen muss.
Auch hier würde es mich interessieren wie ihr das bei anderen
Herstellern erlebt.
Jetzt hoffe ich noch das der Aufwand dafür nicht zu groß ist und es
vielleicht irgend wann mal in eine Firmware Einzug findet.
Hallo,
Thomas O. schrieb:> Und dann werfe ich noch etwas hinterher, ich finde die Menüstruktur> etwas umständlich z.B. muss man bei den Noisefiltern mehrmals die> gleiche Taste drücken um zw. verschiedenen Einstellungen zu wechseln.
Die Idee finde ich gut. Die Frage ist, wie man mit Menüs umgeht, bei
denen es mehr als sechs Unterpunkte gibt? Ein Vorschlag könnte sein, die
erste und letzte Taste für's Weiterschalten in z.B. 3er oder
4er-Schritten zu reservieren.
Das würde sich auch als Schrittweitenverstellung bei den
Zeiteinstellungen anbieten. Jetzt wird ja beim Drücken von z.B. ">"-Wert
im Puls-Width Menüe direkt der Wert geändert, während die Schrittweite
anscheinend einem festen Schema folgt, so dass sich sogar einige Werte
gar nicht einstellen lassen.
Hayo W. schrieb:> Das Problem ist, wenn die Schritte zu fein sind, dann kurbelt man sich> eine Wolf, und wenn sie zu grob sind kann man es nicht genau genug> einstellen. Man muß eigentlich die Schrittweite bei jedem beliebigen> Wert frei einstellen können - ich denk drüber nach.
Wenn man beim Drücken nur die Schrittweite ändert (über die temporär
umbelegten Softkeys), aber den Wert beibehält, wäre das Problem gelöst.
Evtl. könnte es praktisch sein, beim Vergrößern der Schritt den Wert auf
einen passenden Raster zu ziehen.
Hayo, vielleicht übersiehst du, ob soetwas ohne Riesenbaustelle machbar
wäre?
Gruß
Rainer
@Thomas
Dein Vorschlag läuft darauf hinaus, dass statt der Pulldownmenüs
vollständige Menüs benutzt werden. Der Sinn der Pulldowns ist es aber zu
viele Menüs zu vermeiden, damit die Struktur nicht so verschachtelt und
unübersichtlich ist.
Du kannst ja mal überlegen wie viele Menüs wir haben, wenn alle
Pulldowns mit <= 6 Einträgen durch vollständige Menüs erstzt werden.
Auußerdem sind in den Pulldowns eigentlich (fast) nur Einstellungen die
nicht ständig geändert werden müssen. Daher kann ich da eigentlich ganz
gut mit leben.
@Rainer
Zu den numerischen Drehgebern:
ich werde da mal was ausprobieren, z.B. bei der Pulsweitentriggerung.
Ich werde mal die Schrittweite heruntersetzen auf zwei Nachkommastellen
und dann eine quadratische oder kubische Kennlinie für den Drehgeber
einsetzen. Vielleicht geht es damit.
Gruß Hayo
...statt den Softbutton für die Auswahl der Noise-Modi, fände ich den
Drehencoder, der auch im Quick-Measure und Probe-Teiler Menu zum Einsatz
kommt, sehr praktisch! Im Aquire-Modus ist Dieser eh' ohne Funktion und
man müsste auch nicht ständig irgendwelche Buttons drücken
Dasselbe fände ich auch im Channel-Delay-Menu angebracht, die immerhin
die Auswahl von 0nS -16nS haben, also 16x Knopp drücken erfordert...
Gruß Michael
Die Pulldown-Menüs können bei z.B. Agilent auch alternativ mit dem
Drehknopf bedient werden. Das geht eigentlich ganz flott von der Hand.
Ist das hier auch so (Hab leider die Software noch nie in Aktion
gesehen)? Wenn nein, wäre das evtl. eine Lösung.
Da wir gerade schon bei Userinterfaces etc. reden:
Die Pulldownmenus finde ich persönlich sehr in Ordnung.
Vielleicht kann man darüber nachdenken, die Auswahl (zusätzlich?) per
Drehgeber treffen zu können und nicht nur über mehrmaliges Drücken der
Taste.
Was mich noch freuen würde:
Im Rahmen meiner Kalibriertätigkeiten für meinen 22Ohm Umbau ist mir
aufgefallen, daß an meinem Oszi sowohl die Lage der Nulllinie (DAC
Abgleich) als auch die Skalenfaktoren von der Betriebsdauer/Temperatur
des Gerätes abhängen. Das ist nervig.
Diese Parameter stehen aber fest im Flash.
Jetzt haben analoge Oszis in der Regel dafür Einstellungsknöpfe an der
Frontseite. Logisch - die haben ja kein Flash.
Trotzdem fände ich es manchmal hilfreich, Nulllinie und vor allem den
Skalenfaktor manuell beliebig verstellen zu können. z.B. um bei
ungünstigen Messbereichen den Screen möglichst gut ausnutzen zu können.
Auf meinem Analog-Scope nutze ich diese Funktion gerne, weil mich
manchmal eher die Kurvenform interessiert, als die konkreten Werte. Dann
läßt sich z.B. die Kurve in Y-Richtung größer ziehen und Details sind
besser erkennbar.
Als Hinweis leuchtet dann eine LED "uncal.", um den User darauf
hinzuweisen, daß die abgelesenen Werte nicht stimmen.
Andere Anwendung dieser Funktion: Feinkalibrierung "im Feld" ohne
flashen zu müssen.
Wäre es möglich, eine solche Einstellmöglichkeit mit in's Menu zu bauen?
Lothar
Hallo Hayo,
Hayo W. schrieb:> Zur fehlerhaften Anzeige:>> Ich habe wegen des Fehlers von gyppe und Luc etwas an der> Memory-Steuerung gespielt. Die neue Version gibts nachher. Probier dann> doch mal ob es weg ist. Wenn nicht werde ich da noch mal genauer> nachforschen.
Hab' ich gemacht. Nach Default Setup und Kalibrierung sieht die Sache
mit dem Datenmüll, wie du erwartet hast, ganz anders aus, ist aber nicht
weg. Beim Zoom in ein erfaßtes Signal ist alles konsisten, aber am Ende
des Tracks wird grundsätzlich etwas Falsches dargestellt. Beim dauernden
Messen zappelt es wie normales Rauschen, ist aber vertikal verschoben
(abhängig von der Vertikalempfindlichkeit) und passt auch vom
Zeitverlauf nicht zu den 1:1 Pulsen vom Prob Comp Signal. Bei Änderung
des Offsets für den Kanal verschiebt sich der Datenschwanz nicht mit.
Gruß
Rainer
Ahh, jetzt hab ich es auch geschafft. Es geht nur im 5er
Spannungsbereich, deshalb hab ich es bisher nicht geschafft das
nachzustellen. Sehr nebulös. Hängt aber nicht mit dem Speicher zusammen
sondern hier werden offensichtlich falsche Werte vom ADC in den Speicher
geschrieben.
Gruß Hayo
Ok hab die Ursache auch schon ausfindig gemacht. Es ist der Pretrigger!
Der Speicherbereich vor und nach dem Trigger wird anscheinend falsch
zusammengesetzt. Wenn kein Triggerereignis eintritt (siehe rote LED)
dann tritt auch das Problem nicht auf.
Hayo
Und zwar nur im 4KB memory mode -> also 10µs - 500ms.
Entweder ich finde eine Möglichkeit das Zusammensetzen zu korrigiern,
oder ich muß ein Stück vom Speicher abknipsen.
Hayo
Rainer H. schrieb:> Muß ich den PreTrigger (dessen Verhalten ich immer noch unglücklich> finde) für den Pulsbreiten-Trigger im Edge-Menü ändern?
Muß du nicht, aber es verschiebt den Signalanfang entsprechen ;-)
Was findest du unglücklich, bzw. wie meinst du, dass der PreTrigger
wirken sollte?
Gruß, Rainer W.
Noch weniger Speicher wäre eine mehr als unschöne Lösung oder nicht,
selbst die Nutzung von nur 4k bei gerade mal 16k pro Kanal ist schon
verschenkt.
branadic
Da kann ich leider nicht helfen, aber es sieht so aus als hätte ich das
Problem im Griff ohne Speicher abzuknipsen. Mal sehen, evtl. gibt es
gleich die aktuelle Version zum Testen.
Hayo
Habs noch fertiggekriegt bevor der gemütliche Teil des Abends anfängt.
Es gibt wieder etliche Änderungen:
- Speicherendeproblem gefixt (hoffe ich - bitte testen)
- neue Drehgeberkennlinien bei Pretrigger und Memorybrowser
- neue Zoomlogik -> wie weiter oben vorgeschlagen bleibt beim TB-Wechsel
die Triggerposition konstant und das Signal wird nach rechts
"rausgeschoben".
- und.... es gibt mal wieder eine neue Funktion! Der bislang ungenutzte
Pretrigger-Softbutton im Edgemenu funktioniert jetzt als "Auto
Pretrigger"
new function "Auto Pretrigger" in the Edge meu when pressing
pretrigger button.
Viel Spaß Hayo
Grazie davvero Hayo, dovrebbero farti santo! :)
Ho trovato un piccolo bug proprio ora, nella modalità delayed rimane lo
stesso errore di visualizzazione errata. Il resto finora mi sembra tutto
perfetto, sembra che ogni versione sia sempre più veloce ora è davvero
un piacere da usare :) SCrivo anche in Italiano perchè non sono sicuro
di farmi capire con il traduttore.
Thank you so much Hayo, should you saint! :)
I found a little bug right now, delayed mode remains the same mistake a
wronged. The rest so far it all seems perfect, it seems that each
version is always faster now it's really a pleasure to use:) I also
write in Italian because I'm not sure myself understood by the
translator.
Hayo W. schrieb:> - Speicherendeproblem gefixt (hoffe ich - bitte testen)
Passiert. Leider noch nicht ganz. Manchmal taucht immer noch Müll auf.
Gerade ist mir aufgefallen, dass das von der PreTriggereinstellung
abhängt.
Gruß
Rainer
Mi sono accorto che accade solo in certe situazioni, specifico meglio il
problema. Il bug compare solo se dalla visualizzazione normale, si mette
in stop, si zooma almeno una volta e poi si passa in modalità delayed.
Succede anche con i filtri disattivati.
Sono stato davvero fortunato a trovarlo! :D
Spero di essere stato di aiuto, ciao Gyppe.
I realized that only happens in certain situations, specifically the
issue further. The bug appears only if the normal view, you put it to
sleep, it zooms in at least once and then switches to delayed. It
happens even with the filters off.
I was really lucky to find it! : D
Hope this help, Gyppe hello.
Hi Rainer,
ich habe eben bestimmt 10min herum gekurbelt, ich kann deinen Datenmüll
nicht nachstellen...
@Hayo
bin begeistert, die ansteigende Flanke vom Rechteck (Prob 1kHz) bleibt
immer schön auf ihrem Platz von...bis 2nS, da wird sich der Thomas aber
freuen, super Arbeit!!! :)
Anbei mal ein paar shots, wie das aussieht
Gruß Michael
For the measurements shown in Datenende_Pretrigxxx.png I started from
Default Setup and neither touched RUN/STOP nor zoomed in nor switched to
delayed.
Rainer
Michael D. schrieb:> ich habe eben bestimmt 10min herum gekurbelt, ich kann deinen Datenmüll> nicht nachstellen...
Merkwürdig. Probe Comp, 500 mV/div, Trig Norm, PreTrig 470us und dann
ganz nach rechts gekurbelt???
Rainer
Altra aggiunta, scusate. Succede avvolte anche senza mettere in stop e
zoomare ma solo se i filtri sono attivi.
Another added, sorry. It happens even without putting it to sleep
wrapped and zoom but only if the filters are active.
By, Gyppe.
gyppe schrieb:> Another added, sorry. It happens even without putting it to sleep> wrapped and zoom but only if the filters are active.
My Noise Filter is set to OFF.
But perhaps we should not dig too deep on this and classify this topic
as nice to have at this level. We just have to keep in mind that
sometimes there is some garbage.
Rainer
Falls jemand Probleme mit gyppes Rückmeldungen hat, kann ich als
Übersetzer einspringen.
@gyppe
Continua a scrivere anche in italiano - così posso tradurre se non
riescono a capirti
Michael
Rainer W. schrieb:
> Merkwürdig. Probe Comp, 500 mV/div, Trig Norm, PreTrig 470us und dann>
Jup, hab' ich, gut der Trigger war der Comb, sollte aber nix
ausmachen...
> ganz nach rechts gekurbelt???
ich habe ganz nach rechts u. links gekurbelt!
>> Rainer
ich finde das jetzt nicht so schlimm u. Lebenswichtig, die Firmware und
die Arbeit von Hayo sind in kurzer Zeit um Einiges gewachsen, da sollten
wir uns nicht an so Kleinigkeiten aufhängen...mich stört das jetzt nicht
unbedingt.
Gruß Michael
Cool, now we are really international - I like it!
Thanks for Your response!
So it may be the problem at the end of the memory depends on the
hardwaresettings (Factory, High Freq etc.) and the voltage range (or the
pretrigger?).
I will try to make it a little bit more stable.
What about the "Auto Pretrigger" function? Do You think it is usefull?
Same in german:
Danke für die Rückmeldungen!
Das Datenschrottproblem am Speicherende hängt wohl auch von den
Hardwareeinstellungen und dem gewählten Spannungsbereich ab (evtl. auch
vom Pretrigger).
Ich arbeite weiter an der Verbesserung.
Wie fandet Ihr die neue "Auto Pretrigger" Funktion? ist das
praxistauglich?
Gruß/regards/ciao
Hayo
Hi Hayo, gyppe, Lothar Merl and guys all!
Hayo You are tireless and very kind, so again thanks You a lot for the
great job and free time
You provided generously to us!!!
I tried the 1.2.BF.2.3 firmware's release and for me it works, gyppe's
bug and my spike's problem are gone.
So great!
Unfortunately now I have little time and I could not thank You Hayo, I
am really very sorry for this, please excuse me if You can.
Unfortunately I could only do a few tests, however seem to me it work
fine.
This evening I tried your new 1.2.BF.2.3 firmware's release and seem to
me it works great also.
For me in this version the goal is constant pretrigger position at
TB-change, very similar to other DSO how I already written in some past
post.
All seem to me it work very fine but I could only do a few tests because
I am Unfortunately busy now.
I will look over the weekend, sorry Hayo for this.
Hayo, You are amazing, RESPECT!!!
@gyppe
Si comprendo italiano con traduttore di google.;-)
Io no problema con Screenshot_1.6BF ma sfortuna io ho Windows XP.
In Screenshot_1.6BF per Windows il gentile Hayo aggiunto campanello su
richiesta mia, è molto utile e funzionare bene!
Scusa gyppe ma non capisco se tu selezionare BF-Version dentro Quick
Print menu, potrebbe risolvere e Screenshot_0.92OS funzionare?
Lothar Merl schrieb:
>Im Rahmen meiner Kalibriertätigkeiten für meinen 22Ohm Umbau ist mir>aufgefallen, daß an meinem Oszi sowohl die Lage der Nulllinie (DAC>Abgleich) als auch die Skalenfaktoren von der Betriebsdauer/Temperatur>des Gerätes abhängen.
Hallo Lothar Merl.
I'm interested in the modified and I am looking information about it.
I understood what I must to do but potential benefits and side effects
are not clear to me.
Why have You used 22ohm's resistors?
33ohm 1% and 150ohm 1% are the best choice I read, am I wrong?
What is the value of the ADC's termination resistance?
What can You say about a possible's resolution loss?
In the Hardware teil I read that to change the resistance increases the
linearity on the frequency but introduces a loss of resolution
Ok the resolution gets worse, but how much?
I guess changing the ADC's resolution also change the resolving's steps
for the ranges so steps become coarse.
Also very interesting the temperature problem, is the first time I read
about it.
Thanks in advance.
Vielen Dank!!!
Gruß Luc
ja Thomas freut sich mit euch allen zusammen.
Was hat das mit dem Auto-Pretrigger auf sich bzw. was soll das bewirken?
Wird hier die Pretriggerzeit automatisch gewählt und wenn ja nach
welchen Kriterien?
@Hayo: Woran liegt es eigentlich das die Aktualisierungsrate des
Bildschirmes so langsam ist, liegt es am FPGA-Design oder an der
Oberfläche an der hier gearbeitet wird und die wahrscheinlich immer
aufwendiger wird.
Hi Hayo and guys all!
Hayo W. schrieb:
>Wie fandet Ihr die neue "Auto Pretrigger" Funktion? ist das>praxistauglich?
@all
Hayo for me is very usefull.
Honestly most of the DSO I've seen it works this way, only the Welec are
using so unusual way, but it's only a matter of philosophy and habits.
Repeat for me top marks!!!
@gyppe.
Hayo, per me è molto utile.
Sinceramente molti dei DSO che ho visto funzionano in questo modo, sono
solo i Welec che usano questo modo insolito ma è soltanto una questione
di filosofia e abitudini.
Ripeto che per me è da massimo dei voti, 10 e lode!!
Vielen Dank!!!
Grazie mille!!!
Thanks a lot!!!
Gruß Luc
Hayo W. schrieb :
> Das Datenschrottproblem am Speicherende hängt wohl auch von den> Hardwareeinstellungen und dem gewählten Spannungsbereich ab (evtl. auch> vom Pretrigger).
Ok, hab den PreTrigger ganz nach links gedreht, da ist dann der
"Datenschrott"
Shot 1
Nach drücken des Softbuttons (Auto?) ist der "Schrott" weg u. der
PreTrigger geht auf 120 nS,
Shot 2
>> Ich arbeite weiter an der Verbesserung.>> Wie fandet Ihr die neue "Auto Pretrigger" Funktion? ist das>> praxistauglich?
...Ich finde das sehr praktisch!!!
@Thomas
>Was hat das mit dem Auto-Pretrigger auf sich bzw. was soll das bewirken?>Wird hier die Pretriggerzeit automatisch gewählt und wenn ja nach>welchen Kriterien?
nach der Betätigung hüpft die 1. Flanke vom Rechteck(1kHz) in die Mitte
des Bildschirms.
Gruß Michael
Luc,
yes, I changed the values of the resistors to 22 Ohm and 150 Ohm.
The recommended value for the smaller resistors is 29.5 Ohm (correct?)
from
the reference design in the datasheet of the OpAmp. Since this value is
hard to find, some of us took the closest value available in the drawer.
24 Ohm, 33 Ohm whatever comes to hand.
This also applies to the 150 Ohm resistor. The reference design utilizes
a 150 Ohm output resistor. In both cases Wittig used 0 Ohms which is
far from optimum.
Measurements proved an increase of linearity after the modification.
On the other hand the gain drops with increasing resistance.
Both values are adjustable in the software. The file in charge is
tc_vars.cpp
ScaleFactor corrects the gain, DAC_ScaleFactor the offset.
Both values influence the other one a little, so an iterative
approximation process is required.
Increasing gain normally leads to a lower resolution during conversion.
In this case the loss is marginal and I think compared with some other
flaws in the Wittig design it doesn't matter at all.
Yesterday evening I watched the temperature drift of my 2024 scope.
The cope had room temperature (abt. 18°C) and I activated only channel
1,
5V scale and moved the GND indicator to the 15V mark.
The readout showed 13.5V on startup and slowly approached the 15V mark
which it reached after quarter of an hour or so.
But: I did some modifications on my scope. The gap between fan and
housing
was closed with tape and every single AD-converter has a tiny aluminum
heatsink on top. Maybe I should remove them and maybe someone else
could please be so kind an check the temperature drift on an unmodified
scope.
Thank's!
Lothar
"Auto Pretrigger"
Some explanations. What does it do and how does I find it?
Kurze Erklärung. Was macht das Ding und wie finde ich es?
- the memory window (displayed in the memory browser) is set to the
start address of the value buffer.
Der für die Anzeige verwendete Speicherausschnitt wird ganz an den
Anfang des Wertespeichers gesetzt
- the pretrigger is set to the screen middle.
Der Pretrigger wird auf die Bildschirmmitte gesetzt
- change to edge menu and press the pretrigger softbutton on which the
pretrigger time is displayed.
Ins Edge Menu wechseln und auf den Pretrigger Softbutton drücken der
sonst nur die Pretriggerzeit anzeigt.
Hayo
Thomas O. schrieb:> @Hayo: Woran liegt es eigentlich das die Aktualisierungsrate des> Bildschirmes so langsam ist, liegt es am FPGA-Design oder an der> Oberfläche an der hier gearbeitet wird und die wahrscheinlich immer> aufwendiger wird.
Da das Thema immer wieder hochkommt werde ich das mal international
abhandeln.
Why is the refresh rate so slow?
1. The performance of the NIOS design is not very high.
Das NIOS design ist schon etwas betagt und nicht sehr performant.
2. Unfortunately the FPGA-Developer at WITTIG Technology choosed a CPU
design without additional multiplying unit. So we have to go a
circuitous way to optimize multiplying performance (scaling, filters,
arithmetic etc.)
Blöderweise hat der FPGA-Entwickler bei WITTIG (Thomas himself??) das
CPU-Design ohne zusätzlichen Multiplizierer gewählt (man kann zwischen
drei Designs wählen). Deshalb müssen wir solche Verrenkungen machen um
die Performance trotzdem noch akzeptabel hinzukriegen.
3. Which functions need most time?
- the graphic part (scaling, drawing, transferring to the screen) is
the performance killer number one. Refresh rate increases with every
channel which is switched off when not needed!
Der Grafikteil frißt die meiste Performance (Skalierung, zeichnen,
Datentransfer zum Screen). Die Wiederholrate steigt mit jedem
abgeschalteten Kanal der nicht benötigt wird.
- second place on the ranking goes to additional arithmetic operations
like Quick Measure or all Mathfunctions especially FFT. Also the
DSP-Unit for interpolation and filtering.
Als zweites wären da die zusätzlichen Berechnungen wie Quick Measure und
alle Math-Funktionen - insbesondere die FFT. Weiterhin die
Signalverarbeitung (Interpolation, Filterung)
- third place goes to ADC-handling (trigger handling, memory readout
etc)
als drittes ist da das ADC-handling (Triggerauswertung, Speicher
auslesen etc.)
Hayo
Grazie Luc, ok allora continuo a scrivere anche in Italiano. Scusate so
che questo è un bug davvero semplice, prima ci sono cose molto più
importanti da fare. Però segnalarli non fa mai male, così in futuro già
si sa dove intervenire.
Hayo, ora su cosa stai lavorando? Provo a tradurre le vostre discussioni
ma il tedesco è molto difficile :)
Ciao, Gyppe.
Thanks Luc, ok then I continue to write in Italian. Yes sorry I know
this is a bug really simple, first there are more important things to
do. But it never hurts to report them, so in the future you already know
where to modify.
Hayo, now what are you working on? I try to translate your discussions,
but the German is very difficult indeed:)
Hello, Gyppe.
Hallo zusammen,
beim Testen der Triggerfunktionen ist mir aufgefallen, dass ich immer
aber nur auf Kanal 1 (sehr schnelle, virtuelle) Spannungseinbrüche sehe,
siehe oben. Ist meine HW kaputt oder woran kann das liegen?
Viele Grüße,
Rainer
Rainer H. schrieb:> Hallo zusammen,> beim Testen der Triggerfunktionen ist mir aufgefallen, dass ich immer> aber nur auf Kanal 1 (sehr schnelle, virtuelle) Spannungseinbrüche sehe,> siehe oben. Ist meine HW kaputt oder woran kann das liegen?
Da bräuchte man zur Beantwortung mehr Details:
- Triggerung
- wo ist das Speicherfenster (ganz am Anfang / ganz am Ende)
- Noise Filter On / Off
- hardwaresettings
etc.
Was hast Du Du denn für einen gruseligen Noise Pegel bei Dir auf dem
Signal.
Du must Deine Kiste mal kalibreren.
Evtl. verschwindet der Effekt mit einer anderen Hardwareeinstellung? Bei
mir ließ sich das nicht nachstellen.
Hayo
Da schon öfter mal die Nachfrage wegen einer Doku hier hochkam habe ich
mal angefangen einige der Sonderfunktionen zu dokumentieren. Ab jetzt
wird diese Doku in aktualisierter Fassung bei den veröffentlichten
Versionen dabeisein.
Hayo
gyppe schrieb:> Hayo, now what are you working on?
On Your reported bugs, the rotation handling and memory handling.
After that I hope to find time to complete the FFT section which is
still under construction.
> I try to translate your discussions,> but the German is very difficult indeed:)
Yes I know, this is the reason why I try to answer in english if it
seems necessary.
ciao Hayo
@Hayo,
danke, dass Du Dich dem Problem annehmen willst.
Beim beiligenden Bild ist der "probe comp" angeschlossen Trigger ist
pos. Flanke, PreTrigger 300µs (auto), Speicherfenster in der Mitte.
Filter ist aus. Welche HW-Setting meinst Du?
Anregung:
Könntest Du nicht beim Screenshot (oder auf Anforderung) zusätzlich eine
Textdatei mit den aktuellen Einstellungen des Scopes speichern? Dann
wären die Fragen leichter zu beantworten.
Viele Grüße,
Rainer
Hayo grazie mille per il documento specialfunctions! E' molto utile sul
serio. Sto scrivendo un documento in Italiano per cercare di raccogliere
tutte le informazioni e fare conoscere il più possibile il welec, così
magari riusciamo a trovare qualche altro bravo programmatore per aiutare
:) Per chi interessa:
https://sites.google.com/site/gyplace/home/elettronica/welec-wittig-w2000-dso-l-oscilloscopio-digitale-open-source>After that I hope to find time to complete the FFT section which is>still under construction.
Questa si che è una bella cosa!!!! Non vedo l'ora! :) E' vero che
riuscirai a implementare anche i marker? Sarebbe davvero fantastico !!!
Ciao, Gyppe.
Hayo thanks for the document specialfunctions! It 's very useful. I'm
writing a document in Italian to try to gather all the information and
then learn as much as possible welec, so maybe we can find some other
good programmer to help:) If you are interested in:
https:
sites.google.com/site/gyplace/home/elettronica/welec-wittig-w2000-dso-l-
oscilloscopio-digitale-open-source
> After that i hope to find time to complete the FFT section Which Is> Still under construction.
Now that's a good notice!! I can not wait! :) It 's true that you will
also implement the marker? It would be really fantastic!
Hello, Gyppe.
Rainer H. schrieb:> Filter ist aus. Welche HW-Setting meinst Du?
Utility -> More -> Hardware
Hier könntest Du bei ADC-setting mal schauen ob das auch bei anderen
ADC-Settings auftritt.
> Anregung:> Könntest Du nicht beim Screenshot (oder auf Anforderung) zusätzlich eine> Textdatei mit den aktuellen Einstellungen des Scopes speichern? Dann> wären die Fragen leichter zu beantworten.
Das ist keine schlechte Idee - ist notiert
Hayo
Hallo,
wäre eine Probe-Kalibration möglich?
Ich erkläre auch kurz wozu die da ist.
Im Zusammenhang mit dem "Poor Man's 500 MHz Active FET Probe mit OPA659"
(http://welecw2000a.sourceforge.net/docs/Hardware/Aktiver_Tastkopf_mit_OPA659.pdf)
ist heute mein P6205 gekommen. Das ist ein Aktiver FET-Tastkopf mit
750MHz, der mir als Referenz dienen sollte.
Kurz an mein TDS5104B gehängt musste ich feststellen, dass der einen
nicht unerheblichen DC-Offset aufwies. Jedoch gibt es ein Menu im Scope
in dem man den Tastkopf für jeden Kanal (Gerätemeldung: Gerät sollte
seit mind. 20min laufen) kalibrieren kann.
Dazu legt man ebenfalls das Probe-Signal des Scopes auf den Eingang des
Tastkopfs. Nach dem Abgleich war der Offset dann weg und es kam eine
"Pass" Meldung.
Man kann dann jederzeit hergehen und die Kalibration des Tastkopfes am
Kanal zurücksetzen oder den Tastkopf wechseln und erneut kalibrieren.
Das hat nichts mit dem Tastkopfabgleich zu tun, wie man ihn mit dem
Kunststoffschraubendreher am Tastkopf selbst durchführt.
Ich kann nicht genau sagen was da noch alles passiert, aber man hört die
Relais in der Eingangsstufe des betreffenden Kanals klicken.
Viel wichtiger ist jedoch die DC-Korrektur. Ließe sich soetwas auch am
Welec nachrüsten?
branadic
Hi branadic,
geht das nicht, wenn du den kurzgeschlossenen Tastkopf bei der
DAC-Kalibrierung angeschlossen lässt? Dann könnte ma sicher
eine Schnellwahl hinzufügen.
Gruß, Guido
Hallo Guido,
der Unterschied ist, dass es sich dabei um eine von der "Eingangsstufe
unabhängige" Kalibration handelt, die also unabhängig von den
allgemeingültigen Kanaleinstellungen auch wieder zurückgesetzt werden
kann.
branadic
Hi Lothar Merl, gyppe, Hayo and guys all!
Lothar Merl schrieb:
>I changed the values of the resistors to 22 Ohm and 150 Ohm.>The recommended value for the smaller resistors is 29.5 Ohm (correct?)>from the reference design in the datasheet of the OpAmp. Since this value>is hard to find, some of us took the closest value available in the>drawer.>24 Ohm, 33 Ohm whatever comes to hand.
Lothar Merl schrieb:
>Correction:>The resistor in the datasheet is 24.9 Ohm (not 29.5 as I said above)
Lothar You are very kind, thanks a lot for the very useful informations!
The fact is I mistakenly thought the line and termination resistance
were determined by the ADC MAX1121 while are determined by the AD8131
OpAmp.
For this reason I could not understand but now I've downloaded the
AD8131's datasheet and everything is clear.
So thank You very much for the help Lothar!
Lothar Merl schrieb:
>Increasing gain normally leads to a lower resolution during conversion.>In this case the loss is marginal and I think compared with some other>flaws in the Wittig design it doesn't matter at all.
OK Lothar, I earnest thought worse.
Better that way!
Lothar Merl schrieb:
>Yesterday evening I watched the temperature drift of my 2024 scope.>The cope had room temperature (abt. 18°C) and I activated only channel>1,5V scale and moved the GND indicator to the 15V mark.>The readout showed 13.5V on startup and slowly approached the 15V mark>which it reached after quarter of an hour or so.
Well, also for this I earnest thought worse, so better that way!
Lothar Merl schrieb:
>But: I did some modifications on my scope. The gap between fan and>housing was closed with tape and every single AD-converter has a tiny>aluminum heatsink on top. Maybe I should remove them and maybe someone>else could please be so kind an check the temperature drift on an>unmodified scope.
Thanks also for this informations, Lothar!
However I believe the heatsinks do not hurt also because are also
suggested in the Hardware Forum
(Beitrag "Re: Wittig(welec) DSO W20xxA Hardware":).
Tape between fan and housing's gap is also suggested in W20xxA
Optimizing Thermal Design on sourceforge.
So for me there should be no problems but I could be wrong!
I'm really sorry because I can not help You with the internal
temperature measurement, so sorry Lothar.
However, I think I read that the 4-channel versions have overheating
problems, seem to me in the Hardware Forum, maybe someone can confirm.
@all
I rewrite the same things in the Italian for gyppe who can be
interested.
@gyppe
Riscrivo le stesse cose in Italiano per gyppe che potrebbe essere
interessato.
Lothar Merl ha scritto:
Ho portato i valori delle resistenze a 22ohm e 150ohm.
Nella guida di progettazione sul foglio tecnico dell'amplificatore
operazionale sono raccomandati valori di 29,5 ohm per le resistenze
(giusto?)
Dato che tale valore è difficile da trovare, alcuni di noi hanno preso
il
valore più vicino che si trovavano nel cassetto.
24 Ohm, 33 Ohm o qualsiasi valore simile a portata di mano.
Lothar Merl ha scritto:
Correzione:
La resistenza nel foglio tecnico è da 24,9 ohm (non 29,5 come ho detto
sopra)
Luc ha scritto:
Sei molto gentile Lothar Merl, grazie mille per le utilissime
informazioni!
Il fatto è che ho erroneamente pensato che le resistenze di linea e di
terminazione fossero determinate dal ADC MAX1121 mentre sono determinate
dall'amplificatore operazionale AD8131.
Per questa ragione non riuscivo a capire, ma adesso ho scaricato il
foglio tecnico del AD8131 e tutto è chiaro.
Quindi ti ringrazio molto per l'aiuto Lothar!
Lothar Merl ha scritto:
L'aumento di guadagno porta normalmente ad una risoluzione più bassa
durante la conversione.
In questo caso la perdita è marginale e credo che sia trascurabile
rispetto ad alcuni altri difetti di progetto del Wittig.
Luc ha scritto:
Va bene Lothar, io pensavo seriamente peggio.
Meglio così!
Lothar Merl ha scritto:
Ieri sera ho guardato la deriva termica del mio oscilloscopio 2024.
La temperatura ambiente era di circa 18 °C e ho attivato solo il canale
1, ho impostato la scala a 5V e portato l'indicatore di GND sulla linea
di riferimento dei 15V della griglia.
La lettura ha mostrato 13.5V all'avvio e si è avvicinata lentamente
alla linea di riferimento dei 15V che ha raggiunto dopo circa un quarto
d'ora.
Luc ha scritto:
Bene, anche per questo pensavo seriamente peggio, tanto meglio così!
Lothar Merl ha scritto:
Però ho fatto alcune modifiche al mio oscilloscopio.L'apertura tra la
ventola e il contenitore è stata chiusa con nastro e ogni singolo
convertitore AnalogicoDigitale ha un piccolo dissipatore di calore in
alluminio sulla parte superiore. Forse dovrei rimuoverli, magari
qualcuno potrebbe essere così gentile di fare per favore un controllo
della temperatura con un oscilloscopio non modificato.
Luc ha scritto:
Grazie anche per queste informazioni, Lothar!
Tuttavia credo che i dissipatori non fanno male anche perché sono
suggeriti anche nel Forum Hardware
(Http://www.mikrocontroller.net/topic/133766 # 1.913.511% 29:).
Il nastro tra l'apertura e la ventola è suggerito anche nel documento
"W20xxA Optimizing Thermal Design" su sourceforge.
Quindi per me non ci dovrebbero essere problemi, ma potrei sbagliarmi!
Mi dispiace molto perché non posso aiutarti con la misurazione della
temperatura interna, mi spiace Lothar.
Comunque, penso di aver letto che le versioni a 4 canali hanno problemi
di surriscaldamento, mi sembra nel Forum Hardware, magari qualcuno può
confermare.
gyppe schrieb:
>Grazie Luc,>Thanks Luc,
@gyppe
Io credo che dovresti invece ringraziare Michael H. che conosce bene
Tedesco, Inglese ed Italiano.
@all
I think you should be very thankful to Michael H. who knows well German,
English and Italian.
@Hayo
Thank You very much also for Special_Functions.txt!
(Grazie mille anche per il documento "Special_Functions.txt" for italian
guys)
gyppe schrieb:
>https://sites.google.com/site/gyplace/home/elettro...
@gyppe
Bello, complimenti!
@all
Beautiful, congratulations!
Vielen Dank!!!
Thanks a lot!!!
Grazie mille!!!
Gruß Luc
Regards Luc
Saluti Luc
@Hayo,
>Utility -> More -> Hardware>Hier könntest Du bei ADC-setting mal schauen ob das auch bei anderen>ADC-Settings auftritt.
Die HW-Einstellungen haben keinen Einfluß auf den Fehler.
Aber die Timebase muß 5µs oder kürzer sein.
Anbei noch ein Screenshot mit ähnlicher (der gleichen?) Problematik.
Bin ich der einzige mit dem Phänomen?
Gruß,
Rainer
Hi Rainer,
so sehr ich auch mit Deinen Einstellungen hin und herscrolle - bei mir
kriege ich das nicht hin. Da sieht alles gut aus. Heute gibt es wieder
eine aktualisierte Version in der ich den restlichen Datenschrott der
hier reportet wurde beseitigt habe. vielleicht hilft die.
Hayo
branadic schrieb:> Hallo Guido,>> der Unterschied ist, dass es sich dabei um eine von der "Eingangsstufe> unabhängige" Kalibration handelt, die also unabhängig von den> allgemeingültigen Kanaleinstellungen auch wieder zurückgesetzt werden> kann.
Also wenn ich Dich richtig verstehe, dann soll die Kompensation so
aussehen, dass vom Signal der Mittelwert über eine Periode gebildet wird
und dieser Mittelwert dann beim DAC-Offset als Nulllinie benutzt wird.
Im Prinzip geht das auch jetzt schon. Denn die aktuelle DAC-Kalibrierung
arbeitet ähnlich, nur das hier nicht die passende Timebase für das
Comp-Signal benutzt wird sondern bei 50ns/div kalibriert wird.
Auch die Umschaltung wäre kein Problem, die Hardwareumschaltung arbeitet
ja ähnlich, nur dass hier nicht zwischen den ermittelten Offsets
gewechselt wird, sondern zwischen den Skalierungen.
Allerdings fehlt mir eine aktive Probe zum Testen ob das auch
funktioniert. Grundsätzlich könnte man das aber auf die "Wishlist"
setzen.
Hayo
Hallo Rainer,
Du bist da auf das "alte" ADC Setup Problem gestossen. Das sollt aber
nicht auftreten wenn im Menu Utility->More->Hardware->ADC Setup
"Factory" steht. Kannst du das bitte kontrollieren.
Martin
Zum aktiven Tastkopf: Ich meinte das auch so, wie Hayo schreibt.
Einfach mal mit dem DAC-Abgleich probieren und wenn es funktioniert,
macht es Hayo wenig Mühe einen Schnellzugriff mit Speicherung der
alten Werte zu implementieren. Das könnte dannja im Kanalmenü
untergebracht werden.
Grüße, Guido
Hayo W. schrieb:> Also wenn ich Dich richtig verstehe, dann soll die Kompensation so> aussehen, dass vom Signal der Mittelwert über eine Periode gebildet wird> und dieser Mittelwert dann beim DAC-Offset als Nulllinie benutzt wird.
Hallo Hayo,
im Falle unseres Probe-Signals wäre das genau das der Ansatz, wenn auch
nicht unbedingt nur über eine Periode, kommt halt drauf an wieviele
Perioden man sich da gerade anschaut.
Hayo W. schrieb:> Allerdings fehlt mir eine aktive Probe zum Testen ob das auch> funktioniert
Eine mit derzeit ~20,-€ vergleichsweise kostengünstige Lösung für einen
Aktiven Tastkopf habe ich ja vorgestellt.
branadic
@Hayo, Martin H.
ich muß gar nichts machen. Ab und zu gibt es die Ausreißer. Bei
"Display->Persist" fallen sie dann richtig auf.
Im HW-Menü sind beide Einstellungen auf Factory.
Dan hoffe ich mal, dass die neue FW was ändert. Sonst teste ich auch
noch mal alte Versionen, um zu sehen ob das wirklich ein SW-Problem ist.
Viele Grüße,
Rainer
Es gibt außer Fixes (siehe changelog) mal wieder ein Gutie! Da Ihr ja
die Pulldowns so mögt gibt es jetzt im Acquire Menu ein solches für den
Average Mode. Die Einstellung 2 entspricht der alten Funktion, 4 und 8
sind neu.
Ich bin mir nicht 100% sicher dass das so richtig ist, bitte testet das
mal.
Der Datenschrott am Ende und Anfang sollte jetzt weg sein - bei mir hab
ich nichts mehr gefunden.
Beim ersten Start nach dem flashen bitte im Utility Menu das Default
Setup drücken damit sich das Menü richtig initialisiert. Ansonsten steht
da was falsches drin und es gibt Datenschrott!
-----------------------------------------------------------------------
Additional to the fixes (changelog) I made a goodie for You. For You
like the pulldowns so much, I created a new one in the acquire menu for
the average function. Setting 2 is like before, 4 and 8 are new.
I'm not 100% shure that it works like it should, so please check it.
Data trash at start and end of the signal should now been gone - I
didn't find any more.
At first start after flashing please change to utility menu and push
Default Setup to initialize the new menu. Otherwise the wrong menu value
may cause data trash.
Hayo
@Rainer
Jetzt habe ich rausgefunden wie Du das Bild hinbekommen hast. Wenn ich
auf "Persist" schalte und eine halbe Stunde warte, dann sieht es bei mir
auch so aus. Im normalen Betrieb sind das aber sporadisch auftretende
Spikes die kaum auffallen.
Da ändert natürlich auch die Firmware nix dran.
Hayo
Ach ja, wie im changelog zu sehen ist habe ich den Overlay Mode
überarbeitet und an die neue Filtertechnik angepasst. Jetzt kann man
direkt im Overlay Mode den Filter ändern und es wirkt auf beide Signale
(Original und Memory Trace).
Hayo
@Hayo:
Die Spikes gibt es bei mir in beiden Kanälen. Komischerweise sind die
Spikes in Ihrer Höhe nicht statistisch verteilt. Immer nur auf einer
Seite der Flanke und immer in der Höhe (Spannung) der der anderen Seite
(ich hoffe das ist verständlich ausgedrückt). Oder sind die ADC-Werte
evtl. 0?
Ich frage mich halt wo die Ausreisser herkommen. Nach rein zufälligen
Effekten sieht mir das nicht aus.
Gruß,
Rainer
Hi Hayo and guys all!
Hayo thank You very much also for this your new gem, You are very kind,
so again thanks You a lot for the great job and free time You provided
generously to us!!!
I tried the new 1.2.BF.2.5 firmware's release and for me it is great!
Hayo W. schrieb:
>Da Ihr ja die Pulldowns so mögt gibt es jetzt im Acquire Menu ein>solches für den Average Mode. Die Einstellung 2 entspricht der>alten Funktion, 4 und 8 sind neu.
Oh boys, Hayo You are so amazing!!!
Thank You so much also for this add which I have requested!
It's just what I wanted and this makes me very happy!!!
Hayo, thank You, thank You, thank You!!!
No words, RESPECT!!!
Hayo W. schrieb:
>Ich bin mir nicht 100% sicher dass das so richtig ist, bitte testet>das mal.
The new add is great but unfortunately I find it do not work properly.
As usual, this my reporting is not intended as a criticism but as a
simple answer to your kind invitation.
So I find also without a signal on CH1 and CH2 when AVERAGE is activated
on CH2 appears a square wave.
This square wave is not dependent by filters.
After the update I put the defaults again but anyway the problem there
is.
In some cases, also with removing of the input signals, also on CH1 the
signal remains and it does not go away.
When the signal for the compensation of the probe is applied only to
CH1, on CH2 appear the same signal in conjunction with the square wave
described above.
Hardware is High Frequencies and gain in 1.25 but the problem also
occurs with Factory both ADC and gain.
I hope that I explained, however, look at my screenshot please.
I am sorry but I can not dwell, I am unfortunately busy now, so I am
really sorry Hayo, excuse me please if You can.
Thank You again Hayo and please excuse me.
Gruß Luc
Hi Luc,
interesting pictures You posted there! Yes I suspected that the function
doesn't work properly. It is not written by me, but is from the WELEC
developer realized in assembler. So I only changed the interface input
to have an attempt. I think I have to rewrite it completely to make it
work properly.
Hayo
Grazie luc per la traduzione, molto utile! Grazie Hayo per la nuova
versione, ora sembra perfetto, si trovano forse alcune imperfezioni di
visualizzazione ma molto rare. Pensa alla fft ora, quella è roba tosta!
:)
Intanto sto continuando l'articolo, non sembra male per ora. Quando
finisco magari ve lo passo e se qualcuno riesce a tradurlo in inglese si
potrebbe mettere nel wiki se può servire.
Ciao, Gyppe.
Luc Thanks for the translation, very useful! Hayo Thanks for the new
version, now it seems perfect, perhaps there are some imperfections in
the display, but very rare. Think of the hours fft, that's tough stuff!
:)
Meanwhile I am continuing the story, do not look bad for now. When I
finish I'll pass and maybe if someone can translate it into English
could be put in the wiki if it helps.
Hello, Gyppe.
Ciao a tutti
Il problema citato da Luc era già nella BF 2.4
allego screenshot
Grazie Ad Hayo e a tutti, per il lavoro incredibileHello everyone
The problem cited by Luc was already in BF 2.4
I attach screenshot
Hayo and thanks to everyone for the incredible work
ich habe gerade folgendes Entdeckt, wenn ich das 1 kHz Probe Comp
Testsignal anschaue 200mV/dev und die Timebases durchschaltet dann
funktioniert bei 100µS/div und kleiner der Trigger nicht stabil, das
Rechteck springt hin und her.
Edit: Das tritt nur im Auto Mode auf Normal und Combi Mode funktionierts
@Thomas
welcher Trigger? Auto, Combi, Normal?
Wie schon länger bekannt arbeitet der Auto Trigger bei langsameren TB
nicht richtig. Deshalb hat Stefan den Combi Trigger (urspr. Standard
Trigger) geschrieben, der auch bei langsamen TB zuverlässig triggert.
Löst das evtl. Dein Problem?
Hayo
Hier die 2. Compilation der 1.2.BF.2.5 mit einem Fix für das Average
Problem das Luc reportet hat.
@Luc
thanks for testing and reporting this bug. It was only a little one but
not so easy to find.
Nevertheless I'm thinking about a new average routine written in C
instead of the assembler routine. This allows to implement some
additional functionality.
Gruß Hayo
Hallo
Da ich im Moment leider zu wenig Zeit zum programmieren habe, kann ich
hier nur mit ein paar Implemetierungstipps aufwarten.
@Hayo
Du bekommst von mir meine Bachelorarbeit über
Mehrraten-Signalverarbeitung und meine Diplomarbeit über die SF eMail.
Beide beihalten Informationen, die dir weiterhelfen werden + die Cpp und
Octave Dateien mit meinen Filterroutinen.
Der DC-Offset entsteht bei den digitalen Filtern allgemein durch die
2er-Komplement Abrundung. Da bei der 2er Komplement Darstellung das
höchstwertigste Bit negativ gezählt wird, wird beim Verkeinern einer
Zahl (Schiebeoperation, Division, Gleit- und Fixkommamultiplikation...)
implizit immer abgerundet. Das bedeutet, dass positive Zahlen kleiner
werden und jedoch negative Zahlen betragsmäßig größer werden. Dagegen
hilft bspw. das "rechenintensive" Betragsabrunden oder Filteroffsets
(sehr unsicher!).
MfG
Alexander
moin,
hier mal ein paar Shots im "Delay-Modus"
Am Oszi hängen 2 verschiedene Tastköpfe, daher die unterschiedlichen
Einstellungen:
Ch.1 200mV/Div und Ch.2 500mV/Div
Shot 1-3 ist der "Smooth" Filter aktiviert mit 1kHz Prob-Signal
Shot 4 ist der "Strong" Filter aktiv (1kHz Prob-Signal)
Shot 5 und 6 liegt kein Signal an.
Bei den 3 "Stage" Filtern, treten diese Effekte nicht auf, nur bei
Smooth u. Strong
Vielleicht testet das mal Jemand?
Gruß Michael
Hi Michael,
ich habe schon eine Idee wo das Problem liegt, es sind die neuen
Speicherbereiche für Filter. Danke für den Tip, da muß ich dann wohl
noch mal ran. Nebenbei bin ich gerade dabei neue Average Routinen zu
schreiben, da kann ich das ja gleich mit erschlagen.
Gruß Hayo
Zum Thema Filter:
Ich habe Alex gerade meine Email zukommen lassen, damit er mir weitere
Infos zu digitalen Filtern zukommen lassen kann. Mit dieser
Unterstützung werden wir hier ja zu echten Digitalfilterexperten :-)
Ich selbst habe mich mit dem Thema im Studium zwar auch eine ganze Zeit
beschäftigt, aber das ist auch schon 20 Jahre her...
Also ist jede Auffrischung sehr willkommen. Mal sehen was wir dem WELEC
da noch alles beibringen können.
Gruß Hayo
Hayo W. schrieb:
> Hi Michael,
Hi Hayo,
>> ich habe schon eine Idee wo das Problem liegt, es sind die neuen> Speicherbereiche für Filter. Danke für den Tip, da muß ich dann wohl> noch mal ran. Nebenbei bin ich gerade dabei neue Average Routinen zu> schreiben, da kann ich das ja gleich mit erschlagen.>
Den Average-Mode habe ich so verstanden:
Average mode (Average)-Zeigt die durchschnittliche Amplitude jeder
Frequenz an, errechnet vom Moment des Einschaltens bis zum Ausschalten
des Modus.
Average mode (Maximum)-Zeigt den Spitzenwert bei jeder Frequenz an,
errechnet vom Moment des Einschaltens bis zum Ausschalten des Modus.
Average mode (Minimum) - Zeigt den Minimalwert bei jeder Frequenz an,
errechnet vom Moment des Einschaltens bis zum Ausschalten des Modus.
Jetzt haben wir ja die Bereiche 2-4-8-16
...wie werden denn diese Bereiche definiert?
> Gruß Hayo
...so so vor 20 Jahren, dann hast du ja jetzt das beste Alter erreicht
:)
Gruß Michael
EDIT: Bei Shot 6 sieht es fast so aus, als wäre vom Rechteck-Signal noch
was übriggeblieben, obwohl alle Stecker abgezogen waren, kann das sein?
Michael D. schrieb:> Den Average-Mode habe ich so verstanden:> Average mode (Average)-Zeigt die durchschnittliche Amplitude jeder> Frequenz an, errechnet vom Moment des Einschaltens bis zum Ausschalten> des Modus.> Average mode (Maximum)-Zeigt den Spitzenwert bei jeder Frequenz an,> errechnet vom Moment des Einschaltens bis zum Ausschalten des Modus.> Average mode (Minimum) - Zeigt den Minimalwert bei jeder Frequenz an,> errechnet vom Moment des Einschaltens bis zum Ausschalten des Modus.
Ist das so? Ich habe diese Informationen bei meiner Recherche so nicht
gefunden. Hast Du da mehr Infos zu gefunden? Immer her damit.
> Jetzt haben wir ja die Bereiche 2-4-8-16> ...wie werden denn diese Bereiche definiert?
Also wie ich sagte ist die Assemblerroutine für mich etwas
undurchsichtig, also habe ich sie in der BF.2.6 einfach mit den Werten
1,2,3,4 gefüttert. Da mit diesen Werten unter anderem eine LSR-Operation
(shift right) durchgeführt wird entspricht das den 2-4-8-16.
Bei dem Vergleich mit meinen (jetzt gerade) neu geschriebenen Routinen
habe ich festgestellt, dass die Werte 2,3,4 vermutlich keinen großen
Sinn ergeben, der Wert 1 entspricht aber bei meinen Routinen der
Einstellung "unendlich".
Allgemein beim Averaging nimmt man ja den aktuellen Signalverlauf (also
den kompletten Signalbuffer) und den vorherigen Signalverlauf (das in
einem extra Buffer gespeicherte Signal) und bildet den Mittelwert.
Ich habe jetzt aber unterschiedliche Möglichkeiten den Mittelwert zu
bilden implementiert:
unendlich - der Mittelwert wird immer wieder neu mit dem vorherigen
Ergebnis der Mittelwertbildung gewonnen.
2,4,8 - die Mittelwertbildung started nach einem Cyclus von 2,4,8
Signaldurchgängen wieder mit mit einem frischen ungemittelten Signal.
> ...so so vor 20 Jahren, dann hast du ja jetzt das beste Alter erreicht> :)
Korrekt, Bergfest war schon (Ziel ist 95), aber irgendwie fühl ich mich
immer noch als Student, es gibt immer was Neues zu lernen und zu
dengeln.
>> EDIT: Bei Shot 6 sieht es fast so aus, als wäre vom Rechteck-Signal noch> was übriggeblieben, obwohl alle Stecker abgezogen waren, kann das sein?
Das sollte mit der Korrektur der Filterspeicherroutine verschwinden
(hoffe ich)
Hayo
Hallo zusammen,
Hayo W. schrieb:
>Allgemein beim Averaging nimmt man ja den aktuellen Signalverlauf (also>den kompletten Signalbuffer) und den vorherigen Signalverlauf (das in>einem extra Buffer gespeicherte Signal) und bildet den Mittelwert.
anbei ein Ausschnitt aus dem Manual, der genau das bestätigt.
Gruß Jürgen
Hello again,
ich habe die letzten Bugs gefixt und die Average Function völlig neu
geschrieben. Das neue C-Coding ist um einiges schneller als das alte
Assembler Coding, weil nicht mehr alle Punkte berechnet werden, sondern
fast nur noch die benötigten.
Weiterhin habe ich die ADC-Assembler Routine von den überflüssigen
Averageberechnungen befreit, was dazu geführt hat, dass alles etwas
schneller läuft und die Refreshrate gestiegen ist.
Gruß Hayo
Hayo W. schrieb:
> 2,4,8 - die Mittelwertbildung started nach einem Cyclus von 2,4,8> Signaldurchgängen wieder mit mit einem frischen ungemittelten Signal.
Ich habe noch mal im Netz nach "Average-Mode" (heißt ja Mittelwert)
gestöbert, da bin ich auf die Tek-Seite der 2000er Serie gestoßen.
Hier mal ein Auszug aus dem Datenblatt.
Shot 1
Ganz links steht. Mittelwert - Gemitteletes Signal, wählbar: 4, 16, 64,
128
Sind das die Zyklen vom Tek? Vielleicht hilft dir ja diese Info?
>>> ...so so vor 20 Jahren, dann hast du ja jetzt das beste Alter erreicht>> :)> Korrekt, Bergfest war schon (Ziel ist 95), aber irgendwie fühl ich mich> immer noch als Student, es gibt immer was Neues zu lernen und zu> dengeln.
...bin auch schon um Einiges drüber!
>(Ziel ist 95)
Gesunder Optimismus, schauen wir mal...
Delay mit "Smooth-Filter" funzt prima in jedem Bereich, hast du fein
gemacht!!!
Nicht über die zwei unterschiedlichen Signale Wundern, es sind 2
verschiedene Tastköppe angeschlossen (Ch1 20:1, Ch2 10:1)
Shot 2
Mit der Energie gehst du locker über 100...;)
Gruß Michael
Hayo sei incredibile! :)
HO controllato con diversi settaggi e mi sembra perfetto, scomparse
anche le piccole imperfezioni nel modo delayed della versione 2.5, ora è
davvero ok! Grazie. L'acquisizione average mi sembra ottima!
Gyppe
Hayo're incredible! :)
I checked with different settings and it seems perfect, missing even
small imperfections in the delayed mode on the version 2.5, now it's
really ok! Thanks. The average mode is very usefull!
Gyppe
Hi Hayo and guys all!
Hayo You are the best, You are the most tireless Software Engeneer in
the world, therefore thanks You a lot for the amazing job and free time
You provided generously to us also this Sunday!!!
Hayo W. schrieb:
>ich habe die letzten Bugs gefixt und die Average Function völlig neu>geschrieben. Das neue C-Coding ist um einiges schneller als das alte>Assembler Coding, weil nicht mehr alle Punkte berechnet werden, sondern>fast nur noch die benötigten.
Hayo You are very kind, I tried the new 1.2.BF.2.6 firmware's release
and the reported bugs are gone!
No more garbage in any situations, really great!!!
Thanks You very much, RESPECT!!!
Hayo W. schrieb:
>Weiterhin habe ich die ADC-Assembler Routine von den überflüssigen>Averageberechnungen befreit, was dazu geführt hat, dass alles etwas>schneller läuft und die Refreshrate gestiegen ist.
Oh, really very incredible!!!
Thank You so much, Hayo You are the Number One, really no words!!!
RESPECT!!!
The new add I have requested works fine now, I thank You for the amazing
job!!!
I understood, You've completely rewritten the function due to the
malfunctioning of that introduced by Welec.
The function is now faster and above all work well, thanks You very much
Hayo, You are a hero!!!
I do not really know how to thank You for your kindness, only I am very
sorry for the time You lost to fulfill my request.
RESPECT! RESPECT! RESPECT!
But I noticed something I had never seen before.
I adjusted the delay between channels and everything works fine, but
with the time base adjusted to 20nS there is a 4nS delay between CH2 and
CH1 and the failure occurs only with the time base set at 20nS.
Hardware is High Frequencies and gain in 1.25 but the problem also
occurs with Factory both ADC and gain.
Look at my screenshot, please.
After, I have a question, more than anything it is a curiosity.
Is HOLDOFF working?
Seems to me do not work property, I tried it but I do not succeded to
use it.
Seems to how the HOLDHOFF works like Pulse Width in some situations, I
regulate it and the wave form moves horizontally but it does not do his
duty.
Should not HOLDOFF inhibit the trigger for a certain time?
So if I regulate it at 2 seconds and I am watching the probes's
compensation signal, should not I see the synchronized signal only every
2 seconds?
This does not happen and the signal remains synchronized even with the
trigger set to NORMAL.
Repeat, more than anything it is a curiosity.
As I have mentioned, also Pulse Width seem to me to works strange.
For me Pulse Width ">" and "><" works fine, Pulse Width "<" do not
works.
Before, seems to me all works fine with the the probes's compensation
signal.
I know we have already discussed about it, but I'm sure that the Pulse
Width worked with all its settings and I have written it here in the
Forum also.
Instead seems to me that little has been said about HOLDOFF's function.
In any case I know I'm boring and I apologize, so please, excuse me if
You can do it.
I am really sorry Hayo and all.
Thank You again Hayo and please excuse me.
Gruß Luc
Luc schrieb:> Hi Hayo and guys all!> Hayo You are very kind, I tried the new 1.2.BF.2.6 firmware's release> and the reported bugs are gone!> No more garbage in any situations, really great!!!
Thanks for the detailed testing and reporting.
> But I noticed something I had never seen before.> I adjusted the delay between channels and everything works fine, but> with the time base adjusted to 20nS there is a 4nS delay between CH2 and> CH1 and the failure occurs only with the time base set at 20nS.
Hmmm, really curious. I have to check it...
> Is HOLDOFF working?> Seems to me do not work property, I tried it but I do not succeded to> use it.> Seems to how the HOLDHOFF works like Pulse Width in some situations, I> regulate it and the wave form moves horizontally but it does not do his> duty.
It is not so easy to test it because You need a special signal for it
(like a bus signal or something in this way). A normal periodic signal
will show no effect (for You) to HOLDOFF, because all parts of the
signal look equal (I checked it with my Tek 2465A).
HOLDOFF is made for triggering signals with alternating pulsewidth. If
normally the trigger would pick the first pulse of the signal cycle you
are able to trigger on the second or third pulse with HOLDOFF (delayed
trigger).
> Should not HOLDOFF inhibit the trigger for a certain time?
correct
> So if I regulate it at 2 seconds and I am watching the probes's> compensation signal, should not I see the synchronized signal only every> 2 seconds?
if I remember right, the range (on hardware side) for HOLDOFF is much
smaller than 2 seconds but I have to check it. Maybe I have to limit it
in the firmware.
> This does not happen and the signal remains synchronized even with the> trigger set to NORMAL.
See comments above.
> As I have mentioned, also Pulse Width seem to me to works strange.> For me Pulse Width ">" and "><" works fine, Pulse Width "<" do not> works.> Before, seems to me all works fine with the the probes's compensation> signal.> I know we have already discussed about it, but I'm sure that the Pulse> Width worked with all its settings and I have written it here in the> Forum also.
I didn't change anything at Pulse Width Triggering in the last versions.
The last changes has been made in version BF.2.0
But you are right, sometimes it is not working as it should. The
correction is a little bit tricky because the registers and their
settings are not documented in any way. So we have to do it with try and
error in such cases.
Kind regards / ciao
Hayo
Hallo Leute / Hi Folks,
das die Refreshrate gestiegen ist durch die Optimierungen in der letzten
Version hatte ich ja schon gesagt. Hier jetzt mal einige Messungen dazu
um das mal etwas zu präzisieren.
Verglichen habe ich die BF.2.2 mit der alten Assemblerroutine und die
BF.2.6 mit der optimierten Assemblerroutine.
Gemessen mit W2014A bei Defaulteinstellungen (Default Setup) heißt
50ns/div alle 4 Kanäle aktiv. Bei Average im Invinite Modus.
--------------------------------------------------------
I told about the optimizations in the last version, but here are some
detailed measurements to get it more precisely.
I compared the BF.2.2 (with old assembler coding) and the BF.2.6 with
optimized Coding.
Settings on the W2014A are default (Default Setup) - means 50ns/div and
all channels active. At Average in Invinite mode.
Ergebnis / Result:
BF.2.2 / Average off -> 165 Frames/min
BF.2.2 / Average on -> 123 Frames/min
BF.2.6 / Average off -> 200 Frames/min
BF.2.6 / Avarage on -> 195 Frames/min
Diese Messungen könnt Ihr leicht selbst machen. Dazu müßt Ihr in der
Tomcat.cpp den auskommentierten Framecounter wieder entkommentieren und
das Ganze kompilieren. Nach dem Flashen muß ein Terminal gestartet
werden auf dem die Ausgabe erfolgt. Mit Shift + J kann man den Counter
resetten.
----------------------------------------------------------------------
This measurements kann be done by Yourself easily. You have decomment
the Framecounter in the Tomcat.cpp and to compile the source. After
flashing You have to start a terminal on which the output is displayed.
With shift + J the counter can be resetted.
Weitere Optimierungen sind in Arbeit.
Further optimizations are under construction.
Hayo
Hallo Hayo,
nach Umzug steht der Laborplatz nun wieder.
Beim Einstellen des Holdoff-Wertes sind mir folgende Macken aufgefallen
(ausgehend von Default Setup):
Beim Durchtasten durch die Bereiche mit dem Holdoff-Softkey tauchen
folgende Unschönheiten auf:
1. 100.00 us wird als 99.99 us angezeigt
2. 1.00 s wird als 1.00 ms angezeigt (nur upward)
Bei Erhöhung mit dem Drehreglers um 1.00 s folgen aufeinander:
998.00 ms, 99.999 ms, 1.00 ms, 1.00 ms, 1.00 ms, 2.0 s, 3.0 s, usw.
Abwärts ist ok: 3.0 s, 2.0 s, 1.0s, 999.00 ms
Falls du da mal vorbei kommst....
(Der harte Schrittweitensprung um den Faktor 1000 steht ja schon auf der
ToDo-Liste)
Die Funktionalität/Wertebereich ist noch ein anderes Thema.
Bei Einstellung von z.B. 2 s würde ich erwarten, dass 2 s lang nicht neu
getriggert wird.
Gruß
Rainer
Hi Rainer,
erstmal der Laborplatz - dann die Küche! Das wichtigste zuerst ;-)
Das sind Macken mit unterschiedlichen Ursachen. Die Anzeigeroutinen für
die Zahlenwerte (floatstr_t.cpp) sind noch nicht optimal. Rolf sagte mir
er hätte da inzwischen was dran verbessert, mal sehen ob ich da bei Ihm
fündig werde, das würde etwas Zeit sparen.
Beim Holdoff war ich bislang noch nicht dran, da muß ich wohl mal ein
Auge drauf werfen. Mir fehlt im Augenblick ein adäquates Testsignal. Ein
serieller Port müßte eigentlich gehen. Da könnte man auf die Bytes
triggern.
Was ganz Anderes:
Ich optimiere gerade weiter an der Assemblerroutine. Die aktuelle
Refreshrate liegt jetzt bei 245 Frames/min (Avrg off)!!
Ich hätte gar nicht vermutet dass da noch so viel Potential drinsteckt.
Gruß Hayo
Hayo W. schrieb:> Ich optimiere gerade weiter an der Assemblerroutine. Die aktuelle> Refreshrate liegt jetzt bei 245 Frames/min (Avrg off)!!
Da muß Alexander ja schon Angst bekommen, klasse...
Beim Holdoff wundert mich insbesondere, dass die Anzeige von "1.00 ms"
an Stelle von "1.00 s" nur in Aufwärtsrichtung auftritt.
Rainer
>This measurements kann be done by Yourself easily. You have decomment>the Framecounter in the Tomcat.cpp and to compile the source. After>flashing You have to start a terminal on which the output is displayed.>With shift + J the counter can be resetted.
Hayo questa è davvero interessante!! Come compilo il sorgente? Va bene
il normale gcc preinstallato su linux o serve qualcosa di particolare?
Se non è tanto complicato vorrei proprio provare.
Hayo this is really interesting! How to compile the source? Fits the
normal pre-installed on linux gcc or need something special? If it is
not so complicated I want to try.
Hi gyppe,
using Linux please look at
"How to install Linux and CDK en.txt" in the Doc directory of
1.2.BF.2.6.zip
Using Windows You can use the Cygwin environment from an USB-Stick or
copy it to harddisk - as You prefere it.
You will find it here:
http://sourceforge.net/projects/welecw2000a/files/Development/NIOS_Cygwin.zip/download
You need an Editor for Windows, I would recommend Notepad++ which is a
mighty editor for all purposes - and for free.
Also You will find some hints here in the Forum how to use the Cygwin
(some weeks ago).
If You have any questions - please ask.
Hayo
Rainer W. schrieb:> Da muß Alexander ja schon Angst bekommen, klasse...
:-) Das wohl kaum, dazu ist das LEON3 Design einfach zu schnell.
Außerdem wurde ja auch Einiges was im NIOS-Design die Firmware erledigt
beim LEON3 in VHDL umgesetzt.
Da haben wir keine Chance...
Aber trotzdem ist es ganz erfreulich, da wir wohl noch eine ganze Zeit
das NIOS-Design benutzen werden bevor wir auf das LEON3-Design umsteigen
können.
Gruß Hayo
Grazie hayo, scusami non mi ero accorto di quel documento, ora tento
subito l'istallazione :)
Hayo Thanks, sorry I did not realize that document, now try installing
now:)
Ciao, hello, gyppe.
Ergebnis / Result:
BF.2.2 / Average off -> 165 Frames/min -> 2,75 Frames/sek
BF.2.2 / Average on -> 123 Frames/min -> 2,05 Frames/sek
BF.2.6 / Average off -> 200 Frames/min -> 3,33 Frames/sek
BF.2.6 / Avarage on -> 195 Frames/min -> 3,25 Frames/sek
BF.2.6 / Avarage off -> 245 Frames/min -> 4,08 Frames/sek
die Steigerung ist schon beachtlich.
Schade das du (noch) kein VHDL kannst Hayo ;-)
Thomas O. schrieb:> Schade das du (noch) kein VHDL kannst Hayo ;-)
Hab ich mal im Studium kurz gemacht, aber das ist einfach zu lange her.
Das hab ich inzwischen wieder vergessen, da ich damit nie gearbeitet
habe.
Aber dafür haben wir ja unsere LEON3-Spezies. Ich bin da ganz
zuversichtlich dass das noch ein echter Kracher wird. Man muß nur
Durchhaltevermögen haben.
Gruß Hayo
Übrigens für diejenigen die an den Details interessiert sind:
In der alten Assemblerroutine wurde für jeden Wert geprüft ob er
invertiert oder gemittelt werden sollte.
D.h das sind 16383 if(Invert) Abfragen und nochmal 16383 if(Average)
Abfragen.
Bei den neuen Versionen wird jeweils nur noch 1 Mal abgefragt!!!
Weiterhin werden jetzt 3 Übergabeparameter weniger beim Aufruf benötigt.
Das macht das Ganze doch schon etwas schlanker und schneller.
Hayo
Es sind natürlich 16384 Mal - der Zähler läuft von 0 - 16383
By the Way ist mir bei den Umbauarbeiten aufgefallen, dass der Trigger
bei invertiertem Signal falsch positioniert - wird selbstverständlich
korrigiert.
Trigger has wrong position with inverted signal - correction is
guarantied.
Ich habe zur Gegenprüfung immer mein zweites WELEC parallel laufen mit
einer älteren Firmware(BF.2.2). Der Geschwindigkeitsunterschied zur
neuen BF.2.7 ist im direkten Vergleich schon krass!!
Auch das Triggern auf die negative Flanke klappt bei schmalen Signalen
(Pulse) nicht. Ich arbeite daran...
Hayo
Ja war ganz hilfreich, aber ich bin mir nicht ganz sicher wie die das
mit der Mittelung bis 128 gelöst haben. Offensichtlich anders als ich,
da sonst die Berechnung viel zu lange dauern würde. Ich denk da noch
drüber nach.
Hayo
...und hier ist sie - die schnellste Version die wir je hatten.
...BlueFlash labs proudly presents - the fastest version we ever had.
Highlights:
- faster than ever
- trigger stabilized
- corrected triggering of inverted signals
Gruß / regards /ciao
Hayo
Vielen Dank, fühlt sich gut an!!
So beim ersten testen ist mir aufgefallen (kann aber auch schon länger
so sein), das bei Zeitbasen 100 us und kleiner die Triggerung nicht
funktioniert (das Bild springt).
Einstellungen: Default Setup, Eingang an Probe-comp, Triggerung Ch1,
steigende Flanke
Ab 200us ist alles wie es soll!
Viele Grüße,
Mirko
hat sich erledigt - nach einigem rumdrehen und ändern des Triggermodus
zwischen Normal/Combi und zurück ging es dann...
Kann irgendwas mit der Initialisierung sein (an der Zeitbasis hatte ich
oft genug gedreht!)
Viele Grüße,
Mirko
Auto Trigger hat eine zu kurze Timeoutkonstante und springt deshalb in
den langsamen TB. Hierfür ist der Combi-Trigger von Stefan besser
geeignet!
Hayo
Neues Problem - dreht man an der Zeitbasis schnell hin und her, erhält
man relativ schnell so etwas (und die Refreshrate ist dann auch im
Keller).
Das hatten wir im Zusammenhang mit Delayed-Modus so schon mal.
Viele Grüße,
Mirko
Tja, da kann ich nicht viel machen, denn da kommt einfach der
Interrupt-Handler des Rotation-Interface nicht schnell genug hinterher.
Wie schnell drehst Du denn daran? Ich hatte das bislang noch nicht.
Einfach etwas langsamer machen und Ruhe ausstrahlen ;-)
Hayo
Hallo Hayo,
wirklich sehr beeindruckend. Schau was ich für ein Folterwerkzeug
für Oszilloskope habe (PM5771). Sehr alt, aber viel schneller als
das Welec.
Irgendwie kommt mir das mit dem Averaging in C noch bakannt vor,
das hatte ich doch schon vor laanger Zeit mal gemacht. So ist es
aber besser. :-)
Grüße, Guido
Schick, solche Dinger hatten wir damals bei uns während des Studiums im
Labor. Die sind garnicht mal übel. Schön robust, da geht so schnell nix
kaputt. Damit kann man schön die Grenzen unseres Oszis ausloten,
insbesondere die Anstiegszeit.
Die meisten Messungen mache ich hier während des Programmierens auch mit
einem uralten HP3310/B das ich noch aus dem Studium habe. Damit habe ich
damals meine Diplomarbeit getestet (externes PC-Oszi am Parallelport).
Gruß Hayo
@Hayo
Schon klar, das das unter Kosmetik läuft, aber zumindest kennen sollte
man das Problem(chen).
Gerade wenn man am entgegengesetzten Ende der Zeitbasis ist, reiße ich
den Knopf schon mal heftig rum (wie am Analogen halt, nur das man da
einen Anschlag hat;-))
Viele Grüße,
Mirko
Hallo Hayo,
vielen Dank für die Version 1.2.BF2.7! Die läuft jetzt richtig schnell
und gut!
>> So if I regulate it at 2 seconds and I am watching the probes's>> compensation signal, should not I see the synchronized signal only every>> 2 seconds?
Hayo schrieb:
>if I remember right, the range (on hardware side) for HOLDOFF is much>smaller than 2 seconds but I have to check it. Maybe I have to limit it>in the firmware.
In der zweiten Ausgabe des Handbuches zum Welec ist der korrigierte
Wertebereich für Holdoff auf Seite 3-6 zu finden: min 16ns / max 100ms.
Da stand in der ersten Ausgabe noch 40ns - 300s!
So macht es Sinn den Wertebereich zu beschränken.
Gruß Jürgen
Nachtrag (zu dem Effekt beim schnellen drehen an der Zeitbasis):
Kanal 2 bleibt auch nach aus und einschalten zeitlich verschoben!
Erst ein Default Setup bringt es wieder ins Lot.
Viele Grüße,
Mirko
Wow! Das ist wirklich schnell geworden!
Wenn ich auf Kanal 1 bin und im FFT Modus "Power Spec" und dann am
Volt/Div Regler drehe ändert sich die Einstellung, allerdings wird oben
links immer nur "10dBm/" angezeigt obwohl es beim Drehen des Regler
unterlegt wird. Ist das ein Bug?
Vielen Dank für deine Arbeit Hayo!
Lg
Hi Hayo and guys all!
First, Hayo thanks You very much for the latest 1.2.BF.2.7 firmware's
release!
You are really very kindly, therefore thanks You a lot for the amazing
job and free time You provided generously to us!!!
Hayo W. schrieb:
>...und hier ist sie - die schnellste Version die wir je hatten.>...BlueFlash labs proudly presents - the fastest version we ever had.>>Highlights:>>- faster than ever>- trigger stabilized>- corrected triggering of inverted signals
Hayo, You are right, the new 1.2.BF.2.7 release is really very fast and
trigger is significantly more stable also especially at high
frequencies.
So thanks You a lot, no words...
...as usual I'm speechless...
RESPECT!!!
Hayo You are the best one!!!
Thank You so much!!!
Luc schrieb:
> I adjusted the delay between channels and everything works fine, but> with the time base adjusted to 20nS there is a 4nS delay between CH2 and> CH1 and the failure occurs only with the time base set at 20nS.
Hayo and all, please refer to my screenshoot.
As usual, this my reporting is not intended as a criticism but as a
simple answer to your kind invitation to report any problems, so please
excuse my rudeness if You can Hayo.
About the above reported problem I tried to explore the question, so I
used both W2012A and W2022A also with old firmware release.
In this way I noticed the problem already exist with the previus
firmware release.
The new 1.2.BF.2.7 also have it while previus 1.2.BF.2.0 expresses the
problem differently.
The my screenshots show W2022A's behavior when 1.2.BF.2.0 firmware is
used and the behavior change using the 1.2.BF.2.7.
The behavior of a W2012A with new 1.2.BF.2.7. is also shown.
As You can see there is a Time Base's value in which the two channels
are out of phase and this appears to depend on firmware because it
occurs with the same firmware on the same Time Base value, but with a
different firmware occurs at a different Time Base value.
I repeat, this my reporting is not intended as a criticism but it is
simply for knowledge, I do not pretend that the problem is solved, mine
is a simple signaling for knowledge.
I hope I explained and I hope not to seem rude.
Also I know I'm boring so You be patient, please and sorry if You can,
please.
Hayo W. schrieb:
>I compared the BF.2.2 (with old assembler coding) and the BF.2.6 with>optimized Coding.>>Settings on the W2014A are default (Default Setup) - means 50ns/div and>all channels active. At Average in Invinite mode.>>Ergebnis / Result:>>BF.2.2 / Average off -> 165 Frames/min>BF.2.2 / Average on -> 123 Frames/min>BF.2.6 / Average off -> 200 Frames/min>BF.2.6 / Avarage on -> 195 Frames/min
This is really very impressive!
As I already got to write, the new firmware is light years away from the
Welec, it is another world.
It is as how to use a different DSO, a new more better DSO!
RESPECT and thank You very much Hayo!!!
Hayo W. schrieb:
>Was ganz Anderes:>>Ich optimiere gerade weiter an der Assemblerroutine. Die aktuelle>Refreshrate liegt jetzt bei 245 Frames/min (Avrg off)!!>>Ich hätte gar nicht vermutet dass da noch so viel Potential drinsteckt.
Hayo W. schrieb:
>In der alten Assemblerroutine wurde für jeden Wert geprüft ob er>invertiert oder gemittelt werden sollte.>>D.h das sind 16383 if(Invert) Abfragen und nochmal 16383 if(Average)>Abfragen.>>Bei den neuen Versionen wird jeweils nur noch 1 Mal abgefragt!!!>Weiterhin werden jetzt 3 Übergabeparameter weniger beim Aufruf benötigt.>>Das macht das Ganze doch schon etwas schlanker und schneller.
Really incredible!
I do not understand how You can get similar results...
...no words, RESPECT!!!
@all
Last but not least.
About the change of line and termination resistance for the MAX1211 I
understand that the suggested values by the AD8131 datasheet are 24,9ohm
1% for the line resistors and 150ohm 1% for the termination resistor.
However, the values in the BlueFlash firmware are 24ohm, 33ohm or Add
On.
I guess 24ohm refers exactly to the 24ohm 1% value for the line
resistances, so welding the 24.5ohm 1% resistors in the Pre Gain's
configuration must set Add On and must to compile the firmware with the
correct tc_vars.cpp file.
Is this correct?
And how is possible to adjust the line and termination's resistors
value?
Is there need a signal generator like a Leader 3216 or so?
Many thanks to all and best regards.
Vielen Dank!!!
Gruß Luc
moin allerseits,
nach Luc's Darstellung haben wir hier einnen Delay von CH.1 zu Ch.2.
Ich habe das mal mit der FW2.7 nachgestellt.
Ich habe folgende Einstellungen:
Signal 1kHz Rechteck vom Oszi auf beide Kanäle.
Tastkopf-Einstellungen stehen auf 10:1
TB-Einstellungen sind 2nS, 20nS, 50nS, 100nS, 200nS
In der Hardware-Einstellung bin ich dort mit den Delays für Ch.1
nachgezogen, an den Tastköpfen liegt es nicht, da ich Diese mehrmals
vertauscht habe.
Auf den Shots sieht man die nachgezogenen Delay-Einstellungen von CH.1
Gruß Michael
Luc schrieb:> Hi Hayo and guys all!>> First, Hayo thanks You very much for the latest 1.2.BF.2.7 firmware's> release!> You are really very kindly, therefore thanks You a lot for the amazing> job and free time You provided generously to us!!!
Let's thank my wife for tolerating my crazy hobby and all the time I
spend with it ;-)
> As usual, this my reporting is not intended as a criticism but as a> simple answer to your kind invitation to report any problems, so please> excuse my rudeness if You can Hayo.
There is no need for Your excuse. Without the detailed tests and bug
reports from You and all the guys here I wouldn't be able to optimize
the Firmware in this way.
> About the above reported problem I tried to explore the question, so I> used both W2012A and W2022A also with old firmware release.> In this way I noticed the problem already exist with the previus> firmware release.> The new 1.2.BF.2.7 also have it while previus 1.2.BF.2.0 expresses the> problem differently.
This is quite interresting. Until now I had no time to check it, but it
is on my to do list.
> @all> Last but not least.> About the change of line and termination resistance for the MAX1211 I> understand that the suggested values by the AD8131 datasheet are 24,9ohm> 1% for the line resistors and 150ohm 1% for the termination resistor.
The values for the 24ohm setting are determined by Jürgen who uses
24,9ohm resitors if I remember right. So the scaling factors should
match.
> I guess 24ohm refers exactly to the 24ohm 1% value for the line
resistances, so welding the 24.5ohm 1% resistors in the Pre Gain's
> configuration must set Add On and must to compile the firmware with the> correct tc_vars.cpp file.> Is this correct?
If Your resistors are not matching the values which are needed for the
current adjustment You have to determine Your own scaling factors.
There are two sets of factors in the tc_vars.cpp which have to be
adjusted.
float ScaleFactor[16][5] at line 1180 -> amplitude
float DAC_ScaleFactor[3][5] at line 1230 -> zero position
Both have influance to each other! So it is a little bit tricky to
adjust it - but don't be afraid, try it!
> And how is possible to adjust the line and termination's resistors> value?
For the amplitude adjusting I used a normal DC-supply and a multimeter.
> Is there need a signal generator like a Leader 3216 or so?
No, there is no need. This is only for testing hi frequency behaviour.
ciao Hayo
Hallo!
@Hayo
Ich habe dein Email leider nicht bekommen! Sende es mir bitte nochmal
auf die Email-Adresse in meinem Source-Code.
Zu dem Filterthema und der Rechenperformance:
Ich lese gerade da etwas von float und co. Sowas Rechenintensives gibts
bei der LEON3 im Moment nicht. Man könnte jede float*int Operation in
eine (int*int) geschoben um n Bits umwandeln.
Aus y = (int)(0.3333*(float)x); könnte man bspw. Konstante =
0.3333*(2^16) = 21843 machen und dann y = (21843*x)>>16; dem NIOSI
Rechnen lassen.
Für die Interpolationsfilter schlage ich einen M-tel Bandfilter vor, ist
zwar nicht der einfachste, dafür braucht er für einen FIR-Filter nur
sehr wenig Multiplikationen.
Zum Display:
Beim Leon3 Design ohne der Minimal Gui hatte ich einmal ungefähr 50fps
gemessen!
MfG
Alexander
alex008 schrieb:> Hallo!>> @Hayo> Ich habe dein Email leider nicht bekommen! Sende es mir bitte nochmal> auf die Email-Adresse in meinem Source-Code.
Ist Deine SFN-Email nicht gültig? Ich hatte selbige benutzt.
> Zu dem Filterthema und der Rechenperformance:>> Ich lese gerade da etwas von float und co. Sowas Rechenintensives gibts> bei der LEON3 im Moment nicht. Man könnte jede float*int Operation in> eine (int*int) geschoben um n Bits umwandeln.> Aus y = (int)(0.3333*(float)x); könnte man bspw. Konstante => 0.3333*(2^16) = 21843 machen und dann y = (21843*x)>>16; dem NIOSI> Rechnen lassen.
Das hatten wir so in den BF.1.x Versionen. Seit BF.2.x werden die
Floating Point Berechnungen nur noch beim Systemstart oder beim Ändern
der Hardwareeinstellungen ausgeführt um die Lookup Tabellen zu
berechnen. Danach wird nur noch über indizierten Zugriff skaliert - ist
schön schnell.
> Für die Interpolationsfilter schlage ich einen M-tel Bandfilter vor, ist> zwar nicht der einfachste, dafür braucht er für einen FIR-Filter nur> sehr wenig Multiplikationen.
Den kenne ich nicht, ich lass mich aber gerne schlau machen, ich lerne
gerne dazu.
> Zum Display:> Beim Leon3 Design ohne der Minimal Gui hatte ich einmal ungefähr 50fps> gemessen!
In solche Bereiche werden wir beim NIOS nie vorstoßen, aber so wie es
jetzt läuft ist es zumindest schon ganz gut brauchbar und deutlich
angenehmer als mit der original Firmware.
Gruß Hayo
hallo zusammen,
hat eigentlich jemand das screenshot- tool (bf oder os) mit windows 7
x64 im einsatz?
oder gar erfolgreich mit einem usb- rs232 adapter getestet?
> Hi Hayo, Jürgen and guys all!
Hayo W. schrieb:
>Let's thank my wife for tolerating my crazy hobby and all the time I>spend with it ;-)
Very well, Hayo, I understand.
Then I thanks your wife for her patience, so I thank You very much Mrs.
Blueflash!
Ich danke Ihnen sehr Frau Blueflash!
About of the my reported phase displacement problem.
Hayo W. schrieb:
>This is quite interresting. Until now I had no time to check it, but it>is on my to do list.
Hayo, You are really very kind!
However do not worry, is possible to eliminate the problem adding or
subtracting the known phase shift in relation to the used time base when
making measurements.
A little like that used for measuring the rise time with analog
oscilloscopes where You need to add the typical instrument's rise time.
About changing the line and termination resistors.
Hayo W. schrieb:
>The values for the 24ohm setting are determined by Jürgen who uses>24,9ohm resitors if I remember right. So the scaling factors should>match.
Hayo, as usual You are right!
I re-read old messages and on 26.10.2010 19:11
Jürgen schrieb:
>Deshalb nochmal etwas geänderte Kalibrierfaktoren für 2 x 24.9 Ohm und>150 Ohm: ScaleFactor: 3.309 fuer 1-er und 2-er und 2.697 fuer 5-er>DAC-Scalefactor: 0.6614, 1.3228 und 3.307 entsprechend
So thanks You very much Jürgen, also You are really very kind!
Hayo and Jürgen, RESPECT!!!
About the line's and termination's resistors tuning.
Hayo W. schrieb:
>For the amplitude adjusting I used a normal DC-supply and a multimeter.
And about a need of signal generator like a Leader 3216 or so.
Hayo W. schrieb:
>No, there is no need. This is only for testing hi frequency behaviour.
Hayo, thanks a lot for these useful information that make me happy!
RESPECT!!!
Again many thanks to You Hayo, really thanks very much to all You!!!
Vielen Dank!!!
Gruß Luc
Hi Leute,
ein kurzes Lebenszeichen von mir. Ich bin zur Zeit beruflich ziemlich
eingespannt und komme daher nicht zu den eigentlich wichtigen Dingen des
Lebens - den Hobbies. Ihr kennt das ja schon, wenn es sich wieder
entspannt bin ich wieder voll dabei.
Hi Folks,
a short feedback from me. At this time I'm a little bit busy (as SAP
consultant) and got no time for the important things in life - the
hobbies. But You know, if it is becoming relaxed I will be back soon.
So long
Hayo
alex008 schrieb:> Hallo!>> @Hayo> Ich habe dein Email leider nicht bekommen! Sende es mir bitte nochmal> auf die Email-Adresse in meinem Source-Code.>> Zu dem Filterthema und der Rechenperformance:>> Ich lese gerade da etwas von float und co. Sowas Rechenintensives gibts> bei der LEON3 im Moment nicht. Man könnte jede float*int Operation in> eine (int*int) geschoben um n Bits umwandeln.> Aus y = (int)(0.3333*(float)x); könnte man bspw. Konstante => 0.3333*(2^16) = 21843 machen und dann y = (21843*x)>>16; dem NIOSI> Rechnen lassen.
Gibt es sowohl in "meinem" Branch in der OS, genauso ist es
- entgegen Absprachen - in die BF eingeflossen.
Ebenso stammt btw. die Geschichte mit den Abfragen (16384 ggü. 1)
aus einem gewissen Branch in der OS
>> Für die Interpolationsfilter schlage ich einen M-tel Bandfilter vor, ist> zwar nicht der einfachste, dafür braucht er für einen FIR-Filter nur> sehr wenig Multiplikationen.
Für Interpolationsfilter gibt es noch einige andere Möglichkeiten ...
>> [...]
Grüße,
rowue
Rolf W. schrieb:>> Ich lese gerade da etwas von float und co. Sowas Rechenintensives gibts>> bei der LEON3 im Moment nicht. Man könnte jede float*int Operation in>> eine (int*int) geschoben um n Bits umwandeln.>> Aus y = (int)(0.3333*(float)x); könnte man bspw. Konstante =>> 0.3333*(2^16) = 21843 machen und dann y = (21843*x)>>16; dem NIOSI>> Rechnen lassen.>> Gibt es sowohl in "meinem" Branch in der OS, genauso ist es> - entgegen Absprachen - in die BF eingeflossen.
Hallo Rolf,
nein ist es nicht - die Shiftoperationen stammen ursprünglich von mir
und sind auch schon länger in Betrieb. Wie weiter oben beschrieben habe
ich nach unserem Treffen auf Lookup-Tabellen umgestellt weil man damit
flexibler die Faktoren einstellen kann. Dabei habe ich mich aber an
keinerlei Vorlagen orientiert sondern das selbst entwickelt.
> Ebenso stammt btw. die Geschichte mit den Abfragen (16384 ggü. 1)> aus einem gewissen Branch in der OS
Nein auch das stammt nicht aus der OS. Ich bin eher zufällig über das
Thema gestolpert als ich auf Anfrage hier im Forum die Averagefunktion
etwas aufbohren wollte (siehe weiter oben). Ich erinnere mich aber, dass
wir über etwas ähnliches im Zusammenhang mit der FFT gesprochen haben.
>> Für die Interpolationsfilter schlage ich einen M-tel Bandfilter vor, ist>> zwar nicht der einfachste, dafür braucht er für einen FIR-Filter nur>> sehr wenig Multiplikationen.>> Für Interpolationsfilter gibt es noch einige andere Möglichkeiten ...
Immer raus damit. Wie schon gesagt suche ich schon seit einiger Zeit
nach einer Coding-Umsetzung für den sin(x)/x Algorithmus.
Desweiteren hattest Du ja gesagt, dass Du bei der Floatstr-Klasse
einiges geändert hast, das wäre auch interessant.
Gruß Hayo
Hi Hayo and all
Hayo W. schrieb:>> Is HOLDOFF working?
...
> If I remember right, the range (on hardware side) for HOLDOFF is much> smaller than 2 seconds but I have to check it. Maybe I have to limit it> in the firmware.
Hayo, you are right. I checked the behavior of the HOLDOFF function
using a proper pulse train and found it to be working up to a setting of
134 ms. For values of 135 ms or larger, the setting is ignored.
Rainer
Hayo W. schrieb:> Rolf W. schrieb:>>>> Ich lese gerade da etwas von float und co. Sowas Rechenintensives gibts>>> bei der LEON3 im Moment nicht. Man könnte jede float*int Operation in>>> eine (int*int) geschoben um n Bits umwandeln.>>> Aus y = (int)(0.3333*(float)x); könnte man bspw. Konstante =>>> 0.3333*(2^16) = 21843 machen und dann y = (21843*x)>>16; dem NIOSI>>> Rechnen lassen.>>>> Gibt es sowohl in "meinem" Branch in der OS, genauso ist es>> - entgegen Absprachen - in die BF eingeflossen.>> Hallo Rolf,
Hi Hayo,
>> nein ist es nicht - die Shiftoperationen stammen ursprünglich von mir> und sind auch schon länger in Betrieb.
Was alex beschrieb sind float - int Umwandlungen um Int-Float
Konvertierungen für (int)(float)a*(float)b) zu vermeiden.
Also das, was ich Anfang Juli in die OS eingeführt habe.
Schau mal bei Dir in die tc_vars.h Zeilen 1622ff (MultiplyFloatInt).
> Wie weiter oben beschrieben habe> ich nach unserem Treffen auf Lookup-Tabellen umgestellt weil man damit> flexibler die Faktoren einstellen kann. Dabei habe ich mich aber an> keinerlei Vorlagen orientiert sondern das selbst entwickelt.>>> Ebenso stammt btw. die Geschichte mit den Abfragen (16384 ggü. 1)>> aus einem gewissen Branch in der OS>> Nein auch das stammt nicht aus der OS. Ich bin eher zufällig über das> Thema gestolpert als ich auf Anfrage hier im Forum die Averagefunktion> etwas aufbohren wollte (siehe weiter oben). Ich erinnere mich aber, dass> wir über etwas ähnliches im Zusammenhang mit der FFT gesprochen haben.
Bei der FFT haben wir über die Wurzel (Math_Sqrt, tc_vars.h, Z 1686ff)
und ggf. Nutzung der FFT zur Faltung (im Realraum ist Faltung einfach
nur böse (skaliert mit N^2, also gar nicht)) gesprochen. Aber ich habe
Dir dabei erzählt, dass ich die C-Routinen von Guido gefixt und
überarbeitet habe. In diesem Zusammenhang habe ich Dir dann auch
erzählt,
dass ich aus den 16384 Abfragen (Invert) eine gemacht habe. Du wolltest
Dir dann die Assembler-Routinen entsprechend ansehen ...
>>>> Für die Interpolationsfilter schlage ich einen M-tel Bandfilter vor, ist>>> zwar nicht der einfachste, dafür braucht er für einen FIR-Filter nur>>> sehr wenig Multiplikationen.>>>> Für Interpolationsfilter gibt es noch einige andere Möglichkeiten ...>> Immer raus damit. Wie schon gesagt suche ich schon seit einiger Zeit> nach einer Coding-Umsetzung für den sin(x)/x Algorithmus.
Wenn da im Smith nicht's steht (würde mich wundern, den Link hatte
ich Dir ja geschickt), schau mal im "Numerical Receipes" - ist ein
Standard-Werk für Numerik in jeder Richtung ...
>> Desweiteren hattest Du ja gesagt, dass Du bei der Floatstr-Klasse> einiges geändert hast, das wäre auch interessant.
Wie Du sicher noch weisst, arbeite ich offen im branch "rowue-signal"
im SVN bei Sourceforge. Allerdings hatten wir uns ja auch drauf
geeinigt, dass die Sachen des Anderen erst nach der Veröffentlichung
übernommen werden. Mit Veröffentlichung meine ich: eine entsprechend
getaggte Release.
>>> Gruß Hayo
Grüße,
rowue
Rolf W. schrieb:> Hayo W. schrieb:>> Rolf W. schrieb:>>>>>> [...]> Bei der FFT haben wir über die Wurzel (Math_Sqrt, tc_vars.h, Z 1686ff)> und ggf. Nutzung der FFT zur Faltung (im Realraum ist Faltung einfach> nur böse (skaliert mit N^2, also gar nicht)) gesprochen. [...]
Sorry: skaliert N*M also N^2 für N=M
Rolf W. schrieb:> Was alex beschrieb sind float - int Umwandlungen um Int-Float> Konvertierungen für (int)(float)a*(float)b) zu vermeiden.> Also das, was ich Anfang Juli in die OS eingeführt habe.> Schau mal bei Dir in die tc_vars.h Zeilen 1622ff (MultiplyFloatInt).
Ach so, das hatte ich missverstanden. Allerdings hatte ich schon bei
unserem Treffen gesagt dass ich die Inline-Funktionen von Dir verwenden
wollte. Du hattest ja auch gesagt dass diese schon geprüft sind.
Ich hoffe das ist jetzt ok so, oder?
>>> Ebenso stammt btw. die Geschichte mit den Abfragen (16384 ggü. 1)>>> aus einem gewissen Branch in der OS>>>> Nein auch das stammt nicht aus der OS. Ich bin eher zufällig über das>> Thema gestolpert als ich auf Anfrage hier im Forum die Averagefunktion>> etwas aufbohren wollte (siehe weiter oben). Ich erinnere mich aber, dass>> wir über etwas ähnliches im Zusammenhang mit der FFT gesprochen haben.>> Bei der FFT haben wir über die Wurzel (Math_Sqrt, tc_vars.h, Z 1686ff)> und ggf. Nutzung der FFT zur Faltung (im Realraum ist Faltung einfach> nur böse (skaliert mit N^2, also gar nicht)) gesprochen. Aber ich habe> Dir dabei erzählt, dass ich die C-Routinen von Guido gefixt und> überarbeitet habe. In diesem Zusammenhang habe ich Dir dann auch> erzählt, dass ich aus den 16384 Abfragen (Invert) eine gemacht habe.> Du wolltest Dir dann die Assembler-Routinen entsprechend ansehen ...
Stimmt, Du hast recht. Wir hatten das im Zusammenhang mit den C-Routinen
angesprochen. Ich hatte allerdings danach die Assemblerroutine nicht
mehr weiter untersucht. Erst als das Thema Average aufkam bin ich quasi
von hinten durch die kalte Küche wieder darauf gestoßen.
Sorry, ist wohl Altersdemenz ;-)
>>>> Für die Interpolationsfilter schlage ich einen M-tel Bandfilter vor, ist>>>> zwar nicht der einfachste, dafür braucht er für einen FIR-Filter nur>>>> sehr wenig Multiplikationen.>>>>>> Für Interpolationsfilter gibt es noch einige andere Möglichkeiten ...>>>> Immer raus damit. Wie schon gesagt suche ich schon seit einiger Zeit>> nach einer Coding-Umsetzung für den sin(x)/x Algorithmus.> Wenn da im Smith nicht's steht (würde mich wundern, den Link hatte> ich Dir ja geschickt), schau mal im "Numerical Receipes" - ist ein> Standard-Werk für Numerik in jeder Richtung ...
Ich hab da aus Zeitmangel nur kurz reingesehen, gibts da auch C-Coding
Beispiele für diese Algorithmen?
>> Desweiteren hattest Du ja gesagt, dass Du bei der Floatstr-Klasse>> einiges geändert hast, das wäre auch interessant.>> Wie Du sicher noch weisst, arbeite ich offen im branch "rowue-signal"> im SVN bei Sourceforge. Allerdings hatten wir uns ja auch drauf> geeinigt, dass die Sachen des Anderen erst nach der Veröffentlichung> übernommen werden. Mit Veröffentlichung meine ich: eine entsprechend> getaggte Release.
Ja deswegen habe ich auch noch nichts aus der Floatstr übernommen. Ist
das denn noch "under construction" oder bist Du da schon fertig?
Gruß Hayo
Hayo W. schrieb:> Rolf W. schrieb:>>> Was alex beschrieb sind float - int Umwandlungen um Int-Float>> Konvertierungen für (int)(float)a*(float)b) zu vermeiden.>> Also das, was ich Anfang Juli in die OS eingeführt habe.>> Schau mal bei Dir in die tc_vars.h Zeilen 1622ff (MultiplyFloatInt).>> Ach so, das hatte ich missverstanden. Allerdings hatte ich schon bei> unserem Treffen gesagt dass ich die Inline-Funktionen von Dir verwenden> wollte. Du hattest ja auch gesagt dass diese schon geprüft sind.>> Ich hoffe das ist jetzt ok so, oder?
Nein, die musst Du jetzt wieder ausbauen ;)
(lass drin, so wichtig ist die Routine auch nicht)
Ich hatte gesagt, dass diese geprüft sind, aber auch, dass
ich gerne die Übernahme nach der Release hätte ;)
>>>>> [Abfragen ...]>> Stimmt, Du hast recht. Wir hatten das im Zusammenhang mit den C-Routinen> angesprochen. Ich hatte allerdings danach die Assemblerroutine nicht> mehr weiter untersucht. Erst als das Thema Average aufkam bin ich quasi> von hinten durch die kalte Küche wieder darauf gestoßen.>> Sorry, ist wohl Altersdemenz ;-)
Hast Du Deine Notizen (aus den Augen) verloren? ;) - Sonst, dass
war kurz bevor wir über die RMS-Messung über das Histogram gesprochen
haben (ähnlich wie das Stefan mit dem Mittelwert gemacht hat, bloß
Null-Referenz beachten, quadrieren und Wurzel nicht vergessen)
Average: Laß raten, Du willst das Averaging über N Perioden einbauen?
(Wobei das Averaging im Orginal Source eh für das ist, was ich hier
nicht schreiben sollte ;)
>>>>>>> [Interpolation]>> Ich hab da aus Zeitmangel nur kurz reingesehen, gibts da auch C-Coding> Beispiele für diese Algorithmen?
Im DSP-Guide: Nein - Smith verwendet eine Basic-artige Pseudo-Sprache
um den Code zu zeigen. Er sieht den Code als eine Art erweiterten
Text - sprich: erst erklärt er theoretisch, was er macht, dann
kommt der Pseudo-Code und dann wird der Code noch mal im Text
erklärt - zumeist auch mit dem Hinweis, dass man den Code wie
Text lesen und verstehen soll. Es geht dabei darum, dass verstanden
wird, wie und warum etwas gemacht wird und somit Dinge wie z.B.
mindestens überflüssige "Optimierungen" (die dann gerne die
Skalierung zu höheren Ordnungen beeinflussen) vermieden werden.
C-Code dürftest Du im entsprechenden "Numerical Receipes" finden.
Allerdings würde ich grundsätzlich in unserem Anwendungsbereich
den "DSP-Guide" vorziehen. (Und komme selbst zu selten dazu ihn
weiterzulesen)
Für die Mitleser: Der "DSP-Guide" ist das Buch "The Scientist and
Engineer's Guide to Digital Signal Processing" von Steven W. Smith.
Es kann über http://www.dspguide.com/ auch für Lau als PDF runtergeladen
werden und ist m.E. sehr lesenswert - wer es nutzt und nachher Kohle
in dem Bereich macht, sollte es sich als gebundene Ausgabe kaufen)
>>>> Desweiteren hattest Du ja gesagt, dass Du bei der Floatstr-Klasse>>> einiges geändert hast, das wäre auch interessant.>>>> Wie Du sicher noch weisst, arbeite ich offen im branch "rowue-signal">> im SVN bei Sourceforge. Allerdings hatten wir uns ja auch drauf>> geeinigt, dass die Sachen des Anderen erst nach der Veröffentlichung>> übernommen werden. Mit Veröffentlichung meine ich: eine entsprechend>> getaggte Release.>> Ja deswegen habe ich auch noch nichts aus der Floatstr übernommen. Ist> das denn noch "under construction" oder bist Du da schon fertig?
Sagen wir es so: es würde mich sehr freuen, wenn Du mit der Übernahme
von Code aus der OS warten könntest, bis die entsprechende OS-Version
released wurde. Wir können da gerne auch sowas wie einen
"Maintainer-Timeout" ausmachen (nach dem Motto: wenn der Code da
n-Monate drin steht, aber nicht released wurde, ist er frei) - aber
generell mache ich meine
Sachen für die "OS" und würde sich auch am liebsten dort als erstes
veröffentlicht sehen.
>> Gruß Hayo
Grüße,
rowue
PS: Denkst Du an die "commits"? Ich würde mir z.B. gerne auch mal die
Geschichten die Du am Trigger gemacht hast ansehen. Und da sind
kleinzellige Commits einfach netter als "plain Source".
Hallo!
@Rolf
Ich habe damals für das erste Video, dass mir Bruno geschnitten hatte,
ein Sin(x)/x Interpolation als Polyphasenfilter eingebaut (LEON3
optimiert). Den Code habe ich dazu nicht entfernt. Leider wird er
momentan nicht ausgeführt, da solche Dinge intelligent in der Software
platziert werden müssen, und bei mir noch nicht die Zeit gekommen ist,
wo ich mich um das Kümmern konnte.
Zumindest geht seit kurzem das manuelle Verstellen des DC-Offsets beim
LEON3-Design.
Jetzt ist einmal das längst überfällige Einpflegen der Verbesserungen
von Robert an der Reihe. Danach muss ein sehr wichtiges Doku update her,
und dann gibts wieder einmal ein nettes Video.
Des Weiteren werde ich versuchen, das GDB-Debugging für den LEON3 zum
Laufen zu bekommen.
MfG
Alexander
alex008 schrieb:> Hallo!>> @Rolf> Ich habe damals für das erste Video, dass mir Bruno geschnitten hatte,> ein Sin(x)/x Interpolation als Polyphasenfilter eingebaut (LEON3> optimiert). Den Code habe ich dazu nicht entfernt. Leider wird er> momentan nicht ausgeführt, da solche Dinge intelligent in der Software> platziert werden müssen, und bei mir noch nicht die Zeit gekommen ist,> wo ich mich um das Kümmern konnte.
Hi Alex,
meines Wissens suchte Hayo den Code für sinc(x), aber ich
kann mir das gerne auch nochmal ansehen, wobei ich allerdings
gerade "Müll rausbringen" und "eingeschlagene Scheiben reparieren"
auf dem Programm habe (auf Hochdeutsch: einmal 'ne Routine die
unter das KWKG fällt entmüllen und einmal einen von mir eingebauten
Bug beseitigen). Für die Signal-Reperatur (siehe unten) habe ich
mir schon ein-zwei Gedanken gemacht, wo ich mir aber noch ansehen
wollte, ob das physikalisch Sinn macht. Aber auf alle Fälle danke
für den Tip!
>> Zumindest geht seit kurzem das manuelle Verstellen des DC-Offsets beim> LEON3-Design.
Cool!
> Jetzt ist einmal das längst überfällige Einpflegen der Verbesserungen> von Robert an der Reihe. Danach muss ein sehr wichtiges Doku update her,> und dann gibts wieder einmal ein nettes Video.
Nice - kurze Frage: habt Ihr mal geprüft ob das Problem mit
den "nicht äquidistanten Sample-Raten"
(http://sourceforge.net/apps/trac/welecw2000a/ticket/53) auch beim Leon3
auftritt? Ich würde
zwar erstmal auf Nein tippen, aber ein kurzer Test wäre gut ;)
>> Des Weiteren werde ich versuchen, das GDB-Debugging für den LEON3 zum> Laufen zu bekommen.>> MfG> Alexander
Grüße,
rowue
Rolf W. schrieb:> Nein, die musst Du jetzt wieder ausbauen ;)
Aarrrgh... :-)
> Hast Du Deine Notizen (aus den Augen) verloren? ;)
In der Tat, die Notizzettel stapelten sich hier zeitweise 10cm hoch, da
die Testergemeinde hier so fleißig war, dass man kaum hinterherkam.
- Sonst, dass
> war kurz bevor wir über die RMS-Messung über das Histogram gesprochen> haben (ähnlich wie das Stefan mit dem Mittelwert gemacht hat, bloß> Null-Referenz beachten, quadrieren und Wurzel nicht vergessen)
Ich hab die Routine kurz nach unserem Treffen programmiert und
eingebaut. Zur Zeit ist sie aber auskommentiert da die Werte etwas von
denen der ursprünglichen Routine abwichen. Ich wollte da nochmal
genauere Tests und Messungen machen.
> Average: Laß raten, Du willst das Averaging über N Perioden einbauen?
Jupp, hab ich auch schon in der aktuellen Version.
> (Wobei das Averaging im Orginal Source eh für das ist, was ich hier> nicht schreiben sollte ;)
Stimmt, aber ich habe mich immer erfolgreich vor der Assemblerroutine
gedrückt. Dabei mußte ich jetzt feststellen, dass es doch nicht so
schwer war sich da reinzuarbeiten. Ist wohl doch noch was von früher
hängengeblieben.
> Im DSP-Guide: Nein - Smith verwendet eine Basic-artige Pseudo-Sprache> um den Code zu zeigen.
Hab mir gestern doch mal die Zeit genommen da reinzusehen, die Neugierde
ist doch stärker gewesen als die Zeitnot. In weiten Teilen entspricht
das Buch meinen Studienunterlagen zu "Digitale Systeme" und "DSP". Nur
ist es netter geschrieben.
> C-Code dürftest Du im entsprechenden "Numerical Receipes" finden.
Hab mal kurz gesucht, es gibt auf jeden Fall ein ganzes Kapitel zu
Interpolationen.
> Sagen wir es so: es würde mich sehr freuen, wenn Du mit der Übernahme> von Code aus der OS warten könntest, bis die entsprechende OS-Version> released wurde.
Ich komme jetzt sowieso erstmal nicht dazu, da bei mir beruflich
"landunter" herrscht. Zum Jahreswechsel hauen alle Kunden ihr Restbudget
raus und man weiß nicht was man zuerst machen soll.
> PS: Denkst Du an die "commits"? Ich würde mir z.B. gerne auch mal die> Geschichten die Du am Trigger gemacht hast ansehen. Und da sind> kleinzellige Commits einfach netter als "plain Source".
Hab ich versucht. Beim Kopieren in die lokalen Ordner sind wohl
irgendwie die Steuerdateien über Bord gegangen. Seit dem funktioniert
das Update irgendwie nicht mehr. Ich glaube ich muß das alles nochmal
neu anlegen. Irgendwie will mich das SVN nicht so richtig....knirsch.
Gruß Hayo
alex008 schrieb:> Hallo!>> @Rolf> Ich habe damals für das erste Video, dass mir Bruno geschnitten hatte,> ein Sin(x)/x Interpolation als Polyphasenfilter eingebaut (LEON3> optimiert). Den Code habe ich dazu nicht entfernt.
Das ist es doch. Kannst Du mir den Code zukommen lassen, oder mir genau
sagen wo ich den ohne mir einen Wolf zu suchen finde?
Gruß Hayo
Ach ja, einen hab ich noch an Rolf.
Du hattest ja im C-Coding von Guido einen Fehler gefunden und
korrigiert. Bei mir ist das C-Coding zwar nicht aktiv aber noch
vorhanden. Ich würde das ganz gerne korrigieren, damit da nicht das
falsche Coding vor sich hin schlummert. Welche Routine müßte ich von Dir
übernehmen - und wäre das für Dich ok?
Gruß Hayo
Hayo W. schrieb:> Ach ja, einen hab ich noch an Rolf.>> [Fehler in Guidos Coding]
Da brauchst Du keine Routine von mir zu übernehmen:
gehe einfach in hardware_t.cpp, Routine "Hardware::ADC_ProcessData"
und schau Dir an, was dort mit "chan_addr" im Highspeed-Modus
passiert ... - innerhalb von 10 Minuten solltest Du den Fehler
haben.
>> Gruß Hayo
Grüße,
rowue
Hayo W. schrieb:> Rolf W. schrieb:>>> [Ausbauen und Nutzer ...]>> - Sonst, dass>> [RMS]>> Ich hab die Routine kurz nach unserem Treffen programmiert und> eingebaut. Zur Zeit ist sie aber auskommentiert da die Werte etwas von> denen der ursprünglichen Routine abwichen. Ich wollte da nochmal> genauere Tests und Messungen machen.
Also hier waren die Werte - auch in Bezug auf die generelle
Genauigkeit des QMs und des Gerätes - deutlich im grünen Bereich ...
>>> [Average]>> Jupp, hab ich auch schon in der aktuellen Version.
Steht bei mir noch auf dem Zettel - nach dem Aufräumen und
Selbst-eingebauten-Bug fixen ...
>>> [Averaging in der Assembler-Routine ....]>> Stimmt, aber ich habe mich immer erfolgreich vor der Assemblerroutine> gedrückt. Dabei mußte ich jetzt feststellen, dass es doch nicht so> schwer war sich da reinzuarbeiten. Ist wohl doch noch was von früher> hängengeblieben.
Vielleicht sollte ich die auch noch mal verarzten und vom
Speed her mit der C-Routine vergleichen - Bei der Multiplikationsroutine
soll das z.B. Faktor 1.5 - 2 geben ...
>>>> Im DSP-Guide: Nein - Smith verwendet eine Basic-artige Pseudo-Sprache>> um den Code zu zeigen.>> Hab mir gestern doch mal die Zeit genommen da reinzusehen, die Neugierde> ist doch stärker gewesen als die Zeitnot. In weiten Teilen entspricht> das Buch meinen Studienunterlagen zu "Digitale Systeme" und "DSP". Nur> ist es netter geschrieben.
O.K. - ich fand die Darstellung generell ganz gut - wenn es Dir
kein Wissen bringt - o.k.
>>> C-Code dürftest Du im entsprechenden "Numerical Receipes" finden.>> Hab mal kurz gesucht, es gibt auf jeden Fall ein ganzes Kapitel zu> Interpolationen.
Unter anderem ...
>>> Sagen wir es so: es würde mich sehr freuen, wenn Du mit der Übernahme>> von Code aus der OS warten könntest, bis die entsprechende OS-Version>> released wurde.>> Ich komme jetzt sowieso erstmal nicht dazu, da bei mir beruflich> "landunter" herrscht. Zum Jahreswechsel hauen alle Kunden ihr Restbudget> raus und man weiß nicht was man zuerst machen soll.
Sowas kenne ich auch noch ... Bei mir sind es jetzt Abstracts, etc
>>>> PS: Denkst Du an die "commits"? Ich würde mir z.B. gerne auch mal die>> Geschichten die Du am Trigger gemacht hast ansehen. Und da sind>> kleinzellige Commits einfach netter als "plain Source".>> Hab ich versucht. Beim Kopieren in die lokalen Ordner sind wohl> irgendwie die Steuerdateien über Bord gegangen. Seit dem funktioniert> das Update irgendwie nicht mehr. Ich glaube ich muß das alles nochmal> neu anlegen. Irgendwie will mich das SVN nicht so richtig....knirsch.
Eigentlich ist das SVN sehr freundlich - Ist die Frage, was sich mehr
lohnt: Auschecken und über find, etc (rsync?) die "Steuerdateien"
(alle in .svn Verzeichnissen) auf den anderen Tree kopieren, oder
den trunk "wegwerfen" und von Dir neu importieren ....
>> Gruß Hayo
Grüße,
rowue
Hallo alle zusammen.
Ich verfolge diesen Thread mit viel Interesse, weil sich unser DSO damit
durch die Bemühungen und den bewundernswerten Einsatz etlicher
Spezialisten spürbar verbessert. Dank an euch alle.
Die Länge des Threads macht allerdings Schwierigkeiten (lange
Ladezeiten, Fehlermeldung beim Laden). Daher mein Vorschlag, einen
vierten Teil zu starten. Das sollte aber von einem Kenner geschehen und
nicht von einem Nobody wie mir.
Macht weiter so.
Hallo!
@Hayo:
Die Sinc(x) Interpolation ist die Interpolate Funktion in DSO_Signal.c
(habe ich dir schon geschickt).
Zu der Sinc(x) Funktion empfiehlt sich noch eine Dreieck-Funktion zu
generieren (Interpolation ohne Überschwinger). Das I8 steht bei
FilterI8.c für die 8-fach Interpolation. Octave Skript zum Generieren
der Filterdaten wie FilterI8.c hast du auch von mir bekommen.
Falls dir der uSample Datentyp fehlt:
typedef union {
int8_t c[4];
int16_t s[2];
int32_t i;
} uSample;
// so in der Art!
@Rolf
Ich gehe davon aus, dass der Bug 53 bei mir nicht drinnen ist.
Das hatten wir schon öfters irgendwo angesprochen, liegt daran, dass der
Datentransfer zwischen den internen Clock-Domains nicht 100%ig
funktioniert.
Sieht so aus, als würden die Wittigs die Datenübertragung asynchron
gemacht haben, was hier per Definition nie fehlerfrei sein kann.
Bei meiner Implementierung unterstützt Altera Quartus die synchrone
Datenübertragung auch nicht richtig:
Optimiere ich auf Taktfrequenz, funktioniert das nicht.
Optimiere ich auf Fläche, ist alles in bester Ordnung.
Ich habe da einen üblen, schwierigen sehr unüblichen Hack anwenden
müssen, damit das bei mir geht.
MfG
Alexander
alex008 schrieb:> Hallo!>> [...]>> @Rolf> Ich gehe davon aus, dass der Bug 53 bei mir nicht drinnen ist.> Das hatten wir schon öfters irgendwo angesprochen, liegt daran, dass der> Datentransfer zwischen den internen Clock-Domains nicht 100%ig> funktioniert.> Sieht so aus, als würden die Wittigs die Datenübertragung asynchron> gemacht haben, was hier per Definition nie fehlerfrei sein kann.
Naja, wenn Du Dir
http://sourceforge.net/apps/trac/welecw2000a/attachment/ticket/53/samplesvstime.png
ansiehst (95 Perioden auf steigender und fallender Flanke um den
Nullpunkt ausgewertet), sieht es für mich eher so aus, als
würde die Abtastung der ADC's 3 und 4 a) nahezu "zeitgleich"
und b) etwa 1.5ns zwischen den Abtastungen von 1 und 0 geschehen.
Testen kann man den Fehler sehr schnell, z.B. in dem man auf
eine steigende Flanke (Probe-Signal) triggert und schaut, ob die
"linear" bleibt, oder "Treppen" zeigt. Dies ist z.B. in
http://sourceforge.net/apps/trac/welecw2000a/attachment/ticket/53/wrong_samples.png
mit dem 1kHz Test-Signal gezeigt.
Sonst muss ich noch mal nachlesen, wie das mit dem Leon3
unter Linux läuft und mal 'nen "kurzen" Blick werfen ;)
>> Bei meiner Implementierung unterstützt Altera Quartus die synchrone> Datenübertragung auch nicht richtig:> Optimiere ich auf Taktfrequenz, funktioniert das nicht.> Optimiere ich auf Fläche, ist alles in bester Ordnung.> Ich habe da einen üblen, schwierigen sehr unüblichen Hack anwenden> müssen, damit das bei mir geht.
Autsch ;)
>> MfG> Alexander
Grüße,
rowue
Hallo,
es passt zwar deutlich besser in die Rubrik Hardware, jedoch betrifft es
auch die Software-Fraktion.
Ich habe heute Walters aktuellste Messungen zur Huckepack-Platine
hochgeladen. Ihr findet es wie immer hier:
http://sourceforge.net/apps/trac/welecw2000a/
Im Detail besteht das Ganze aus drei Skripten.
1. Integration der Huckepack-Platine in das Welec
http://welecw2000a.sourceforge.net/docs/Hardware/PCB_Integr.pdf
2. Erste Messung: Störeinstrahlung am Kanal 1
http://welecw2000a.sourceforge.net/docs/Hardware/PCB_messung_1.pdf
3. Zweite Messung: Einfluss des High Fre. Registers
http://welecw2000a.sourceforge.net/docs/Hardware/PCB_messung_2.pdf
Den Messungen kann man entnehmen, dass der furchtbare Frequenzgang der
originalen Eingangsstufe zum Teil durch die noch katastrophaleren,
digitalen Filter ausgebügelt wird, was sich wiederum negativ auf den
flachen Frequenzgang der Huckepack-Platine auswirkt.
Aus derzeitiger Sicht kann nur mit dem LEON3-Design wirklich das Optimum
aus der Huckepack-Platine herausgeholt werden, es sei denn es findet
sich ein Weg, die implementierten Filter vollends abzuschalten.
branadic
Alex H. schrieb:> Ähm, ich will zwar nicht meckern
Hast du aber. ;) Nicht desto trotz, hab ich die Dokumente etwas
verkleinert. War mir nicht bewusst, dass es noch Leute gibt die langsam
im Netz unterwegs sind.
branadic
branadic schrieb:> Hallo,>> [...]>> Den Messungen kann man entnehmen, dass der furchtbare Frequenzgang der> originalen Eingangsstufe zum Teil durch die noch katastrophaleren,> digitalen Filter ausgebügelt wird, was sich wiederum negativ auf den> flachen Frequenzgang der Huckepack-Platine auswirkt.> Aus derzeitiger Sicht kann nur mit dem LEON3-Design wirklich das Optimum> aus der Huckepack-Platine herausgeholt werden, es sei denn es findet> sich ein Weg, die implementierten Filter vollends abzuschalten.
Also: Wenn ich das richtig verstanden habe, ist in der BF der Filter,
den wir damals deaktiviert haben aktiviert und wird bei "High-Freq"
abgeschaltet. Der gestörte Signalverlauf in Abb. 11 dürfte Dir auch
noch sehr bekannt sein.
AFAIK wird die Darstellung beim Leon3 in Hardware gemacht - in wie
weit sind denn dort unterschiedliche Verstärungsfaktoren vorgesehen?
>> branadic
Grüße,
rowue
Und 30MB Pdf's mit großen Bildern sind wirklich nicht schön ;)
Hallo!
Die Darstellung im Leon3 Design wird in Software über einen (leider 16
Bit) 640x480 Framebuffer gemacht. Der VGA-Controller arbeitet als
AHB-Master und holt sich seine Daten selbstständig aus dem externen RAM.
Solange man nicht für jedes Bild den ganzen Bildschirm löscht und alles
neu zeichnet, gibt es definitiv kein Performance-Problem mit dem VGA.
(Jeder 16Bit Wert ist genau einem Pixel zugeordnet).
Die Signalerfassung inklusive der HW-Filter läuft in Hardware, damit man
beispielsweise bei einer Abtastrate vom 1MS/s einen Filter von 1GS/s zu
10MS/s einschalten kann (Filterung quasi ohne Bandbreitenbegrenzung :-)
).
Es wird bei eingeschaltenen Filter übrigens auch auf das gefilterte
Signal getriggert.
Zweiter Vorteil dieser Konstellation ist, dass die Triggereinheit bei
korrekter Einstellung nach ihrer einmalen Aktivierung per Software kein
Triggerevent übersieht.
Slog2 fing einmal mit einer Darstellung in Hardware an, die ich von
Beginn an sehr kritisierte. Man hat zwar auch anfangs schnell was, aber
sowas ist im vollen Menüumfang einfach nicht sinnvoll zu erreichen und
schränkt zu stark ein.
MfG
Alexander
Guten Abend,
bedingt durch die derzeit fehlende Unterstützung der Huckepackplatine
durch die Firmware konnten Messungen am Welec mit der Huckepackplatine
bisher nur mit viel Umständen durchgeführt werden.
Walter hat hierzu die Programmierleitungen für den LMH6518 nach außen
geführt und via Akkubetrieb am Notebook die Programmierung durchgeführt.
Ich hinke mit meinen Vergleichsmessungen noch ein wenig hinterher, da
bei mir persönliche Umstände dazu geführt haben, dass ich nicht die
notwendige Zeit dafür hatte.
Da wir auch von Stefan eine ganze Weile schon nichts mehr im
Skype-Gruppenchat gehört haben möchte ich an dieser Stelle noch einmal
den Aufruf starten die Unterstützung für die Huckepackplatine in der
Software zu implementieren.
Walter hatte dazu folgenden Vorschlag unterbreitet.
Hardware:
1. Kanal 5 - U24 kommt weg, LMH6518 hinter U21
2. U24 (Pin2) umleiten auf U21 (Pin9 oder 10)
Software:
1.LMH data = U22 pin9; clock = pin3 der Schiebereg.; CS = U24 pin4
2.LMH data = U22 pin9; clock = pin3 der Schiebereg.; CS = U24 pin6
3.LMH data = U22 pin9; clock = pin3 der Schiebereg.; CS = U24 pin14
4.LMH data = U22 pin9; clock = pin3 der Schiebereg.; CS = U24 pin12
16bit + 16bit + stb = 32bit oder 8 (U22)+ 24 (LMH6518)
Da die Huckepackplatine ja bereits vor einige Zeit zahlreich unter die
Leute gebracht wurde wäre es langsam auch an der Zeit, dass sie zusammen
mit dem Welec in Betrieb genommen werden kann.
Offen gestanden, man möge mir diesen Beitrag verzeihen, wundert es mich,
dass noch keine Beanstandungen durch die Leute laut wurden, die die
Huckepackplatine geordert haben.
Ich hoffe daher um die Unterstützung aus der Community und Programmierer
dieses Manko zu beseitigen. Leider bin ich in der Programmierung nicht
zu Hause und kann daher nichts zur Impementierung beitragen, ich
wünschte es wäre anders.
Daher noch einmal meine eindringliche Bitte an die Programmierer,
schafft eine Möglichkeit für die Huckepackplatine, bevor das Interesse
am Welec-Projekt gänzlich erlischt.
Gruß, branadic
Hallo Branadic!
Grundsätzlich habe ich ein großes Interesse, die Huckepack Platine ins
LEON3-Design einzubauen.
Dass ich das noch nicht gemacht habe lag daran, dass zuerst der
DC-Offset einstellbar sein musste.
Des Weiteren haben Robert und Crazor im Sommer wesentliche
Vereinfachungen in der Bedienung und Entwicklung des LEON3-Designs
durchgeführt, die ich unbedingt einarbeiten und vor allem dokumentieren
muss, bevor ich mich neuen Features wie der Huckepack-Platine widmen
kann.
In dem Zustand wie das LEON3-Zeug jetzt dokumentiert ist, werde ich kaum
neuzuwächse bekommen.
Seit ca. einem Jahr baue ich keine neuen Features mehr ein.
Zuerst muss die Basis funktionieren. Wenn ich jetzt gedankenlos
irgendwelche Dinge dazu programmiere, kommt im Endeffekt vielleicht
wieder so eine Software, die quaulitativ mit dem Original zu vergleichen
ist, heraus.
Das möchte ich auf jeden Fall vermeiden.
Alexander
Um einen Überblick zu bekommen wer überhaupt noch an dem Projekt
arbeitet habe ich die Seite der Entwickler um eine Statusspalte
erweitert:
http://sourceforge.net/apps/trac/welecw2000a/wiki/Developers
Ich möchte mit Nachruck jeden bitten, der noch am Projekt arbeitet
seinen Status in die Tabelle einzutragen.
Wir sind schon so weit gekommen das wir nicht zulassen dürfen dass das
Projekt untergeht. Mit der OS- und BF- Firmware wurden schon riesige
Fortschritte erziehlt, aber das wahre Potential liegt noch im
Leon-Design und der neuen Eingangsstufe.
Es gibt noch viel zu tun
Hallo werte Gemeinde ;-)
kein Grund zur Beunruhigung, meine Funkpause liegt wie schon gesagt an
der (wie immer) zum Jahresende angespannten beruflichen Lage. Über die
Feiertage bin ich dann in den Dolomiten (Bella Italia) zum Ski-fahren.
D.h. ich komme erst im neuen Jahr wieder dazu weiterzumachen. Aber - es
geht auf jeden Fall weiter.
@Branadic
Ich schaffe das leider erstmal nicht. Weiterhin hatte ich rausgehört,
dass es da Schwierigkeiten gibt mit den zur Verfügung stehenden Pins,
oder??
@Kurt
mach ich
Gruß Hayo
Keine Bange, es ist Weihnachtsstress, und bald sind Ferien.
Auf jeden Fall bin ich jetzt mit dabei.
Habe mich in der letzten Woche viele Stunden eingelesen und vielleicht
10% verstanden.
Und habe auch gleich einen klitzekleinen Fehler in tc_vars.cpp
int iSin1024[1024] = ...
vorletzte Zeile 31 muss -31 heißen.
Ob sich das irgendwo auswirkt?
Ich frage mich, ob es besser ist, statt 1024 1023 zu schreiben, dann
bleibt man im 11-Bit-Zahlenraum.
Mein insgesamt-Eindruck der Software: Es wurde vorbildlich schön,
bulletproof, IRQ-proof, modular, objektorientiert und threadbar
programmiert, aber dadurch leidet die Performance.
Z.b. in der Display::PIXELP (wenn ich das richtig sehe, wird der gesamte
Bildschirmaufbau darüber gemacht und dementsprechend oft aufgerufen) und
allen diese Funktion aufrufenden Routinen:
planeadr wird etliche Male durchgereicht, das braucht jedes Mal Zeit.
Ist es möglich, das über eine globale Variable zu lösen?
Außerdem wird set verwendet. Ich fände es besser, auf 2 Routinen
umzuschreiben, einen PIXELC (clear) und eine PIXELS (set)
Vorteil: set entfällt und muss nicht geladen, gestackt und ausgewertet
werden.
Hat jemand sich Gedanken zu meinem ddsScope.c vom 07.10.2010 21:38
gemacht?
Wie ich bisher verstanden habe, ist weder im Main-, noch im Delayed eine
variable Zeitbasis möglich.
Ich habe noch soo viele Ideen, aber wenig Zeit.
Siehe auch
Beitrag "Welec W20xx Bedienelemente modifizieren: Drehgeber Encoder LED BNC-Buchsen"
Eher für die Hardware:
In http://sourceforge.net/apps/trac/welecw2000a/wiki/LCD sehe ich den
Lapsus mit den 5*5*5=125 statt 8*8*8=512 Farben, ist das nicht durch
einfaches Grounden der niederwertigen Leitungen lösbar?
Hallo eProfi,
ich sehe Du hast Dich da schon richtig reingewühlt. Das sind
interessante Hinweise die Du da gefunden hast. Sobald ich wieder etwas
Zeit habe werde ich mir die Stellen mal ansehen.
Prima, dass Du da mitmischen willst. Ich freue mich schon auf das neue
Jahr, wenn es dann weitergeht.
Gruß Hayo
Ciao a tutti, purtroppo tempo fa mi si è rotto hard disk, e tra le altre
cose ho perso il firmware originale 1.4. Visto che in rete trovo tanti
che lo cercano e a quanto pare non si trova più, qualcuno lo potrebbe
postare da qualche parte? Vorrei metterlo sul sito per renderlo
disponibile a tutti.
Grazie, Gyppe :)
Hello, unfortunately I recently broke hard disk, and among other things
I've lost the original firmware 1.4. Since the network find many who
seek him and apparently no longer found, someone could post somewhere? I
would put it on the site to make it available to everyone.
Thanks, Gyppe:)
Hello,one new question
do you know if I rename file Tomcat.ram to Tomcat.flash and start the
updater available on Welec website,it works only in RAM??
Then, when I power off should appear the older firmware 1.4 and I can
choose what firmware is better.
Really I didn't find an easy way to check the firmware 2.7 before
installing
I tried installing Perl ,but the serial library conflicts on my XP,it
don't work
let me know
Best Regards
Hallo an alle,
ich wünsche ein frohes neues Jahr mit vielen Neuerungen für unsere DSOs.
@Gyppe
You never will need the original Firmware again - it is useless stuff!
@Alex
Den Sinn hab ich jetzt auch nicht verstanden.
@all
Mein SAP-Projekt ist gerade in der heißen Phase. Ich denke gegen Ende
des Monats bin ich damit durch und kann wieder was vernünftiges
machen...
Gruß Hayo
Naja, so wie ich das verstehe, möchte Alex mit der Welecsoftware
die neue Firmware erstmal testen, bevor er sie drüberbrät. Aus
irgendeinem Grund bekommt er Perl nicht zum Laufen.
Frohes Neues allerseits, Guido
Hallo,
um das Rätsel mit Alex Post aufzuklären... Die original Mail stammt von
Sandro aus Italien, ich hab ihm den Rat gegeben direkt in englisch hier
ins Forum zu posten, hat er aber wohl nicht hin bekommen.
Sandro wollte die TomCat.ram ausprobieren, bekommt aber auf seinem XP
Rechner Perl nicht installiert /Treiberkonflikt.
Seine Frage war jetzt, ob sich die Ram- Version auch ohne Perl irgendwie
in das Scope bekommen lässt, also z.B. mit dem Welec-updater.
Gruß, Brunowe
eProfi schrieb:> Z.b. in der Display::PIXELP (wenn ich das richtig sehe, wird der gesamte> Bildschirmaufbau darüber gemacht und dementsprechend oft aufgerufen) und> allen diese Funktion aufrufenden Routinen:> planeadr wird etliche Male durchgereicht, das braucht jedes Mal Zeit.> Ist es möglich, das über eine globale Variable zu lösen?>> Außerdem wird set verwendet. Ich fände es besser, auf 2 Routinen> umzuschreiben, einen PIXELC (clear) und eine PIXELS (set)> Vorteil: set entfällt und muss nicht geladen, gestackt und ausgewertet> werden.
Das habe ich schon so gemacht und vor vielleicht einem Jahr bei
Sourceforge eingecheckt. Zusammen mit diversen anderen Optimierungen im
Bereich der Zeichenfunktionen.
Ich bin eine Weile raus, kenne den aktuellen Projekt-Flow nicht. Gab es
nicht mal einen Merge von svn zu Hayo? Wenn nicht, wäre schade.
Jörg
Dimenticavo, buon nuovo anno a tutti!
Michael D, grazie mille! :)
Hayo, più che altro è meglio averlo se serve mandarlo in garanzia, credo
che con il firm modificato farebbero problemi.
Cosa è il SAP-Projekt? Ci dai qualche anticipazione? :)
Ciao, Gyppe.
I forgot, good new year to all!
Michael D, thanks a lot! :)
Hayo, more than anything else is better if you need to send it under
warranty, I believe that the firm would change problems.
What is the SAP-Projekt? Give us a preview? :)
Hello, Gyppe.
@Jörg
Ich bin da im Augenblick auch nicht im Bilde. Ich check das aber sobald
ich Zeit da zu habe. Wenn es noch fehlt kann ich es dann ja übernehmen.
@gyppe
buon nuovo anno.
Ah, I understand the problem. By the the way - I'm just back from Italy
where I had a nice time in the dolomites (Canazei).
If I tell You anything about my SAP-Project I have to kill You after
that - or my customer will kill me ;-)
Hayo
Hallo,
happy new year to all
don't forget to help me about the firmware testing (.ram file,see the
post upper)
I guess this isn't only mine
Thank you
alex
Alex, I succeede in sending the ram-file to the scope
just using a terminal program, e.g. hypertrm.exe.
It takes about 20 minutes.
flash-files can NOT be sent with a terminal because the erase-commands
in the beginning take to much time each.
But a trick helped: In hypertrm you can select a pause after each line.
(properties: connect via: direct connection of com1
configurate: 115200 bits per second 8 bits no parity flow control:
none
properties / settings ASCII configuration line delay: 2000 ms
Ok Ok
Open the connection by hitting any key, e.g. enter-key
(in the status line you see "connected" and a timer
In the main menue: Transmit | send text file | select file | set file
type to "all files" select your flash-file
wait ....
I split the flash-file into 2 parts:
Part 1: the erase-commands sent with 2 seconds pause after each line
Part 2: the program sent with "full" speed (at least full
hypertrm-speed which is slow in reality)
I did not succeed in installing the serial-apps either.
Welec-Updater did not work at all, maybe because of my old PC.
It did not load the whole file.
Good luck!
Hallo ,
I can't establish the connection,need some details
file is 1.2.BF.2.7\TomCat.ram
protocol is zmodem or xmodem?
scope must be activated by pressing the two keys before or after
connection?
RS232 and cable are ok because at power on I (only)receive the boot
message Update channel 1 and 2 done
BR
Alex
(part two of the upper post)
Also I have some question
original firmware 1.4 size is 3159 KB
either update BF 2.7 tomcat.flash and tomcat.ram size are 1256 Kb
Less the HALF . Looking in the code,What's useless in the original
firmware
or,what is not implemented in the new?
regards,
Alex
Hi Alex,
if You use a terminal I would recommend the free terminal Teraterm.
Attached You will find the .ini file with all settings You need.
When using the RS232 for flashing You need to change into the monitor
mode before. This is done by pushing and holding the first function key
(left) and then pushing the second function key one time.
After that the transmission can be startet.
If it doesn't work with the terminal, You can use the WELEC Updater from
Markus for backing up and flashing.
Complete Backup is recommended in every case!!!
How to use the program is described in the guides in the doc directory
of the BF.2.7 package.
If someting is going wrong or doesn't work we will help You.
I can promise You - after changing the firmware to the open source
firmware You will never change it back! The original firmware is scrap
and next to useless!
Hayo
Alex schrieb:> (part two of the upper post)>> Also I have some question> original firmware 1.4 size is 3159 KB> either update BF 2.7 tomcat.flash and tomcat.ram size are 1256 Kb> Less the HALF . Looking in the code,What's useless in the original> firmware> or,what is not implemented in the new?
Don't worry - the size of the flash file is not corresponding to
functionality!
The open source firmware is complete different to the original firmware
and has much more functions.
Hayo
Hayo, eh eh ok :) Avevo capito male, credevo fosse un progetto per il
dso.
Ciao, Gyppe.
Hayo, heh heh ok:) I had misheard, I thought it was a project for the
DSO.
Don't wonder about - although I'm Dipl. Ing E-Technik in real life I
earn my money as SAP consultant.
But programming DSO-Fw is my favourite activity...
Hayo