Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)

[gyppe (Gast)]

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

[Blue F. (blueflash)]

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

[Rainer W. (rawi)]

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

[Rainer W. (rawi)]

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

[Blue F. (blueflash)]

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

[gyppe (Gast)]

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?

[gyppe (Gast)]

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?

[Blue F. (blueflash)]

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

[gyppe (Gast)]

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

[Blue F. (blueflash)]

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

[Mirko B. (Gast)]

jia isichian!!

[Blue F. (blueflash)]

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

[Thomas (kosmos)]

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?

[Michael H. (Gast)]

@ 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

[Blue F. (blueflash)]

@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

[Mirko B. (Gast)]

>Die beigelegte Exceltabelle....

Wo ist die denn beigelegt?

Viele Grüße,

Mirko

[Blue F. (blueflash)]

In der 1.2.BF.x.x.zip\doc\programmers reference.xls -> Timebase Table

[Mirko B. (Gast)]

entweder ist mein ZIP kaputt oder....
In der 2.3 kann ich nix finden.

Viele Grüße,

Mirko

[Rainer H. (rha)]

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

[Blue F. (blueflash)]

@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

[Blue F. (blueflash)]

Hier die versprochene aber leider vergessene Datei.

Hayo

[Thomas (kosmos)]

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:____|-----|___

[Michael D. (mike0815)]

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

[Mirko B. (Gast)]

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

[Thomas (kosmos)]

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

[Michael D. (mike0815)]

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

[Thomas (kosmos)]

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

[Mirko B. (Gast)]

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

[Thomas (kosmos)]

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.

[Rainer W. (rawi)]

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

[Blue F. (blueflash)]

@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

[Michael D. (mike0815)]

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

[Ein Gast (Gast)]

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.

[Thomas (kosmos)]

die Idee von Michael finde ich auch ganz gut, also Pulldown Menü per 
Knopfdruck aufrufen und mit dem Drehencoder wechseln.

[Lothar M. (lme)]

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

[Rainer W. (rawi)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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 W. (rawi)]

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.

[branadic (Gast)]

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

[Daniel (Gast)]

Hallo zusammen, kann mir jmd verraten ob und wo ich die
FPGA HDL-Sources finde?
Über...
http://sourceforge.net/apps/trac/welecw2000a/wiki
... komme ich irgendwie nicht weiter.

Mfg,
Daniel

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[gyppe (Gast)]

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.

[Rainer W. (rawi)]

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

[gyppe (Gast)]

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.

[Michael D. (mike0815)]

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

[Rainer W. (rawi)]

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

[Rainer W. (rawi)]

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

[gyppe (Gast)]

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.

[Rainer W. (rawi)]

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

[Michael H. (stronzo83)]

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

[Michael D. (mike0815)]

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

[Blue F. (blueflash)]

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

[Luc (Gast)]

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

[Thomas (kosmos)]

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.

[Luc (Gast)]

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

[Michael D. (mike0815)]

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

[Lothar M. (lme)]

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

[Lothar M. (lme)]

Correction:
The resistor in the datasheet is 24.9 Ohm (not 29.5 as I said above)

Sorry

  Lothar

[Blue F. (blueflash)]

"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

[Blue F. (blueflash)]

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

[gyppe (Gast)]

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.

[Rainer H. (rha)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Rainer H. (rha)]

@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

[gyppe (Gast)]

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.

[Blue F. (blueflash)]

@Gyppe

Really nice site! I will keep it in mind.

Hayo

[Blue F. (blueflash)]

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

[gyppe (Gast)]

Tanks Hayo! :)

[branadic (Gast)]

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

[Guido (Gast)]

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

[branadic (Gast)]

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

[Luc (Gast)]

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

[Blue F. (blueflash)]

Hi there,

the optimization which I recommended in "Optimizing Thermal Design" is 
the minimum an 4 Channel device owner should do.

My own W2014A has now Heat Sinks (old PC Cooler) on the ADCs and a 70mm 
CPU-Fan on the backside:

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Other mods:

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"


Since this modifications all thermal problems are gone! So before You 
think about other resistances I would suggest to optimize the air flow 
in Your device.


@Lothar

Das würde bei Dir evtl. auch helfen!



Hayo

[Rainer H. (rha)]

@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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Martin H. (martinh)]

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

[Guido (Gast)]

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

[branadic (Gast)]

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

[Rainer H. (rha)]

@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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

@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

[Blue F. (blueflash)]

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

[Rainer H. (rha)]

@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

[Luc (Gast)]

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

[Blue F. (blueflash)]

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

[gyppe (Gast)]

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.

[wailer (Gast)]

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

[Thomas (kosmos)]

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

[Blue F. (blueflash)]

@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

[Thomas (kosmos)]

Achso ist schon bekannt, hatte meinen Beitrag erweitert als ich gesehen 
habe das es nur im Auto Mode auftritt.

[Blue F. (blueflash)]

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

[alex008 (Gast)]

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

[Michael D. (mike0815)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Michael D. (mike0815)]

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?

[Blue F. (blueflash)]

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

[Jürgen (Gast)]

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

[Blue F. (blueflash)]

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

[Michael D. (mike0815)]

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

[Blue F. (blueflash)]

Danke und guats Nächtle ;-)

[gyppe (Gast)]

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

[Luc (Gast)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Rainer W. (rawi)]

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

[Blue F. (blueflash)]

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

[Rainer W. (rawi)]

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

[gyppe (Gast)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[gyppe (Gast)]

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.

[Thomas (kosmos)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

Ü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

[Blue F. (blueflash)]

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

[Michael D. (mike0815)]

...der Hayo, unermüdlich!

War die Tek-Info hilfreich oder eher nicht?
Bin schon ganz gespannt auf deine neue FW2.7

Gruß Michael

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Mirko B. (Gast)]

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

[Mirko B. (Gast)]

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

[Blue F. (blueflash)]

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

[Mirko B. (Gast)]

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

[Blue F. (blueflash)]

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

[Guido (Gast)]

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

[Blue F. (blueflash)]

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

[Mirko B. (Gast)]

@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

[Jürgen (Gast)]

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

[Blue F. (blueflash)]

Ah danke für den Hinweis! Werde ich mal als Nächstes in Angriff nehmen.

Hayo

[Mirko B. (Gast)]

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

[Michael H. (Gast)]

Wow beeindruckend ist die richtige Beschreibung, das Ding ist jetzt 
wirklich erheblich schneller. Klasse!

[Moritz Z. (moud)]

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

[Blue F. (blueflash)]

Der Bereich der FFT ist noch in Arbeit. Ich hatte das nur unterbrochen 
um auf die zwischendurch gemeldeten Anforderungen und Bugs einzugehen.

Hayo

[Luc (Gast)]

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

[Michael D. (mike0815)]

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

[Blue F. (blueflash)]

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

[alex008 (Gast)]

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

[Blue F. (blueflash)]

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

[Peete960 (Gast)]

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?

[Luc (Gast)]

> 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

[Blue F. (blueflash)]

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

[Kurt B. (kurt)]

Neues vom W2000A-SD-USB-Host:
Beitrag "W2000A-USB-SD-Host"

[gyppe (Gast)]

Hayo meriti un po di relax :)

Hayo deserves a bit of relaxation:)

Gyppe.

[Rolf W. (rowue)]

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

[Blue F. (blueflash)]

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

[Rainer W. (rawi)]

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

[Blue F. (blueflash)]

Aaah, alles klar,

danke für die Info, dann muß ich da also wirklich einen Limiter 
einbauen.

Gruß Hayo

[Rolf W. (rowue)]

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

[Blue F. (blueflash)]

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

[Rolf W. (rowue)]

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

[alex008 (Gast)]

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

[Rolf W. (rowue)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Rolf W. (rowue)]

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

[Rolf W. (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

[[e-mail] (Gast)]

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.

[Mirko (Gast)]

Ich glaube die magische Grenze liegt so um die 1000 Posts - da muß du 
wohl noch etwas leiden ;-)

Schönes WE,

Mirko

[Link (Gast)]

Seitenaufteilung einschalten:

http://www.mikrocontroller.net/user/enable_post_pagination

[alex008 (Gast)]

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

[Rolf W. (rowue)]

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

[branadic (Gast)]

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. (hoal)]

branadic schrieb:
> 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

Ähm, ich will zwar nicht meckern und verfolge eure Entwicklung wie schon 
bei deinen Tastköpfen sehr interessiert, aber "Bildformate"...

Tut das Not, dass die enthaltenen Fotos die PDFs auf über 30 MByte 
aufblähen?

[branadic (Gast)]

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

[Rolf W. (rowue)]

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

[alex008 (Gast)]

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

[branadic (Gast)]

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

[alex008 (Gast)]

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

[branadic (Gast)]

Nunmehr sind 8 Tage vergangen und außer Alex hat niemand reagiert. Wird 
die Thematik jetzt totgeschwiegen?

branadic

[Kurt B. (kurt)]

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

[Blue F. (blueflash)]

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

[eProfi (Gast)]

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?

[Blue F. (blueflash)]

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

[gyppe (Gast)]

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

[alex (Gast)]

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

[Michael D. (mike0815)]

Hi Gyppe,

Here is the first link:
--- Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)" ---

and here is another one:
--- Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)" ---

greetings

Alex

wieso willst du die RAM in Flash umbennen? Hier gibts doch genug 
Flashfiles ?!?
Ausserdem müsste in der RAM noch ein Kommando entfernt werden, dann geht 
das!

Gruß Michael

[Blue F. (blueflash)]

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

[Guido (Gast)]

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

[Bruno W. (brunowe)]

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

[Blue F. (blueflash)]

Hab ich noch nicht getestet!

Einfach mal ausprobieren, kann ja nichts schiefgehen. Es sind ja keine 
Löschbefehle drin.

Hayo

[Jörg H. (idc-dragon)]

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

[gyppe (Gast)]

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.

[Blue F. (blueflash)]

@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

[Alex (Gast)]

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

[eProfi (Gast)]

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!

[Alex (Gast)]

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

[Alex (Gast)]

(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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Guido (Gast)]

@ Alex: No transferprotocol, just use "send data"!

[gyppe (Gast)]

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.

[Blue F. (blueflash)]

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