mikrocontroller.net

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


Autor: eProfi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dies ist die Fortsetzung von 
Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"


Autor: Hayo W. (blueflash)  Datum: 10.09.2011 00:56
eProfi schrieb:
>> ...wenn man die Helligkeit genug aufdrehte, sah man auch bei
>> nicht ausgelöstem Trigger am linken Bildrand einen Punkt in Höhe der
>> aktuellen Eingangsspannung. Das ist sehr praktisch, um z.B. zu sehen, ob
>> man den Tastkopf gut kontaktiert hat.
>> Ich wünsche mir also einen (per Menü aktivierbaren) 2x2 Pixel-Fleck, der
>> immer bei x=0 den aktuellen DAC-Wert anzeigt.
>Sorry, das hab ich irgendwie nicht so ganz verstanden. Die Höhe der
>aktuellen Eingangsspannung in negativer oder positiver Richtung oder wie
>ist das gemeint. Ich kann mir da nichts drunter vorstellen. Du hast
>nicht zufällig ein Bild davon?
Ein Beispiel: Du misst im Normal-Trigger einen Signal, das zwischen 2 
und 3V schwankt und ab und zu Spikes bis 5V hat, auf die Du triggern 
willst.
Nun siehst Du wg. fehlendem Trigger nicht, ob der Tastkopf richtig 
sitzt. Deshalb wäre es praktisch, wenn auch ohne Trigger bei x=0 (am 
linken Grid-Rand) die Eingangsspannung immer als Punkt dargestellt 
würde, sozusagen als senkrecht stehendes Multimeter. Dann siehst Du 
sofort an diesem Punkt, ob der Tastkopf richtig Kontakt macht und wie 
hoch die Spannung ist.



>> Was mir immer wichtig ist: die Triggerung. Da hat sich in letzter Zeit
>> viel getan, ich bin aber noch nicht zum Testen gekommen. Auf jeden Fall
>> ist mir der Unterschied AUTO und COMBI nicht klar.
>
>Was Michael erklärt ist schon ganz richtig, aber Auto und Combi arbeiten
>im Prinzip gleich. Wenn nach einer bestimmten Zeit kein Triggerereignis
>eintritt wird das Signal trotzdem ausgegeben. Der Unterschied liegt im
>Timeout. Der Combitrigger hat einen wesentlich längeren Timeout so daß
>auch langsamere Signal zuverlässig getriggert werden. Der Autotrigger
>arbeitet leider nur bei schnellen Signalen ganz brauchbar.

Ist diese Timeout-Zeit einstellbar? Das würde ich zusammen mit der 
Holdoff-Time so auswählbar machen, ob man eine feste konstante Zeit oder 
eine bestimmte Anzahl von Kästchen eingeben will.
Nochmal:
AutoTrigTime: Zeit, nach der der Strahl wieder startet, auch wenn kein 
Trigger kam.
HoldOffTime: Zeit, wie lange nach dem aktuellen Strahlende auf jeden 
Fall nicht getriggert wird, auch wenn ein Trigger kam.

Sitzt der Auto-Trigger im FPGA?


Zu den Geschichten mit der Drehrichtung von Knöpfen: einfach alles 
einstellbar machen.

Zu den Drehgebern, die bisher keine Taster hatten: seht Ihr da eine 
Möglichkeit, nachträglich welche mit Taster einzubauen, oder ist die 
Auswertung der 4 noch freien Eingänge 10-12,14 (die noch keine Pullups 
haben) am U9  im FPGA nicht unterstützt?


Autor: branadic (Gast)   Datum: 02.10.2011 12:33
Ich denke auch, dass zwischen den Samples und den Pixeln einfach eine 
Formel y=offset + sample * scalefactor (z.B. 
8x16-->24Bit-FixedPoint-Mul, nur die oberen 8 Bit des Ergebnisses 
nutzen) stehen sollte.
Damit kann man auch das Invertieren frei wählen, indem man scalefactor 
negativ macht. Beide Variablen stufenlos frei eingebbar machen, aus 
scalefactor den Wert V/div berechnen und fertig ist der y-Zoom.

Ich finde es einfach praktisch, wenn man z.B. ein Rechtecksignal mit 
genau einem Kästchen Höhe darstellen kann (das selbe gilt auch für 
x-Zoom).

Da der Gain des LHM scheinbar fein eingestellt werden kann, bietet es 
sich an, den ADC möglichst FullScale zu nutzen.

Autor: Gertjan K. (13ezeork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

Erst mal Herzlichen Dank fur was Sie alles fur die Wittig W20xx gemacht
haben. Dadurch wird dieses gerat bestimmt viel besser.

Habe mit Jörg schon gemaild, und werde einige Teile von Ihn kaufen.

Gruß Gertjan.

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eProfi schrieb:
> Da der Gain des LHM scheinbar fein eingestellt werden kann, bietet es
> sich an, den ADC möglichst FullScale zu nutzen.

Den ADCc Fullscale zu betreiben klingt zunächst zwar verlockend, macht 
aber bei genauer Betrachtung wenig Sinn, man sollte immer etwas Reserve 
haben, um nicht in der Sättigung des Eingangsverstärkers zu liegen. Das 
wird übrigens auch bei professionellen Geräten so gehandhabt. Als 
Beispiel, das Tektronix TDS5104B zeigt auf dem sichtbaren Bereich sogar 
nur 200 Samples an, der Rest ist Reserve außerhalb des Bildschirmes.
Angenommen du möchtest dir von einer Flanke die Basis anschauen, dann 
wirst du dazu verleitet sein das Signal nach oben zu kurbeln. Geht der 
Eingangsverstärker nun in die Sättigung wird sich auch die Basis deines 
Signales, dass du ja betrachten möchtest, stark verändern und nicht mehr 
der Realität entsprechen.

Darüber hinaus ist es mit der Huckepackplatine auch gar nicht möglich 
den ADC im Fullscale zu betreiben. Das Excelsheet zeigt was maximal 
möglich ist.

Der max. Gain des LMH6518 beträgt 38.8dB, es kommen weitere 6.02dB durch 
den darauf folgenden AD8131 hinzu. Zusammen mit der 
Widerstandskombination an dessen Ausgang 2x 24.9R plus den 150R vor den 
ADC verlieren wir noch mal 2.49dB, landen damit also bei einer 
Gesamtverstärkung von 42.33dB.
Damit ist der ADC in allen drei Ablenkbereichen (1, 2, 5) zu etwa 225LSB 
ausgesteuert und wir haben ca. 30 LSB Reserve.
Ich denke das ist ein überaus gutes Ergebnis und der 
Software-Scalefactor ist mit ca 1,78 in allen drei Bereichen auch 
konstant.
Der Rauschteppich wird damit in den 5er-Bereichen noch mal etwas 
verbessert und ist, was ja noch viel wichtiger ist, in den 1er und 2er 
Bereichen nun genauso groß wie im 5er Bereich.
240 LSB, wie ursprünglich von Walter vorgeschlagen, erreichen wir durch 
die Widerstandskombi nicht. Diese erachte ich jedoch als durchaus 
sinnvoll, um definierte Verhältnisse zu schaffen.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eProfi schrieb:

>>> immer bei x=0 den aktuellen DAC-Wert anzeigt.
Bist Du sicher, dass Du den DAC-Wert meinst und nicht ADC?

> Nun siehst Du wg. fehlendem Trigger nicht, ob der Tastkopf richtig
> sitzt. Deshalb wäre es praktisch, wenn auch ohne Trigger bei x=0 (am
> linken Grid-Rand) die Eingangsspannung immer als Punkt dargestellt
> würde, sozusagen als senkrecht stehendes Multimeter.
Tja, aber bei einem 5 Mhz Signal würde der Punkt dann ziemlich schnell 
hoch und runter flitzen, Es sei denn man berechnet den Mittelwert, der 
aber bei einem symmetrischen Signal Null ist.


> Ist diese Timeout-Zeit einstellbar?
Das wäre noch eine Idee.

> Sitzt der Auto-Trigger im FPGA?
Ja, deswegen habe ich da auch keinen Einfluß drauf.
>
> Zu den Geschichten mit der Drehrichtung von Knöpfen: einfach alles
> einstellbar machen.
Das wird vielleicht etwas sehr aufwändig.


> Zu den Drehgebern, die bisher keine Taster hatten: seht Ihr da eine
> Möglichkeit, nachträglich welche mit Taster einzubauen, oder ist die
> Auswertung der 4 noch freien Eingänge 10-12,14 (die noch keine Pullups
> haben) am U9  im FPGA nicht unterstützt?
Da kann ich momentan leider nichts zu sagen.
>
> Autor: branadic (Gast)   Datum: 02.10.2011 12:33
> Ich denke auch, dass zwischen den Samples und den Pixeln einfach eine
> Formel y=offset + sample * scalefactor (z.B.
> 8x16-->24Bit-FixedPoint-Mul, nur die oberen 8 Bit des Ergebnisses
> nutzen) stehen sollte.
> Damit kann man auch das Invertieren frei wählen, indem man scalefactor
> negativ macht.
Dann steht aber das invertierte Signal nicht für weitere Berechnungen 
wie QM oder Math zur Verfügung. Ein stufenloser Scalefaktor wäre 
machbar, aber die genaue Amplitudenmessung müßte man sinnvoll umsetzen 
(evtl. über die Cursor) denn die Angabe 3,76V/div hat ja nicht allzu 
viel praktischen Wert beim Ablesen.

Gruß Hayo

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
branadic:
Ich meine ja nicht ganz FullScale, sondern nahe an FullScale, 200-230 
ist ein guter Wert.


Hayo:
>> immer bei x=0 den aktuellen DAC-Wert anzeigt.
> Bist Du sicher, dass Du den DAC-Wert meinst und nicht ADC?
Hast Recht, ADC meine ich.


> Tja, aber bei einem 5 Mhz Signal würde der Punkt dann ziemlich
> schnell hoch und runter flitzen, Es sei denn man berechnet den
> Mittelwert, der aber bei einem symmetrischen Signal Null ist.
Ich dachte eher an ein Gleichspannungssignal, bei dem ganz selten Spikes 
auftreten. Oder ein RS232-Signal, bei dem ab und zu Bytes gesendet 
werden.


> Dann steht aber das invertierte Signal nicht für weitere
> Berechnungen wie QM oder Math zur Verfügung.
Wieso? Du kannst dort doch auch nochmal skalieren.

> Ein stufenloser Scalefaktor wäre machbar, aber die genaue
> Amplitudenmessung müßte man sinnvoll umsetzen (evtl. über
> die Cursor) denn die Angabe 3,76V/div hat ja nicht
> allzu viel praktischen Wert beim Ablesen.
Finde ich schon, wenn man z.B. Verhältnisse messen will.

Autor: Kurt Bohnen (kurt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt eine neue Version der USB-Host Firmware:
http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum

Die Firmware ist etwas schlanker geworden und die Stabilität wurde 
drastisch erhöht! Als nächstes wird die Platine weiter optimiert und die 
Dokumentation vervollständigt.

@Hayo:
bitte die UC_rle_enc ersetzten. Danke!

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eProfi schrieb:
> Ich meine ja nicht ganz FullScale, sondern nahe an FullScale, 200-230
> ist ein guter Wert.

Das ist doch mit der Huckepackplatine gegeben!

Nach dem ursprünglichem Vorschlag von Walter den ADC mit 240 LSB 
auszusteuern müssten die Terminierungswiderstände am Ausgang des AD8131 
weggelassen werden. Dafür ergäben sich Vertikalablenkungen von:
1 mV/div - 5 V/div, entsprechend einem ADC-Aussteuerbereich von 237 - 
238 LSB.

Folgt man jedoch dem Vorschlag von mir mit 220 LSB, was eine Bestückung 
der 2x 24.9 R + 15 0R zwingend notwendig macht, ergibt sich ein 
Vertikalablenkungsbereich von 1 mV/div - 10 V/div, mit einem 
ADC-Aussteuerbereich von 224 - max. 226 LSB. Die Reserve an den ADC 
halte ich durchaus für zweckmäßig und sinnvoll.
Der Eingangsspannungsteiler sollte, das wäre aber noch mal zu prüfen, 
die notwendige Spannungsfestigkeit für 10 V/div aufweisen und es wäre 
sicher zu stellen, dass die Eingangsspannungsteiler in diesem Fall auch 
wirklich beide aktiv sind.

Du hast dir das Excelsheet angeschaut? Das habe ich extra erstellt, 
damit man die zu Grunde liegende Rechnung nachvollziehen kann.

http://welecw2000a.sourceforge.net/docs/Hardware/W...

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eProfi schrieb:

>> Tja, aber bei einem 5 Mhz Signal würde der Punkt dann ziemlich
>> schnell hoch und runter flitzen, Es sei denn man berechnet den
>> Mittelwert, der aber bei einem symmetrischen Signal Null ist.
> Ich dachte eher an ein Gleichspannungssignal, bei dem ganz selten Spikes
> auftreten. Oder ein RS232-Signal, bei dem ab und zu Bytes gesendet
> werden.
Leider stehen die ADC-Werte auch nicht die ganze Zeit zur Verfügung, 
sondern nur nach einem Triggerereignis. Für Deinen Punkt müßte man 
versuchen den Pretriggerspeicher auszulesen, die ganze Aktion würde aber 
unter Umständen das Timing des normalen Triggerbetriebs 
durcheinanderbringen.

>
>> Dann steht aber das invertierte Signal nicht für weitere
>> Berechnungen wie QM oder Math zur Verfügung.
> Wieso? Du kannst dort doch auch nochmal skalieren.
Das ist leider nicht so ganz einfach. Die Grafikausgabe funktioniert aus 
Performancegründen nicht ganz so einfach, dass jeder Punkt nach einer 
Formel berechnet wird, sondern es wird anhand der Skalierungsfaktoren 
für jeden Spannungsbereich eine Wertetabelle aufgebaut die dann für 
jeden ADC-Wert einen Wert enthält der die Y-Ablenkung repräsentiert.

>> Ein stufenloser Scalefaktor wäre machbar, aber die genaue
>> Amplitudenmessung müßte man sinnvoll umsetzen (evtl. über
>> die Cursor) denn die Angabe 3,76V/div hat ja nicht
>> allzu viel praktischen Wert beim Ablesen.
> Finde ich schon, wenn man z.B. Verhältnisse messen will.
Der Wert wäre außerdem vom Platz her in der Statuszeile nicht 
unterzubringen. Man müßte sich also überlegen wie man den Wert anzeigt. 
Gibt es da evtl. schon etablierte Lösungen an denen man sich orientieren 
kann?

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurt Bohnen schrieb:

> @Hayo:
> bitte die UC_rle_enc ersetzten. Danke!

Ok, geht klar. Mach ich wenn ich wieder zurück bin.

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Um bei der Sammelbestellung etwas Zeit zu sparen möchte ich schon jetzt 
die Preise festlegen. Wer also noch teilnehmen möchte und sich nicht bei 
mir gemeldet hat, sollte dies jetzt nachholen. Je mehr Leute sich melden 
desto günstiger kann der Preis werden!

Wichtig: Das ist noch keine Deadline! Das Ende der Bestellannahme wird 
rechtzeitig und deutlich bekannt gegeben.

Wer Fragen hat kann sich hier im Forum oder per mail bei mir melden.

Mfg,
Kurt


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

Autor: eProfi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> eProfi schrieb:
>
>>> Tja, aber bei einem 5 Mhz Signal würde der Punkt dann ziemlich
>>> schnell hoch und runter flitzen, Es sei denn man berechnet den
>>> Mittelwert, der aber bei einem symmetrischen Signal Null ist.
>> Ich dachte eher an ein Gleichspannungssignal, bei dem ganz selten Spikes
>> auftreten. Oder ein RS232-Signal, bei dem ab und zu Bytes gesendet
>> werden.
> Leider stehen die ADC-Werte auch nicht die ganze Zeit zur Verfügung,
> sondern nur nach einem Triggerereignis. Für Deinen Punkt müßte man
> versuchen den Pretriggerspeicher auszulesen, die ganze Aktion würde aber
> unter Umständen das Timing des normalen Triggerbetriebs
> durcheinanderbringen.
Das darf natürlich nicht passieren. Es genügt, wenn z.B. mit 10 Hz die 
Spannung / der Punkt aktualisiert wird.

>>> Dann steht aber das invertierte Signal nicht für weitere
>>> Berechnungen wie QM oder Math zur Verfügung.
>> Wieso? Du kannst dort doch auch nochmal skalieren.
> Das ist leider nicht so ganz einfach. Die Grafikausgabe funktioniert aus
> Performancegründen nicht ganz so einfach, dass jeder Punkt nach einer
> Formel berechnet wird, sondern es wird anhand der Skalierungsfaktoren
> für jeden Spannungsbereich eine Wertetabelle aufgebaut die dann für
> jeden ADC-Wert einen Wert enthält der die Y-Ablenkung repräsentiert.
Steht diese Wertetabelle im RAM? Dann kannst Du sie bei jeder Änderung 
von y-Offset oder V/div  einmalig neu berechnen.

Wenn ich mich recht erinnere, gibt es eine weitere Tabelle, die bei 
PutPixel(x,y) den y-Wert in eine Display-Adresse "umrechnet".
Diese beiden Tabellen würde ich gleich in eine einzige zusammenfassen:
ADC nach Adresse, das bringt Performance (ich habe jetzt nicht 
nachgeschaut, ob es bereits so gemacht wird).
>
>>> Ein stufenloser Scalefaktor wäre machbar, aber die genaue
>>> Amplitudenmessung müßte man sinnvoll umsetzen (evtl. über
>>> die Cursor) denn die Angabe 3,76V/div hat ja nicht
>>> allzu viel praktischen Wert beim Ablesen.
>> Finde ich schon, wenn man z.B. Verhältnisse messen will.
> Der Wert wäre außerdem vom Platz her in der Statuszeile nicht
> unterzubringen. Man müßte sich also überlegen wie man den Wert anzeigt.
> Gibt es da evtl. schon etablierte Lösungen an denen man sich orientieren
> kann?
>
Im Anhang ein 800x600-Screenshot unseres LeCroy WaveRunner.
Im oberen Pane (Teilfenster) ein Signal mit 50,0µs/div, abgetastet mit 
5.0 Gs/s sind das 2,5 MSamples (bei diesem Modell max. 4x 
12,5MSamples)), Timebase 0µs bedeutet, dass der Triggerzeitpunkt 
(hellgrüner Pfeil nach oben unter dem Pane) in der x-Mitte der Anzeige 
ist.
Das hellbraune C1 mit dem "Haken" und das hellgrüne C4 zeigen die 
Gnd-Level von C1 und C4 an, im Klartext auch -22.00 V ofst  bzw.  -193.0 
mV.
(0 V ist wiederum die y-Mitte des Y-Bereiches).
Der hellgrüne links-Pfeil  rechts vom oberen Pane ist der Triggerlevel 
(hier 100.0mV über C4-Gnd).
Der hellgetastete Bereich der oberen Darstellung wird im unteren gezoomt 
(50.0mV/div 1.00 µs/div) dargestellt (die Aufteilung in Panes (wieviele 
Grids dargestellt werden)  und die Zuordnung, welches Signal wo 
dargestellt wird, ist frei wählbar).

Folgende Werte sind 1-2-5-stufig einstellbar:
- V/div für C1-C4
- s/div für C1-C4

Folgende Werte sind stufenlos einstellbar:
- Triggerlevel oben und unten (auch über die Displaygrenzen hinaus)
- x-Offset C1-C4 (Triggerzeitpunkt)
- x-Offset Z1-Z4 (unabhängig von C1-C4)
- V/div und s/div für Z1-Z4 (unabhängig von C1-C4)
- Zoombereich (y-offset)


Keine Frage, dass eine solche Anzeige auf 640x480 fast unmöglich ist.
(800x600 ist einer der kleinen Minuspukte des LeCroys, unser "Platz 2" 
(Yokogawa) hatte nämlich 1024x768).

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurt Bohnen schrieb:
> Wichtig: Das ist noch keine Deadline! Das Ende der Bestellannahme wird
> rechtzeitig und deutlich bekannt gegeben.

Jetzt kommt aber die Deadline: Bestellungen für Huckepack Platinen und 
USB-Host werden noch bis zum 16.10.2011 24:00 Uhr angenommen.

Autor: manfred.h (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo und alle anderen:

Zwei Macken stören beim Umgang mit dem Scope:
Firmware 4.5-C2

1) Lege ich ein logisches Signal (Rechteckspannung 0,5V bis 5V) an, 
reagiert der Trigger (Flankentrigger, egal welche Flanke) erst ab einer 
bestimmten Mindestsignalhöhe. So z.B. im 5V-Bereich erst ab ca. 2 Volt, 
im 1V-Bereich erst ab ca. 0,9 Volt. Die Höhe ist nicht reproduzierbar 
jedesmal gleich. So hatte ich im 1V-Bereich auch schon einmal 0,5 Volt 
als untere Grenze.

2) Symmetrische Dreieckspannung: 3,5Vss; 100Hz
a) Trigger auf pos.Flanke (screen-04). Sobald der Triggerpegel in den 
negativen Bereich geht, stimmt der Triggerpunkt nicht mehr (250mV zu 
hoch).
b) Trigger auf negative Flanke (screen-03). Wird hier der Triggerpegel 
in den positiven Bereich bewegt, ist der Triggerpunkt um ca. 250mV zu 
niederig.

Ist das bei euch auch so oder gibt es das Problem nur bei mir?

Gruß Manfred

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manfred,
ich kann das im Moment leider nicht testen.
Aber inzwischen gibt es ja die Version 1.2.BF.4.9-C2,
evtl. hat sich das damit ja bereits errledigt?

Gruß
Robert

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manfred,

wie Robert schon andeutet bitte möglichst die aktuellste Version 
verwenden. Allerdings sollte sich in den Zwischenversionen am Trigger 
nichts geändert haben. Ich werde mir das mal ansehen.

Gruß Hayo

Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,
the function 'Undo autoscale' with last FW 1.2.BF.4.9-C2 seems not 
working, didn't recall the previous setting.I tested with CH1,any 
signal.May be you are already informed?
Regards,
Sandro

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sandro,

thanks for reporting, I will check it.

Regards Hayo

Autor: manfred.h (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, liebe Welec-Kolleg(innen)

Info: Habe die neueste Firmware aufgespielt. An den Triggerproblemen hat 
sich nichts geändert.

Gruß Manfred

Autor: manfred.h (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,
würde obige Probleme gerne in Kauf nehmen, wenn mein DSO noch 
funktionieren würde. Ich will aber nicht zu früh aufgeben! Deswegen 
suche ich eure Hilfe.

Was ist passiert: Während eines Messvorganges (kann nicht an zu hoher 
Eingangsspannung liegen!) zeigte das Display ein Muster wie eine 
senkrecht angeordnete Jalousie zweier verschiedener Anordnungen, jeweils 
mindestens 20 Pixel breit. Das beigefügte Bild ist nur aus dem 
Gedächtnis gemacht, also symbolhaft: einerseits zufällig leuchtende 
Pixel, dazwischen die Anzeige des gemessenen Signals - allerdings 
eingefroren. Ich schlatete das Gerät aus und dann wieder ein. Dabei 
scheint das DSO in den Germs-Monitormode zu gehen, keine 
Initialisierung. Es leuchtet nur die Run/Stop-Taste grün. Das Drücken 
der linken zwei Tasten aktiviert den Germs-Monitor erneut mit wechselnd 
leuchtenden Tasten. Ich kann auch ein Firmwareupdate aufspielen, 
allerdings kommt das Oszi danach nicht mehr zur normalen Arbeitsansicht.

Ich bin ratlos, hab schon alles (Un)mögliche versucht - Gerät 
ausschalten, auskühlen lassen, neue Firmware flashen, Ram neu bespielen, 
usw... Seht ihr eine Möglichkeit, die ich noch ausprobieren könnte?
Manfred

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es könnte sein dass du den RAM nachlöten musst.

Mfg,
Kurt

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gab da mal Probleme mit unsauber verlöteten Speicherbausteinen. 
Anhand deines Musters müßte sich das eigentlich eingrenzen lassen.

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manfred,

bei mir saß der Stecker vom Display nicht richtig. Das könnte vom 
Fehlerbild schon passen.

Gruß,
Jörg

Autor: Manfred,h (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Das Display zeigt im Germsloaderbetrieb keine Streifen. Stecker muss 
also passen. Ich hab in der Speicheraufteilung nachgeschaut. Da wird 
beim Einschalten das Flash in den Ram-Bereich kopiert, was bei mir wohl 
nicht der Fall ist. Welcher Speicherbereich wird beim Start des 
Germsloaders angesprungen? In welcher Reihenfolge passiert der 
Bootvorgang? Wo steckt der Speicher, der die Daten für das Display 
enthält? Ist dieser Speicher linear aufgebaut?  Weiß da jemand Bescheid?

Manfred

Autor: Georg X. (schorsch666)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend Leute,

ich habe jetzt auf mein W2014A die neueste FW aufgespielt. Ich habe mal 
das 1kHz Testsignal vom Oszi auf den ersten Kanal gelegt und ein wenig 
mit den Einstellungen gespielt.
Mir ist aufgefallen dass wenn ich die Zeitauflösung nach oben verstelle 
vom msec in den sec Bereich dass das Oszilloskop zwar anfangs alle 
Flanken erkennt und quasi einen befüllten gelben Streifen anzeigt. Ab 
einer bestimmten Einstellung werden nur vereinzelte Flanken erkannt und 
somit statt 1kHz ein Signal mit ca. 3Hz angezeigt. Lässt sich hier noch 
was einstellen damit man bei einer solch falschen Einstellung merkt dass 
die Messpunkte nicht mehr ausreichen und der angezeigte Messwert falsch 
ist.

ODER immer erst Auto-Scale und dann in die gewünschte Einstellung 
wechseln?

Danke und Gruss,
Georg.

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg X. schrieb:
> Ab einer bestimmten Einstellung werden nur vereinzelte Flanken
> erkannt und somit statt 1kHz ein Signal mit ca. 3Hz angezeigt.

Das hat schon seine Richtigkeit. In der Grundvorlesung über digitale 
Systeme taucht relativ bald das Nyquist-Shannon-Abtasttheorem auf. Wenn 
du dagegen verstößt, passiert genau das, was du da beobachtet hast: 
Aliasing.
Das aus den abgetasteten Daten rekonstruierte Signal sieht wie ein 
Signal anderer Frequenz aus. Das ist eine grundlegende Eigenschaft eines 
DSO.

Gruß
Rainer

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg,
Rainer hat völlig Recht: das Phänomen tritt grundsätzlich bei Abtastung 
eines Signales mit zu geringer Abtastrate auf und man hat auf der 
Softwareseite keinerlei Möglichkeit, zu erkennen, ob die Abtastrate 
ausreichend hoch ist oder nicht. Sobald du mit zu geringer Samplerate 
arbeitest, ist die Information über das tatsächliche Signal dahin und 
kann nicht softwareseitig zurückgewonnen werden (von Spezialfällen mal 
abgesehen).

Falls du nicht weißt, in welchem Frequenzbereich dein Signal liegt, dann 
schalte vorsichtshalber immer probeweise in kleinere Zeitbasen. Auf die 
Weise bist du dann sicher, dass das was du siehst auch deinem 
tatsächlichen Signal entspricht.
Es schadet auch nicht, immer mal einen Blick auf die Samplerate zu 
werfen und zu checken, ob man ausreichend weit oberhalb der 
Signalfrequenz liegt.

Gruß
Michael

Autor: Georg X. (schorsch666)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend,

woher dass kommt und wie es funktioniert ist mir schon klar.
Ich bin nur etwas andere Messmittel gewohnt. Da sind die Grenzen 
deutlich höher und die Darstellung ist anders, so dass man daran schon 
erkennt dass das Signal verfälscht wurde. Allerdings kosten die Geräte 
auch um das 100fache mehr.

Danke euch für die Erleuterungen.
Außerdem Danke an die fleißigen Entwicker unter euch. Richtig gute 
Arbeit.

Gruß,
Georg.

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Professionelle Geräte können durch ihre meist sehr hohe Speichertiefe 
(bei uns z.B. 4MSa/Kanal) auch bei langsamen Zeitbasen noch relativ 
schnell abtasten, dadurch stößt man natürlich entsprechend seltener auf 
das Problem des Aliasings. Auch mein altes Zweitoszi hier zu Hause mit 
seinen 125kSa/Kanal schiebt die Abtastrate bei langsamen Signalen 
gegenüber dem Welec deutlich nach oben, obwohl es nur 100MSa/s maximale 
Samplerate hat.
Aber auch bei professionellen Geräten gibt es bei Unterabtastung 
keinerlei Möglichkeit, zu erkennen, dass das angezeigte Signal nicht dem 
realen entspricht - das ist ja gerade das gemeine am Aliasing.

Gruß,
Michael

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für den SD-USB-Host habe ich noch eine kleine Anleitung geschrieben:
http://welecw2000a.sourceforge.net/docs/Miscellane...

Weitere Infos werden später ergänzt.

Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen schrieb:
> Rainer W. schrieb:
>> Korrektur:
>> Es geht doch, allerdings mit mir völlig unverständlichen Zeitlimits.
>> Solange die Summe der beiden Werte für die Länge des
>> Pulstriggerfensters in dem gezeigten Fall gerade noch unterhalb von
>> 287µs liegt, kriegt die Triggerfunktion den genau genommen 192µs langen
>> Puls zu fassen. Es ist egal, ob man z.B. (<100, >187), (<140, >147) oder
>> gar (>187, <100) einstellt.
>> Einen komischen "Hystereseeffekt" gibt es, wenn man den ">"-Wert in der
>> Nähe der Pulsdauer variiert, d.h. z.B. <50µs fest eingestellt hat und
>> dann
>
> Hallo Rainer,
>
> ich konnte dies eben noch mal mit dem Probe Comp Signal nachvollziehen.
> Das schau ich mir nochmal an! Da läßt sich sicher etwas machen.
>
> Gruß Jürgen

@Rainer

Ich hab mal wieder einen Blick zurück getan und die Lösung gefunden :-)
Als Anhang mal eine Probe für die Pulse Width Problematik. Du kannst ja
mal den Anhang ausprobieren, ob es so passt. Es fehlen allerdings noch
die gesamten Prüfungen zu den Eingabebereichen in der Firmware.

Gruß Jürgen

Sorry, das sollte hier her in Teil 5!

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

Super!

Bei der in meinem alten Beitrag gezeigten Pulstrigger-ärger-Pulsfolge
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
kriegt der Pulstrigger im "><"-Mode jetzt alle Pulse sauber zu fassen.

Der ">"-Mode benimmt sich anscheinend auch vernünftig, obwohl der 
natürlich bei der Pulsfolge etwas überfordert ist.

Getestet habe ich unverändert mit Pulslängen 100..400 µs.

Bei der Bedienung für den "><"-Modus müßte man natürlich sicherstellen, 
das der ">"-Wert größer als der "<"-Wert ist.

Da hätte ich aber noch einen Alternativvorschlag. Wie wäre es, wenn man 
den Reglern im "><"-Mode, anders als bisher, die Parameter

 1. Triggerpulslänge
 2. Toleranz

zuordnet, also statt bisher z.B. für 100 µs Pulse die Regler auf
"< 90µs" bzw. "> 110µs" zu stellen, würde man dann als Parameter 
einstellen "L 100µs" und "+/- 10µs". Vorteil wäre, das man in der 
Bedienung die beiden Parameter Länge und Toleranz sauber getrennt hat, 
so dass man nicht immer an beiden Regler drehen muß, um die 
Triggerpulslänge zu ändern.

Hast du für die Lösung des Problems jetzt ein Work-arround um die FPGA 
Logik gebaut oder wie hast du dem Scope seine Triggerunarten abgewöhnt?

Gruß
Rainer

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

Rainer W. schrieb:
> Hast du für die Lösung des Problems jetzt ein Work-arround um die FPGA
> Logik gebaut oder wie hast du dem Scope seine Triggerunarten abgewöhnt?

Nö, wie oben angedeutet, hab ich mal wieder zur Welec 1.4 Software 
geschaut :-)
Dort ist die zweite Taste im "><"-Modus mit "delta t" beschriftet, was 
genau der Funktion entspricht.

> Bei der Bedienung für den "><"-Modus müßte man natürlich sicherstellen,
> das der ">"-Wert größer als der "<"-Wert ist.

Dies muß eben noch als "Eingabeprüfung" ausprogrammiert werden.

> Da hätte ich aber noch einen Alternativvorschlag. Wie wäre es, wenn man
> den Reglern im "><"-Mode, anders als bisher, die Parameter
>
>  1. Triggerpulslänge
>  2. Toleranz
>
> zuordnet, also statt bisher z.B. für 100 µs Pulse die Regler auf
> "< 90µs" bzw. "> 110µs" zu stellen, würde man dann als Parameter
> einstellen "L 100µs" und "+/- 10µs". Vorteil wäre, das man in der
> Bedienung die beiden Parameter Länge und Toleranz sauber getrennt hat,
> so dass man nicht immer an beiden Regler drehen muß, um die
> Triggerpulslänge zu ändern.

Die Funktion ist jetzt: Die positive Impulsdauer muß größer als ">" sein 
und die negative Flanke dann innerhalb des Zeitfensters "dt", gerechnet 
ab ">" sein. D.h. das entsprechende Register "<" muss einfach mit der 
Differenz zwischen ">" und "<" geladen werden.
Die jetzige Funktion scheint mir in der Bedienung logischer zu sein. In 
einer "Luxusversion" kann man ja mit der Drehung des ">"-Reglers auch 
den anderen Regler "<" entsprechend verstellen. Ist allerdings nicht 
ganz so einfach.
Für die nicht funktionierenden "<"-Modus sollten wir eventuell intern 
auch einen "><"-Modus mit einem Festwert für ">" von z.B.16ns 
hinterlegen, da in der Betriebsanleitung von Welec sowieso eine 
Untergrenze von 16ns als Beschränkung angegeben ist. Der Regler 
verstellt dann nur noch die Obergrenze. Die Untergrenze muß erprobt 
werden.

Gruß Jürgen

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

wer kommt schon drauf, dass die Regler falsch beschriftet sind. Prima .

Jürgen schrieb:
> Die Funktion ist jetzt: Die positive Impulsdauer muß größer als ">" sein
> und die negative Flanke dann innerhalb des Zeitfensters "dt", gerechnet
> ab ">" sein. D.h. das entsprechende Register "<" muss einfach mit der
> Differenz zwischen ">" und "<" geladen werden.
>
> Die jetzige Funktion scheint mir in der Bedienung logischer zu sein.

Logisch finde ich beide Einstellmethoden, je nach Weltanschauung.
Klar, die Eingabe von ">" und "<" ist dichter am Signalverlauf dran, 
aber auf der anderen Seite kommt es oft genug vor, dass man nur die 
Impulsdauer verändern möchte und sich eigentlich gerne das Fummeln am 
zweiten Regler sparen würde.
Die Idee den "<"-Mode durch einen "><" mit festem unteren Wert zu 
realisieren ist sicher eine gute Möglichkeit.

Wie wäre es denn, wenn man die Modusauswahl ganz umschmeißt und einen 
Button mit Auswahllist für folgende vier Triggerarten einbaut:
 1. "<" mit Regler "<" (intern als "><" mit unterem Limit 16ns)
 2. ">" mit Regler ">"
 3. "><" mit Reglern ">" und "<"
 4. "t, dt" mit Reglern für Länge und Delta, die dann intern auf
    unteres Limit = Länge - Delta und
    oberes Limit = Länge + Delta (i.e. Register "<" = 2 * Delta)
    umgesetzt sind.

Die jetzige Art des Softbuttons bringt nicht so die riesigen Vorteile 
und eine Auswahlliste wäre konform zur sonstigen Bedienphilosophie. Mit 
den vorgeschlagenen vier Einstellmodi würde es dann für alle 
Anwendungsfälle passen.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rainer W. schrieb:
> Hallo Jürgen,
>
> wer kommt schon drauf, dass die Regler falsch beschriftet sind. Prima .

Hallo Jungs, das war ich. In der Annahme, dass WELEC die Funktionen und 
das Menü der Agilent Scopes abgekupfert hat (was ja auch größtenteils 
stimmt) habe ich die Beschriftung von Agilent übernommen. Das scheint 
aber ja nicht zu stimmen. Werde ich dann entweder wieder rückgängig 
machen, oder die Funktion anpassen so dass es stimmt. Wie seht Ihr das?

Den Vorschlag von Rainer könnte man dann als Fernziel später mal 
umsetzen. Momentan bin ich an einer anderen Sache dran.

Gruß Hayo

p.s. Noch nie war Messtechnik so günstig. Hab gestern ein W2022A 
geschossen für ruinöse 153,- + Versand. Davon wagte ich als Studi nicht 
mal zu träumen...

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wurde kürzlich gefragt (in SFN) wie man am besten Netzspannungen mit 
unserem Oszi mißt, da die Spannungsbereiche dafür nicht so optimal 
ausgelegt seien (mit Tastkopf 10:1).

Folgender kurzer Hinweis:

Für solche Messungen lieber einen 100:1 Tastkopf verwenden.
Es werden gerade welche in der E-Bucht angeboten, habe mir auch gleich 
einen besorgt.

100:1 Hochspannungs- Tastkopf 2kV, 100MHz -> 30,- Flocken

Einer ist da noch zu haben.

Gruß Hayo

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

Hauptsache, Jürgen hat den Pulstrigger erstmal als funktionierend 
erkannt und die Reglerfunktion ist klar. Ich habe gerade noch mal mit 
deiner letzten 4.9 C2 probiert und eigentlich muß man nur wissen, dass 
im "><"-Mode auf dem "<"-Regler die Intervallbreite liegt. Vielleicht 
läßt sich als Sofortlösung mit der nächsten Release erstmal die 
Regler-Beschriftung korrigieren.

Hayo W. schrieb:
> Den Vorschlag von Rainer könnte man dann als Fernziel später mal
> umsetzen. Momentan bin ich an einer anderen Sache dran.

Wäre prima, dann hätte man beide Einstellvarianten zur Verfügung, eilt 
aber ja nicht.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beschriftung ist schon wieder geändert auf Delta t.

Alles wird gut...

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
da die Bestellannahme vorbei ist werde ich ich nun anfangen die Preise 
endgültig festzulegen. Sobald ich dann auch den Preis für die Platinen 
habe, werde ich euch den Gesammtbetrag und die Zahlungsmöglichkeiten 
mitteilen.

Die gute Nachricht ist, die LMH6518 konnte ich wieder von eBay beziehen. 
Deshalb beträgt der Stückpreis nur ca. 5,51€!
4 Stück sind noch zu haben:
http://stores.ebay.de/audiosector?_trksid=p4340.l2563

Alle weiteren News setzte ich ab jetz in den Hardware Thread.

Mfg,
Kurt

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

es geht mittlerweile wieder dem Jahresende entgegen. Dank der Arbeit von 
Jörg findet die Huckepackplatine ja bereits erste Unterstützung (ich 
hänge gerade am Einbau), auch wenn noch nicht alle Funktionalitäten 
umgesetzt sind (20MHz-Bandbreitenbegrenzung erfolgt am LMH und nicht 
mehr extern.
Nun ist es aber so, wie wir alle sicherlich wissen, dass dieses ominöse 
ADC-Register dafür sorgt, dass der Frequenzgang alles andere als flach 
verläuft und das Welec bei derlei Messungen macht was es will.
Wäre es nicht daher langsam an der Zeit sich dem Leon zu widmen, da 
damit  auch Messungen im HF-Bereich möglich werden? Mal ganz zu 
schweigen von den zusätzlichen Möglichkeiten, die sich damit bieten 
würden.
Es ist bedauerlich, dass sich noch niemand auf Alex's Terrain gewagt 
hat.

branadic

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Beschriftung ist schon wieder geändert auf Delta t.
>
> Alles wird gut...

Nö! Die paar Änderungen kannst Du doch wieder übernehmen..

Autor: manfred.h (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

möchte mich noch für die Bemühungen (speziell bei dir, Hayo) bedanken, 
das Oszi schrittweise brauchbar gemacht zu haben. Hatte viel Freude beim 
Einspielen einer neuen Firmware und mit den stetigen Verbesserungen. 
Leider muss ich mich von der Welec-Gemeinde verabschieden, da mein Oszi 
2024A offensichtlich unrettbar defekt ist. Leider.
Wünsche euch allen noch gute Fortschritte und viel Spaß bei der weiteren 
Entwicklung.

Manfred

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast den RAM nachgelötet?

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manfred,
wenn dein Gerät wirklich nicht mehr reparabel ist, würdest du es zum 
reverse-engeneering und für die Ersatzteile spenden?
Es soll noch geklärt werden, welche Verbindungen zwischen den 2 FPGAs 
vorhanden sind. Dazu müssten die FPGAs abgelötet werden, was nur bei 
einem defekten Gerät Sinn macht.

Außerdem bräuchte Bernhard (er besorgt die neuen Huckepackplatinen) 
einen Drehencoder.

Mfg,
Kurt

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gab es denn wenigstens ein würdiges Begräbnis?

Schade,

Hayo

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurt Bohnen schrieb:
> Außerdem bräuchte Bernhard (er besorgt die neuen Huckepackplatinen)
> einen Drehencoder.


Einen Drehencoder könnte ich noch spendieren. Ich hatte mir mal von den 
ALPS von Pollin (vor ca. 2 Jahren) ein paar zugelegt, weil bei meinenm 
Welec auch einer kaputtging. Passt ziemlich genau rein.

Gruß,
Bernhard


P.S.: gerade gefunden
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
und es sind diese
http://www.pollin.de/shop/dt/MDY2OTU3OTk-/Baueleme...

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie ich sehe habe die Drehencoder auch noch einen Druckschalter. Es kam 
ja mal die Frage ob die Signale des Druckschalters auswertbar seien. Hat 
da mal jemand recherchiert?

Ich bin leider gerade in der Firma und komme nicht an meine Unterlagen 
heran.

Wäre natürlich echt cool wenn man zusätzliche Schalterfunktionalität 
implementieren könnte.

Gruß Hayo

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na toll!
Ich glaube kaum, das (geschätzte) 20-30 Welec-Besitzer jetzt noch den 
Drehencoder gegen einen mit Druckknopp tauschen...
Was machen dann User, die nix zum drücken haben?

Gruß Michael

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Leute/Programmierer,

wurde meine Frage nach dem Leon wieder geschickt ignoriert!?

Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

Wäre gut, wenn ihr dazu mal ein Statement abgeben würdet.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Branadic,

nein nicht ignoriert, sondern zur Kenntnis genommen. Hab vorhin nicht 
darauf geantwortet, weil ich keine Zeit mehr hatte vor meinem 
Projektmeeting.

Ich würde mich ja gerne der Portierung auf das LEON-Design widmen, aber 
meines Wissens ist dieses noch nicht so weit, dass alle 
Hardwarefunktionen unterstützt werden. Das wäre aber für mich die 
Voraussetzung für eine Portierung.

Falls ich da falsch liege bitte korrigieren.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> na toll!
> Ich glaube kaum, das (geschätzte) 20-30 Welec-Besitzer jetzt noch den
> Drehencoder gegen einen mit Druckknopp tauschen...
> Was machen dann User, die nix zum drücken haben?

Also erstens denke ich dass es deutlich mehr WELEC-Besitzer sind (auch 
international), außerdem wären diese Funktionen dann (wie auch die 
LED-Funktionen) optional. Das heißt sie wären dann auch über die 
Funktionstasten verfügbar für alle die nicht löten wollen.

Der Austausch der Drehencoder scheint mir aber recht simpel und daher 
vermutlich auch für etliche Bastelwütige (wie mich) interessant zu sein.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Ich würde mich ja gerne der Portierung auf das LEON-Design widmen, aber
> meines Wissens ist dieses noch nicht so weit, dass alle
> Hardwarefunktionen unterstützt werden. Das wäre aber für mich die
> Voraussetzung für eine Portierung.
>
> Falls ich da falsch liege bitte korrigieren.

Nach aktuellem Stand wird die gesamte Hardware unterstützt, mit einer 
Ausnahme, derzeit ist das Design auf die Funktion von zwei Kanälen 
beschränkt, weil Alex kein Vierkanalgerät besitzt und noch immer 
unbekannt zu sein scheint, wie die beiden FPGAs miteinander 
kommunizieren.

branadic

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der Andre...du hast ja Recht!
Das Thema Leon3-Design, hatte ich auch schon mal versucht neu anzuregen.

Obwohl das Aufspielen der Leon3-Software garnicht so schwer ist, kommen 
warscheinlich nicht alle damit zurecht. Zugegeben, die Anleitung dafür 
und die dafür benötigten Tools, sind etwas verstreut.
Benötigt wird der Quartus-Programmer von Altera, USB-Blaster und der 
Waverecorder.
Was ist eigendlich der letzte Stand des Leon3 bzw. wo liegen die 
"W2000A.sof" und die dazugehörige "sram" Dateien?

Vielleicht würde noch mal eine "All-in-one" Anleitung zur Animation 
beitragen?!?

Ich selbst habe schon verschiedene Versionen getestet und war von der 
Geschwindigkeit sehr beeindruckt!

Gruß Michael

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ich weiß, ist der Leon VHDL mäßig fertig. Nur die Firmware fehlt 
noch. Ich habe Alex schon eine mail geschrieben und gefragt, wie weit er 
mit der Doku gekommen ist und wo sie zu finden ist.

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> der Andre...du hast ja Recht!
> Das Thema Leon3-Design, hatte ich auch schon mal versucht neu anzuregen.

Naja, wollte ja nur mal hören wie die Allgemeinheit dazu steht, 
schließlich sind die Grenzen des originalen Designs mehr als bekannt, 
spätestens bei Messungen von höherfrequenten Signalen ist Schluss und 
ein gutes Workaround gibt es ja offenbar dafür auch nicht. Zumindest mir 
missfällt diese "HF-Umschaltung", denn das auf dem Bildschirm 
präsentierte Ergebnis ist frei interpretierbar und nicht als 
Messergebnis zu bezeichnen.
Die Störungen, die wie kippende Bits ausschauen, sind ebenfalls 
zweifelhaft und im Leon-Design in der Form noch nicht aufgetreten.
Die Dezimationsfilter sollten ebenfalls nicht unterschlagen werden.

Alex hat ja nun gut Zeit und Arbeit investiert, da sollte sie doch auch 
mal Früchte tragen. Bis zur vollständigen Unterstützung für die 
4-Kanäler ist man ja nicht gezwungen das Design fest einzuspielen, 
sondern kann das auch nur temporär vornehmen und gerade das muss man ja 
nicht unbedingt als Nachteil sehen.

Das Alex sich in letzter Zeit nicht mehr intensiv darum kümmert liegt 
nicht zuletzt auch am fehlenden Feedback und an fehlender Unterstützung, 
durchaus nachvollziehbar.

Meiner ganz persönlichen Meinung nach hätte man dem Leon schon viel 
früher die notwendige Aufmerksamkeit widmen müssen.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Branadic,

leider dringt zum Stand der Dinge in Sachen LEON nicht allzu viel an die 
"Öffentlichkeit". Ich wußte bislang nicht, dass die Entwicklung schon so 
weit fortgeschritten ist, dass die gesamte Hardware bis auf die Kanäle 
3+4 unterstützt wird.

Wenn jetzt noch die Ansteuerung der Hardware brauchbar dokumentiert 
wäre, sähe ich eigentlich (fast) keinen Hindernisgrund mit der 
Portierung anzufangen.

Zum (fast): Leider hatte ich massive Schwierigkeiten das LEON-Design bei 
mir zum Laufen zu bringen. Als alter EDVler und Computerfreak der ersten 
Stunde traue ich mir schon zu das alles richtig hinzukriegen. Dennoch 
habe ich 2 Tage lang vergeblich versucht das Ganze bei mir zum Laufen zu 
bringen. Offensichtlich gab es Probleme bei der richtigen Registrierung 
des USB-Device. Hatte das auch schon mal jemand?

Ich bin aber grundsätzlich kein Aufgeber und werde das gerne nochmal 
versuchen. Die Aussicht auf mehr Performance ist schon sehr verlockend!

Weiterhin kommt jetzt ein alter Studienkollege von mir mit an Bord, der 
unter Umständen diese Plattform für seine (leicht verspätete) 
Diplomarbeit nutzen wird.

Es könnte noch sehr interessant werden...

Gruß Hayo

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hayo
> Also erstens denke ich dass es deutlich mehr WELEC-Besitzer sind (auch
> international), außerdem wären diese Funktionen dann (wie auch die
> LED-Funktionen) optional. Das heißt sie wären dann auch über die
> Funktionstasten verfügbar für alle die nicht löten wollen.

Okay, dann nehme ich natürlich alles zurück und behaupte das Gegenteil! 
;-)

> Der Austausch der Drehencoder scheint mir aber recht simpel und daher
> vermutlich auch für etliche Bastelwütige (wie mich) interessant zu sein.
Ich bin da ja genauso, wie du weißt und habe da auch keine 
Berührungsängste mit dem Lötkolben!

@Kurt
> Soweit ich weiß, ist der Leon VHDL mäßig fertig.
Ach? Jetzt wird's spannend!

> Nur die Firmware fehlt
> noch. Ich habe Alex schon eine mail geschrieben und gefragt, wie weit er
> mit der Doku gekommen ist und wo sie zu finden ist.

...das wäre chic!!!
Btw. war da nicht schon mal eine vorab Testversion für das Ram, dieses 
Jahr, oder war das schon länger her?
Vielleicht mache ich mich mal auf die Suche, wenn Zeit is'.

@branadic
> Das Alex sich in letzter Zeit nicht mehr intensiv darum kümmert liegt
> nicht zuletzt auch am fehlenden Feedback und an fehlender Unterstützung,
> durchaus nachvollziehbar.
vielleicht auch u.a. an den von mir angegebenen Gründen der 
Installation?!?
Hayo hat mit dem Aufspielen der FW(LEON3) auch Probleme gehabt, sonst 
hätte er bestimmt schon dazu etwas beitragen können, denke ich.

Ich hatte mal eine bebilderte Installation(Altera)mit aufspielen der FW 
für das Ram gepostet, soweit ich mich erinnern kann. Wenn Bedarf 
besteht, könnte ich das mal heraus suchen, oder liegt das irgendwo im 
Gethub oder SF?

Gruß Michael

EDIT: Hayo, warst mal wieder schneller... :-(

Autor: Kurt Bohnen (kurt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb (per mail):
> Eine richtige Doku habe ich dafür noch nicht gemacht.
> Stattdessen sind im Prinzip alle SFR-Zugriffe implementiert und zu 98%
> mit Erfolg getestet.
>
> Ich glaube schon, dass die Funktionsaufrufe ziemlich selbsterklärend
> sein sollten.
> Die GUI ist nicht von mir!

@Michael,
am besten suchst du die Anleitung mal raus, dann kann man sie gut 
sichtbar verlinken.

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, nachdem einige Zeit nichts über das nächste Release zu hören war 
hier eine Vorschau auf die 5er Version.

Was neu ist und warum es so lange gedauert hat muß ich wohl nicht 
erklären,
 da die Screenshots für sich sprechen.

Screenshot 1 -> Normaler Analogmodus
Screenshot 2 -> Digitalmodus TTL
Screenshot 3 -> Digitalmodus CMOS

Zur Zeit alles noch beta. Bis zur Fertigstellung muß noch einiges an 
Feinarbeit gemacht werden.

Damit dürfte die Messlatte für vergleichbare Oszis wieder etwas höher 
liegen...

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo,
kannst du was mit der leon.zip anfangen?

Es ist schade dass es keine Dokumentation gibt, aber die Leon Firmware 
hat noch einen so kleinen Funktionsumfang, dass das reverse engeneeren 
deutlich einfacher sein sollte als bei der Nios Firmware. Wie siehst du 
das, als W2000A erfahrener Programmierer, oder auch alle anderen die 
sich an der leon Firmware beteilige  möchten?

Mfg,
Kurt

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Was neu ist und warum es so lange gedauert hat muß ich wohl nicht
> erklären,
>  da die Screenshots für sich sprechen.
>
> Screenshot 1 -> Normaler Analogmodus
> Screenshot 2 -> Digitalmodus TTL
> Screenshot 3 -> Digitalmodus CMOS

Der Vollständigkeit halber müssten ECL bzw. PECL (min. 150mVpp, typ. 
800mVpp, max. 1Vpp) und RSPECL (min. 320mVpp, typ. 400mVpp, max. 
420mVpp) auch Erwähnung finden.

branadic

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
branadic schrieb:
> Der Vollständigkeit halber müssten ECL bzw. PECL (min. 150mVpp, typ.
> 800mVpp, max. 1Vpp) und RSPECL (min. 320mVpp, typ. 400mVpp, max.
> 420mVpp) auch Erwähnung finden.

Oder gleich eine Option "User"-defined mit Level-Definition über's 
Setup.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kurt

Hatte noch keine Zeit mir die Datei anzusehen.


@Branadic

Du hast recht, die Liste ist noch nicht komplett. Ich wollt nur erstmal 
eine Grundliste zur Verfügung stellen.


@Rainer

Auch das wäre denkbar. Die Auswahl von bestimmten Logiktypen mit festen 
Einstellungen finde aber schon recht komfortabel. Dem weiteren 
(späteren) Ausbau steht natürlich nichts entgegen.


Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kurt

Habs jetzt mal auf die Schnelle überflogen. Leider ist die Source nur 
sehr spärlich kommentiert, das erinnert mich an die alte WELEC-FW.

Es war auf den ersten Blick nicht erkennbar ob alle Hardwarefunktionen 
unterstützt werden.

Funktionen um den DAC anzusprechen und den Trigger zu setzen habe ich 
wohl gefunden. Einen UI-Interrupthandler habe ich aber zum Beispiel 
nicht finden können, auch den Zugriff auf das Flash konnte ich noch 
nicht lokalisieren.

Auch waren die Hardwareansteuerungen nicht auf den ersten Blick 
selbsterklärend. Da müßte man also erstmal forschen, was eigentlich 
vermeidbar wäre wenn es eine Doku zu den Hardwareschnittstellen gäbe.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rainer W. schrieb:
> branadic schrieb:
>> Der Vollständigkeit halber müssten ECL bzw. PECL .. auch Erwähnung finden.

Ich habe erstmal nur Single Ended Logiktypen berücksichtigt, da die 
Messung von differenziellen Pegeln (ECL, PECL, LVDS, RS422 etc.) mit 
unserem Gerät wegen des gemeinsamen Grounds so nicht ohne Weiteres 
möglich ist.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

ECL-Pegel implizieren nicht, dass der Ausgang differentiell sein muss, 
sie können genauso gut single-ended Verwendung finden.
Ungeachtet der Tatsache, dass ich diese Funktionen selbst nicht 
benötige, wollte ich nur darauf aufmerksam machen.

branadic

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin,

> @Michael,
> am besten suchst du die Anleitung mal raus, dann kann man sie gut
> sichtbar verlinken.

hier schon mal der Link für die Installation der benötigten 
Programme(Englisch):
Installation-LEON3 im Detail:
Quartus-II-Programmer, USB-Blaster, Waverecorder
http://sourceforge.net/apps/trac/welecw2000a/wiki/...

LEON3 FPGA-Design-Firmware latest Preview1.1
http://sourceforge.net/projects/welecw2000a/files/...
------------------------------------------------------------------------ 
---
Vorab eine Kurzanleitung:

Am DSO werden "no Buttons" gedrückt!!!
Nach dem das DSO im Quartus-II-Programmer als
"Nios Evulation Board"(HID-HumanInterface) erkannt wird (Hardware 
Setup), kann das LEON3-Design über "USB" eingespielt 
werden---(w2000a.sof)---.
Wichtig! Im Quartus-II Prog.-Fenster darf nur "1 
Device"(z.B.)"EPC35F484" stehen!
Danach wird die Software---(w2000a.bin)--- am "DSO-COMPORT" mit dem 
Waverecorder über eine Batchdatei mit den erforderlichen Parametern 
aufgesetzt.
Es wird nur das "RAM" beschrieben. Nach dem Aus- und wieder Einschalten 
ist alles wie voher!
------------------------------------------------------------------------ 
---
Ich will mal schauen, ob ich das mit einer bebilderten Doku hinbekomme. 
Die Bilder habe ich schon, fehlt nur noch der Text...

(by Alex) LEON3-welec2000a
https://github.com/alexvie/welecw2000a/tree/11357b...

Ich hatte mal auf GITHUB das komplette Projekt herunter geladen mit dem 
Filnamen: alexvie-welecw2000a-bcc9464(entpackt 36MB), leider finde ich 
die Quelle nicht mehr, hab's aber auf der Platte. Ob es das Aktuellste 
ist, kann nur Alex beantworten

Ansonsten bin ich hier noch fündig geworden:
https://github.com/alexvie/welecw2000a/tree/11357b...

Wenn man auf dieser Seite ist, kann man das Qellcode-Projekt als 
ZIP-File 9MB(oben links) herunterladen, vielleicht kann Hayo damit was 
anfangen?!?

Gruß Michael

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Hayo, super das habe ich mir schon immer gewünscht unverrauschte 
Digitalsignale wie bei einem LA, für Dinge bei den man die 
Signalqualität schon für ok befunden hat und dann auch kein Rauschen 
mehr braucht.

Anscheinend funktioniert der Trigger inzwischen besser ich hatte früher 
immer Probleme wenn die Triggerschwelle sehr niedrig eingestellt war 
erst ab ca. 0,5-1V funktionierte das ganze zuverlässig.

Hayo W. schrieb:
> da die Messung von differenziellen Pegeln (ECL, PECL, LVDS, RS422 etc.) mit
> unserem Gerät wegen des gemeinsamen Grounds so nicht ohne Weiteres möglich ist.
differentiell muss aber nicht bedeuten dass die beiden Pegel 
unterschiedliche Potentiale haben.
siehe CAN
http://www.kfztech.de/kfztechnik/elo/can/bmw2.JPG

Ich fände es super wenn man das integrieren könnte, dann würde man nicht 
mal mehr einen CAN-Treiber brauchen sondern könnte direkt mit 2 Kanälen 
auf den CAN Bus und aufzeichnen.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Branadic

Meines Wissens werden die ECL-Logiktypen konstruktionsbedingt immer 
differenziell verwendet, aber vielleicht gibt es auch Ausnahmen.

ECl hat ja einen sehr kleinen Spannungshub, der eigentlich nur möglich 
ist wenn durch den differenziellen Betrieb das Rauschen bzw. die 
Störeinflüsse kompensiert werden.


@Michael

An der Anleitung lag es bei mir nicht. Ich hatte alles nach der 
Anleitung durchgeführt. Bei der USB-Erkennung ist irgendwas 
schiefgelaufen, so dass das Device nicht in Quartus erschien.

Gruß Hayo

Autor: Michael D. (mike0815)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> @Michael

> An der Anleitung lag es bei mir nicht. Ich hatte alles nach der
> Anleitung durchgeführt. Bei der USB-Erkennung ist irgendwas
> schiefgelaufen, so dass das Device nicht in Quartus erschien.

> Gruß Hayo

Ok,
ich habe jetzt mal ein komplettes Treiberpaket aller benötigten Treiber 
gepackt, da im Download nicht wirklich alle enthalten sind.

Den Ordner "CyUsb" inkl. "CyUsb.spt" in die c:\Windows\Sytem32 kopieren.

CyUSB.sys und CyUSB.inf nach c:\Windows\System32\Drivers.

Die restlichen 3 dll's plus die usbblstr.sys nach c:\Windows\System32

jetzt muß das aber hinhauen!

Gruß Michael

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werd's noch mal versuchen. Mal sehen ob ich es dieses Wochenende 
schaffe.

Gruß Hayo

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
gerade habe ich ein wenig mit dem Welec gearbeitet und möchte eine 
kleine Erweiterung anregen, die ich sehr vermisse:
Könnte man an geeigneter Stelle die Bandbreite einblenden? Das ist bei 
Verwendung der verschiedenen Filter eine sehr wichtige Information.

Gruß
Michael

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das LEON3 Design jetzt auf einem 2-Kanaler funktioniert und 
eventuell die Software einfach darauf anzupassen ist. Dann ist ja die 
komplette Software des Oszis Open Source. Könnte man hier nicht ansetzen 
und auch einen Schaltplan und eine Leiterplatte entwerfen die zu dem 
FPGA Desgin kompatibel ist?

Das Oszi besteht aus:
Eingangsstufe: Es existiert schon ein alternativer Schaltplan
ADC
FPGA
Displayschnittstelle
Tasten
Stromversorgung DC/DC aus 12 - 24V

Mfg

Michael

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwar eine sehr schöne und reizvolle Idee aber für die paar Euro die die 
Welecs kosten wird man da keinen Selbstbau hinbekommen. Dazu ein 
Gehäuse, Display...
Obwohl sich wahrscheinlich schon Anhänger finden würden, wenn die 
Selbstbauplattform erstmal voll funktionsfähig steht.

Michael

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Display alleine bestellt kostet schon mehr als ein in der E-Bucht 
geschossenes gebrauchtes DSO von WELEC...

Eine andere Idee, die ich mit meinem ehemaligen Studienkollegen 
diskutiert habe, ist eine Koprozessorplatine mit einem DSP drauf an den 
Datenbus anzukoppeln und da die rechenaufwändigen Sachen drauf berechnen 
zu lassen.

Das dürfte bei FFT und Filterberechnungen einen echten 
Geschwindigkeitsschub geben, da der DSP solche Sachen quasi in Echtzeit 
berechnet. Entsprechende Boards gibt es z.B. von Motorola oder Texas 
Instruments als Evaluation Kits.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hat etwas gedauert, aber dafür läuft es jetzt stabil. Die Logikpegel des 
Logic Processors sind zur Zeit nur für nicht modifizierte Geräte 
eingestellt.

Eine Anpassung für andere Hardware (24/33 Ohm bzw Addon) ist in 
Vorbereitung.

Funktionieren sollte es aber trotzdem, wenn auch die Schaltschwellen 
dann nicht ganz genau sind.

Gruß Hayo

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

W2022A 1.2.BF.5.0

da scheint's ein Problem zu geben:

Aquire -> Button Logic(Off)-> TTL 5V -> Menu beendet nicht.
Weitere Betätigungen dieser Taste scrollen zwar durch die Auswahl, der 
Menupkt. endet aber nicht. Nur z.B. Druck Average(Off) beendet den Pkt.
Die Anzeige steht weiterhin auf: Logic (Off). Betätigt man wieder 
Logic(Off) sieht man das die TTL 5V aber angehakt sind.

Dann z.B. wieder Average(Off) und es 'hakt' nun auch dieser Menu-Pkt.

Mit dem Drehgeber ausgewählt funktioniert es.

Gruß
Robert

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

Robert schrieb:
> W2022A 1.2.BF.5.0
>
> da scheint's ein Problem zu geben:
>
> Aquire -> Button Logic(Off)-> TTL 5V -> Menu beendet nicht.
> Weitere Betätigungen dieser Taste scrollen zwar durch die Auswahl, der
> Menupkt. endet aber nicht. Nur z.B. Druck Average(Off) beendet den Pkt.
> Die Anzeige steht weiterhin auf: Logic (Off). Betätigt man wieder
> Logic(Off) sieht man das die TTL 5V aber angehakt sind.
>
> Dann z.B. wieder Average(Off) und es 'hakt' nun auch dieser Menu-Pkt.

ACK

Schönen Sonntag!

Gruß
Jürgen

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, das isr der Menü-Timer, ich dachte das hätte ich gefixt.

Korrigiere ich und gebe das nachher raus.

Gruß Hayo

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Korrigiere ich und gebe das nachher raus.
>
> Gruß Hayo

Ich sortiere eben die Pulse Width -Geschichte in die Version 5.0. Dauert 
noch ein paar Minuten. Ich stelle die geänderten Dateien dann hierher 
und Du kannst das übernehmen. Und natürlich die Button Beschriftung 
wieder zurück ändern :-)

Gruß Jürgen

Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

hier sind die 4 geaenderten Dateien.

Gruß Jürgen

Autor: alex008 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Liebe Gemeinde!

Freut mich, dass ihr euch jetzt wieder für meine Diplomarbeit 
interessiert.

Zum "aktuellen" Stand meiner Entwicklung:

"Fehlerfrei" und kaum verbesserbar:
FPGA:
LEON3 + Debug Support Unit im FPGA
Signalerfassung, inklusive der digitalen Dezimationsfilter!
SRAM-Anbindung (bei den scheinbaren EMV-Problemen hat das eine abnormal 
lange Zeit gebraucht, ging erst gut und schnell, nachdem ich den 
SRAM-Controller selbst geschrieben habe)
9 Bit Farben VGA: Bitte nur darauf schreiben, nie davon lesen ->
(Cache-Verhalten)!
DAC + restliche analoge Einstellungen über GPOs.
Trigger: Auto, Normal + Glitch (1 Sample!) über Hysterese


Firmware:
Treiberfunktionen für den Trigger, Abtastgeschwindigkeit, DAC Offset 
(ohne Kalibrierung per Software), Auslesen des Triggerspeichers 
(Samplebuffers) im Normal Mode.
Teilen der seriellen Schnittstelle mit dem integrierten Programmer 
(Debug Uart).
Screenshot

Waverecoder:
Upload, Backtrace, saubere Schnittstellentrennung (UART, Debug UART, 
nicht implementiert Ethernet)
Setzen von Befehlen SetTrigger, ReadData, WriteData über den Debug UART.
Linux, MAC, Windows Unterstützung.

Nachteile:
Debuggen geht nur eingschränkt mit dem grmon und einem 6.? GDB.
Noch kein Betriebssystem in der Firmware,
Slogs Treiber zum Programmieren des FPGAs funktioniert zwar unter 
Windows, aber das installieren kann sich als schwierig erweisen.
Unterschiede bei der Linux-Treiberinstallation für den FPGA-Programmer 
je nach Kernelversion.
Die Software steckt noch ziemlich in den Kinderschuhen.

@Kurt:
Die fehlenden Pin-Zuweisungen der Adress-Datenbussanbindung zwischen den 
FPGAs kann man mit zwei VHDL Designs ohne Demolierung des Boards 
feststellen.
Bei einem schickt man bspw. Rechtecksignale rein, beim anderen ließt man 
auf den Kanäle das Signal, speichert es und ließt es mit Quartus aus.
So hat das warscheinlich auch Slog gemacht.

@Michael
Das FPGA Design ist auf eine möglichst gute Portierbarkeit ausgelegt.
Wenn hier jemand beabsichtigt, ein eigenes Oszi damit zu bauen, bitte 
unbedignt einen Ethernet PHY mit Isolator zum Debuggen und so verwenden 
draufpacken!
Der LEON3 hat leider keine freie USB-Schnittstelle intern, die man nur 
Einbinden muss.

MfG
Alexander

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

leider war diese Page nicht erreichbar in den letzten Stunden, daher von 
mir keine Rückmeldung. Das Problem ist erkannt. Es ist der Timer 3, der 
beim Button drücken ausgelöst wird.

Das tritt nur im Standardlayout auf, deshalb war mir das nicht 
aufgefallen.

Workaround ist also erstmal das Layout auf eines der "Mono" Layouts zu 
ändern, dann ist alles gut.

Gruß Hayo

p.s. Korrektur gibts morgen

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alex,

> Freut mich, dass ihr euch jetzt wieder für meine Diplomarbeit
> interessiert.
na, auf jeden Fall!
Ich bin ja nur User...

> Zum "aktuellen" Stand meiner Entwicklung:
> "Fehlerfrei" und kaum verbesserbar: ......

hast du für uns was Kompiliertes (w2000.sof u. bin) zum testen da?
Jetzt werde ich neugierig! :-)

@Hayo
> Das tritt nur im Standardlayout auf, deshalb war mir das nicht
> aufgefallen.

stimmt, kann ich bestätigen. Ich hatte das mehrmals getestet, allerdings 
nicht mit dem Standart-Layout und konnte da keine Unstimmigkeiten 
feststellen...deswegen hatte ich erstmal die Klappe gehalten ;-)
Hast mal wieder eine tolle Arbeit gemacht!

Gruß Michael

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alex008 schrieb:
> Liebe Gemeinde!
>
> Freut mich, dass ihr euch jetzt wieder für meine Diplomarbeit
> interessiert.

Hi Alex, das Interesse war immer da, nur habe ich auf einen Stand der 
Entwicklung gewartet der für eine Portierung geeignet ist.

Wenn das Ganze eine Diplomarbeit ist, dann müßte das doch recht gut 
dokumentiert sein. Stellst Du uns die Doku zur Verfügung? Eine 
detailierte Beschreibung der Register bzw. der Ansteuerung ist natürlich 
mit das Wichtigste (UARTs, Timer, ADCs, DACs, Display, Drehencoder, 
Buttons etc).

Wie sieht es denn mit den Kanälen 3 + 4 aus. Wenn ich das richtig 
herausgehört habe gehört der zweite FPGA nicht zu Deiner Diplomarbeit. 
Wird hier noch eine Umsetzung erfolgen, oder bleibt es bei zwei Kanälen?

Ist das von Kurt gepostete Coding zur Ansteuerung des LEON das 
Aktuellste, oder gibt es schon aktuellere Routinen?


Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So hier die Korrektur. Hab auch noch die Änderung beim Pulstrigger 
eingebaut - allerdings in einer etwas von Jürgens Version abweichender 
Implementierung. Das Ergebnis ist aber das Gleiche. Es wird nur an einer 
anderen Stelle subtrahiert. An den Registern habe ich auch noch etwas 
rumgespielt.

Gruß Hayo

Autor: alex008 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Der LEON3 hat einen AHB-Bus und einen APB-Bus (Adress-Datenbus).
Davon habe ich einen AHB-Teilnehmer für die SRAM/Flash-Anbindung 
geschrieben, ein AHB-Teilnehmer ist der Triggerspeicher (32KB) und ein 
APB-Teilnehmer ist das SFR mit 32 Register.
Alle anderen Geräte sind die originalen Teile vom LEON3.

Das beinhaltet den konfigurierbaren Framebuffer-SVGA mit 16 Bit Farbe, 
welcher sich die Daten aus dem SRAM selbst holt.
Dabei ist auch ein UART, der dem 16550 ähnlich und einfachst zu bedienen 
ist.
Was auch beim LEON3 niemals fehlt ist die DSU (Debug Support Unit) und 
eine seiner Schnittstellen, hier ist es der Debug UART.
Für alle Komponenten, welche ich nicht geschrieben habe, gibt es 3 
Dokumente bei www.gaisler.com oder im Repository:
sparcv8.pdf, grlib.pdf und grip.pdf.
Die Startadressen von allen Busteilnehmern stehen in der Source-Datei 
DSO_Main.h.

@Hayo
Es gibt für alle Hardware-Ansteuerungen, die du wissen möchtest, 
einfache LOW-Level Routinen, die sicher zu 95 % fehlerfrei sind 
(externer Trigger ungetestet!, der Rest sollte passen).
Schwieriger wird es bei der hochperformanten GUI, die noch nicht 
ausgereift ist.
Auch hier ist das hinzufügen von Menüeinträgen relativ leicht, bei der 
Darstellung (GUI-Core) gibt es aber noch ein paar Probleme zu lösen.
Wenn du es geschafft hast, mit dem originalen Quellcode zurechtzukommen,
sollte ein Umstieg für dich recht leicht sein.
Robert, unser GUI Entwickler, benötigte von mir zum Einarbeiten so gut 
wie keine Hilfe.
Falk schrieb mir auch einmal, dass ihm meine Routinen für die 
Signalerfassung wesentlich besser sein sollen, als die von der 
NIOS-Seite.

Beispiel Debug Uart Protokoll:
Erstes Byte: Ein Bit für Schreiben oder Lesen, rest für die Datenmenge 
in DWORDs (Bytes *4). Danach folgen 4 Byte für die Adresse, und am 
Schluss schickt man, oder man bekommt die Daten.

@Michael
Beim LEON3-Zeug funktionieren leider nur die LOW-Level Treiberroutinen 
gut, mehr als beim Preview 1.1 ist da vom Benutzer nicht zu sehen.
Mir fehlt leider die Zeit, um den Rest weiter zu entwickeln.

MfG
Alexander

Autor: Ingo M. (ingom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alex008 schrieb:
> Auch hier ist das hinzufügen von Menüeinträgen relativ leicht, bei der
> Darstellung (GUI-Core) gibt es aber noch ein paar Probleme zu lösen.

Wie äußern sich diese Probleme?

MfG Ingo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Alex,

bei dem Coding welches Kurt hier gepostet hat fehlen noch Headerdateien 
und von GUI hab ich da auch nichts drin gefunden. Gibt es andere 
Sourcen?

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,
diese Seite kennst du?

https://github.com/alexvie/welecw2000a

Mfg,
Kurt

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein,

bis eben nicht. Sonst hätte ich wohl auch die Frage nicht gestellt ;-)

Aber dann hat sich ja alles geklärt. Soweit ich das auf die Schnelle 
gesehen habe ist ja alles vorhanden um sich da weiter schlau zu machen.

Danke

Hayo

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt frage ich mich, wozu ich mir die Mühe gemacht habe???

Siehe: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht böse sein, ich hatte einfach noch keine Zeit mir alles 
durchzulesen. Ich schaffe es zwischendurch manchmal nur kurz einen Blick 
auf die Postings zu werfen und habe dann auch keine Zeit den Links 
nachzugehen.

Ich arbeite mich aber voran...

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dennoch bleibt die Frage ob die fehlenden zwei Kanäle noch implementiert 
werden oder ob das Projekt jetzt abgeschlossen ist.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist einfach so, dass dem Alex nur ein 2-Kanal-Gerät zur Verfügung 
steht und stand und er deswegen die anderen beiden Kanäle nicht 
implementieren konnte.

branadic

Autor: Dirk B. (garag)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin moin,

ich könnte z.B. Alex ein 4 Kanal Gerät zur Verfügung stellen. Wäre es 
dann in absehbarer Zeit möglich das Leon Design auf auf die 4 Kanäler zu 
erweitern ?

Hat Alex dazu lust und Zeit ?

Gruß
Dirk

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ich momentan keine Zeit für das Projekt habe und trotzdem indirekt 
hilfreich am Projekt mitwirken will, kann auch ich meinen 4-kanaler dem 
Alex leihen, und würde noch einen LA1034 LogicAnalyzer dazupacken.

Weiß jemand, was aus
manfred.h s (Gast) Datum: 17.10.2011 21:18 Gerät wurde?
Ich würde es ihm gerne abkaufen (und evtl.Alex zur Verfügung stellen).

Tipp: ibäh:audiosector hat neben den LMHs ca. 2250 sehr interessante 
Teile im Angebot, u.a. Panasonic Rotary Encoder cgi.ebay.de/170645192579 
(zu testen, ob sie ins Oszi passen), evtl. bietet sich eine 
Sammelbestellung (im Forum Markt) an.

Hat schonmal jemand bei Welec angefragt, was die mit defekten Geräten 
machen? Vielleicht können sie welche zum Debuggen zur Verfügung stellen. 
Immerhin profitieren sie von unserer Arbeit ziemlich.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eProfi schrieb:
>
> Hat schonmal jemand bei Welec angefragt, was die mit defekten Geräten
> machen? Vielleicht können sie welche zum Debuggen zur Verfügung stellen.
> Immerhin profitieren sie von unserer Arbeit ziemlich.

Das ist keine schlechte Idee. Ich hatte mir auch schon überlegt ob man 
nicht mal fragen könnte ob WELEC Dukumentation zu einigen der Register 
raustut, wenn sie das VHDL schon nicht zur Verfügung stellen 
wollen/können. Das könnte uns u.U. etwas weiter bringen.

Bin übrigens nicht untätig, sondern bin ziemlich intensiv am 
experimentieren mit FIR-Filtern und der sin(x)/x Interpolation. Ist 
ziemlich viel Recherche- und Testaufwand, aber ich arbeite mich voran. 
Meine Vorlesungen in Digitale Systeme sind halt schon etwas länger her. 
Da muß man sich erstmal wieder reinarbeiten.

Gruß Hayo

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

ich muß nochmal auf den Pulstrigger zurückkommen. Entweder habe ich da 
die neue Bedienung nicht verstanden oder es hat sich im "><"-Mode mit 
der BF 5.0 C2 ein Bug eingeschlichen:

Mit den Zeitgrenzen "> 40µs", "< 60µs" gelingt es mir nicht, z.B. auf 
einen 50µs Digitalpuls zu triggern (Signal 5V, Normal Trigger 3V).

Mit der BF 5.0 und entsprechenden Einstellungen ("> 40µs", "dt 20µs") 
funktioniert es einwandfrei.

In beiden Versionen gibt es nach Aufruf von Default Setup noch ein 
Problem mit den Einstellung vom Pulstrigger: Die im Puls-Width Trigger 
Menü angezeigten Werte entsprechen danach nicht den Geräteeinstellungen, 
m.a.W. erst wenn man z.B. den Kanal neu wählt und die Zeitgrenzen 
ändert, stimmen die angezeigten Werte. Ohne explizite Kanalwahl erfolgt 
kein Trigger.

Wenn du mal eine Ablenkung von FIR, IIR und Co. brauchst, kannst du 
vielleicht da noch einmal gucken.

Schönes Wochenende

Gruß
Rainer

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
p.s. zum Pulstrigger:
Für die Einstellung der Zeitlimits ist die Bereichsumschaltung noch sehr 
"praxisfern", insbesondere im "><"-Mode. Durch die momentan feste 
Schrittweite (8ns, 1µs, 1ms) lassen sich kurz über den Umschaltpunkten 
(1µ bzw, 1ms) die Zeiten nur sehr grob einstellen und kurz unterhalb von 
1ms dreht man sich einen Wolf.
Das führt auch dazu, dass es z.B. nicht möglich auf Pulse von z.B. 1.9 
ms zu triggern, falls gleichzeitig solche von 1.1 ms vorhanden sind, 
weil in solch einem Fall das dt Fenster relativ sehr groß sein muß.

IMHO sind im "><"-Mode als Einstellparameter ">" und "dt" wesentlich 
besser geeignet, weil man bei ">" und "<" für Pulslängenänderung immer 
zwei Regler bedienen muß.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mit den Zeitgrenzen "> 40µs", "< 60µs" gelingt es mir nicht, z.B. auf
> einen 50µs Digitalpuls zu triggern (Signal 5V, Normal Trigger 3V).

Bei mir hat es manchmal funktioniert und manchmal bicht. Mir ist aber 
nicht ganz klar woran es liegt.


> In beiden Versionen gibt es nach Aufruf von Default Setup noch ein
> Problem mit den Einstellung vom Pulstrigger: Die im Puls-Width Trigger
> Menü angezeigten Werte entsprechen danach nicht den Geräteeinstellungen,
> m.a.W. erst wenn man z.B. den Kanal neu wählt und die Zeitgrenzen
> ändert, stimmen die angezeigten Werte. Ohne explizite Kanalwahl erfolgt
> kein Trigger.

Hmm, das muß ich mal prüfen. Vielleicht fehlt nach dem Default Setup die 
Triggerinitialisierung -> danke für den Hinweis

> IMHO sind im "><"-Mode als Einstellparameter ">" und "dt" wesentlich
> besser geeignet, weil man bei ">" und "<" für Pulslängenänderung immer
> zwei Regler bedienen muß.
Da hast Du eigentlich Recht. Wie sehen das dei Anderen? Sollen wir das 
wieder zurückändern?

Die Abstufung der Einstellwerte war mir auch schon mehrfach negativ 
aufgefallen - ist noch alter Sourcecode. Da werde ich mal versuchen was 
dran zu ändern.

Gruß Hayo

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei > < kann man aber direkt 180-200µSek einstellen, bei der anderen 
Variante müsste man 190 +- 10 einstellen.
Vielleicht kann man es ja wählbar machen ob > < oder > dt

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Die Abstufung der Einstellwerte war mir auch schon mehrfach negativ
> aufgefallen - ist noch alter Sourcecode.

Bei der Zeiteinstellung ist IMHO eine Auflösung im Bereich 1..5% ganz 
praktisch. Wie wäre ist mit der üblichen 1-2-5 Log-Approximation, also 
z.B.
      Bereich       Schrittweite
 1.00 ..  2.00 ms     0.02 ms
 2.00 ..  5.00 ms     0.05 ms
 5.00 .. 10.0  ms     0.10 ms
10.0  .. 20.0  ms     0.20 ms
u.s.w.
Das sollte fein genug sein und man kurbelt sich nicht tot ;-)

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe mir das mal an wenn ich hier mit den Filtern durch bin. Zur 
Zeit läuft mein FIR mit Circular Buffer langsamer als der nicht 
optimierte FIR mit Shiftlogik.

Nebenbei habe ich im direkten Vergleich festgestellt, dass die Filter 
die ich ohne fundierten Algorithmus nur nach logischen Überlegungen 
selbst entworfen habe (Smooth, Strong), deutlich schneller sind und 
trotzdem ein genauso gutes Ergebnis aufweisen - da bin ich doch schon 
etwas überrascht und es zeigt, dass die Überlegungen grundsätzlich 
richtig waren.

Gruß Hayo

Autor: alex008 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Dirk!

Vielen Dank für dein Angebot, mir deinen 4 Kanäler zu borgen.
Ich werde es aber nicht annehmen, da mich das zu sehr unter Zugzwang 
stellen würde.

Die FPGAs der 4 Kanäler sind laut Crazor (lange nichts mehr von ihm 
gehört) über den Adress-Datenbuss verbunden.
Beim einem schön hirarchischen Aufbau der Software sollte es nicht allzu 
schwer sein beide FPGA Designs zu verbinden.
Man müsste unter Umständen nicht einmal den FPGA mit dem Softcore 
ändern, wenn man den zweiten FPGA dazu einfügt.
Auch beim anderen FPGA (für Kanal 3 und 4) müsste man nur die 
Signalerfassungsteil herausnehmen und die Adress-Datenbuss-Schnittstelle 
adaptieren.
Was ein wenig aufwendiger werden könnte, wäre das Auffinden der ADC Pins 
für Kanal 3/4.

@Hayo
Ich habe dir doch schon einmal einen hoch optimiertes 
Polyphasen-Interpolationsfilter geschickt (optimierter FIR-Filter für 
die Interpolation, der sich die Multiplikation mit den eingefügten 0ern 
spart).
Probiers vielleicht mit Pointer-Zugriffen anstatt von Array-Zugriffe auf 
den Puffer, damit spart man sich im Schnitt 1/3 von der Zeit!

MfG
Alexander

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Alex,

ja danke für den Hinweis. Mit dem Filter hatte ich es zuesrst probiert, 
aber es lief nicht - keine Ahnung warum.

Mittlerweile bin ich auch schon weiter. Mein FIR mit Circular Buffer ist 
inzwischen pfeilschnell dank geänderter Pointerberechnung und Lookup 
Table.

Ich bin gerade dabei die Koeffizienten für den sin(x)/x Filter zu 
berechnen.
Mit einem Raised Cosinus Filter hate ich es schon probiert, das ergibt 
leider keine vernünftige Interpolation, da es kein idealer Tiefpass ist.

Gruß Hayo

Autor: alex008 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo!

Am besten wäre es meiner Meinung nach, wennst du dir einmal die 
sin(x)/x-Koeffizienten für 4 Bandbreiten mit gleicher Länge generierst.

http://en.wikipedia.org/wiki/Sinc_filter

Für B = 2 ist die Grenzfrequenz 1/4 von der Abtastfrequenz.
Für B = 4 ist die Grenzfrequenz 1/8 von der Abtastfrequenz.

Am besten ist es noch, wenn sin(0)/0 = 1 in der Mitte vorkommt (ungerade 
Anzahl an Koeffizienten)!

Zusätzlich erzeugst du dir mit gleicher Länge ein Hamming (gut, einfach) 
ein Hann (gut, einfach, anders) und ein Dreieck-Filter (keine 
Überschwinger im Zeitsignal durch den Filter).

http://de.wikipedia.org/wiki/Fensterfunktion

Um nun die Filterkoeffizienten für einen fertig verwendbaren Filter zu 
generiern, musst du die Sinc-Koeffizienten nur mehr mit den 
Fenster-Koeffizienten einzeln multiplizieren.

Damit erreicht man meiner Meinung nach ausreichende Flexibilität.
Bspw. Filter auf fs/2, fs/4, fs/10, fs/16
kombiniert ohne (Rechteck-Fenster) und mit den Fenstern ergeben 16 
verschiedene Filter!
Und als Draufgabe wäre eine unabhängige Option von Zero-Padding 
(theoretisch richtig) und Wert halten (besser bei kleinen Werten) bei 
Interpolieren ein Hit!

MfG
Alexander

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alex008 schrieb:
> Hallo Hayo!
>
> Am besten wäre es meiner Meinung nach, wennst du dir einmal die
> sin(x)/x-Koeffizienten für 4 Bandbreiten mit gleicher Länge generierst.
Daran arbeite ich gerade...

> http://en.wikipedia.org/wiki/Sinc_filter
>
> Für B = 2 ist die Grenzfrequenz 1/4 von der Abtastfrequenz.
> Für B = 4 ist die Grenzfrequenz 1/8 von der Abtastfrequenz.
>
> Am besten ist es noch, wenn sin(0)/0 = 1 in der Mitte vorkommt (ungerade
> Anzahl an Koeffizienten)!
Ja, ich arbeite mit 11 Koeffizienten.



> Um nun die Filterkoeffizienten für einen fertig verwendbaren Filter zu
> generiern, musst du die Sinc-Koeffizienten nur mehr mit den
> Fenster-Koeffizienten einzeln multiplizieren.
Da gibt es fertige Formeln für bei denen die Fensterfunktion schon drin 
ist. Ist allerdings etwas viel getippe im Rechner...

Ich bin am übverlegen ob ich das mal in eine kleine Funktion kippe die 
die Koeffs berechnet.


> Damit erreicht man meiner Meinung nach ausreichende Flexibilität.
> Bspw. Filter auf fs/2, fs/4, fs/10, fs/16
> kombiniert ohne (Rechteck-Fenster) und mit den Fenstern ergeben 16
> verschiedene Filter!
Das ist wahr.

> Und als Draufgabe wäre eine unabhängige Option von Zero-Padding
> (theoretisch richtig) und Wert halten (besser bei kleinen Werten) bei
> Interpolieren ein Hit!
Ich wollte mal den klassischen Ansatz mit Zero-Padding machen, Mit 
meinen bisherigen Koeffizienten blieben da aber immer Zacken stehen. Ich 
wollte
jetzt mal mit Koeffizienten aus dem Tietze Schenk (ja auch meine alte 
Ausgabe hat schon digitale Filter drin!) einen Test machen.

Danke für die Tips

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alex008 schrieb:
> Hallo Dirk!
>
> Vielen Dank für dein Angebot, mir deinen 4 Kanäler zu borgen.
> Ich werde es aber nicht annehmen, da mich das zu sehr unter Zugzwang
> stellen würde.

Hallo Alex,

was heißt das konkret für das Welec-Projekt? Wirst du die Thematik 
angehen oder ist das Thema ganz und gar für dich gestorben?

alex008 schrieb:
> Die FPGAs der 4 Kanäler sind laut Crazor (lange nichts mehr von ihm
> gehört) über den Adress-Datenbuss verbunden.
> Beim einem schön hirarchischen Aufbau der Software sollte es nicht allzu
> schwer sein beide FPGA Designs zu verbinden.
> Man müsste unter Umständen nicht einmal den FPGA mit dem Softcore
> ändern, wenn man den zweiten FPGA dazu einfügt.
> Auch beim anderen FPGA (für Kanal 3 und 4) müsste man nur die
> Signalerfassungsteil herausnehmen und die Adress-Datenbuss-Schnittstelle
> adaptieren.
> Was ein wenig aufwendiger werden könnte, wäre das Auffinden der ADC Pins
> für Kanal 3/4.

Gedankliche Ansätze hast du ja präsentiert, jetzt wäre es natürlich 
toll, wenn das nicht nur theoretischer Natur bleiben würde.

branadic

Autor: alex008 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Branadic!

In meiner jetzigen beruflichen Situation würde mich die Entwicklung des 
Oszis zu stark belasten. Ich habe schon in der Firma wegen dem zu hohen 
Druck bekannt gegeben, dass ich mit sehr hoher Wahrscheinlichkeit bald 
kündigen werde.

Wenn ich eine Firma finde, bei der ich weniger unter Druck stehe, werde 
ich mich wieder dieser Open Source Entwicklung widmen.

Der nächste Punkt ist, das diese Entwicklung meiner Meinung nach zuerst 
auch für einen Anwender brauchbar sein sollte, bevor man irgendeine 
Erweiterung macht.
Die Hardwarefunktionalität ist jetzt schon so komplex, dass man zuerst 
die Software soweit bringt (großer Nachholbedarf), dass auch der 
Anwender die Vorteile der Neuentwicklung nutzen kann.

Alexander

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,
siehst du eine Chance, wenn die Geschichte mit den Filtern erledigt ist, 
mit der Nios Firmware eine kleine Pause einzulegen und den 
Entwicklungsschwerpunkt Richtung Nios Firmware zu verlagern?

Mfg,
Kurt

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alex008 schrieb:
> In meiner jetzigen beruflichen Situation würde mich die Entwicklung des
> Oszis zu stark belasten. Ich habe schon in der Firma wegen dem zu hohen
> Druck bekannt gegeben, dass ich mit sehr hoher Wahrscheinlichkeit bald
> kündigen werde.

Das ist natürlich bedauerlich zu hören.

> Wenn ich eine Firma finde, bei der ich weniger unter Druck stehe, werde
> ich mich wieder dieser Open Source Entwicklung widmen.

Kann ja nicht so schwer sein einen entsprechenden Arbeitgeber zu finden.

> Der nächste Punkt ist, das diese Entwicklung meiner Meinung nach zuerst
> auch für einen Anwender brauchbar sein sollte, bevor man irgendeine
> Erweiterung macht.
> Die Hardwarefunktionalität ist jetzt schon so komplex, dass man zuerst
> die Software soweit bringt (großer Nachholbedarf), dass auch der
> Anwender die Vorteile der Neuentwicklung nutzen kann.

Grundsätzlich funktioniert das Design ja erst einmal auf allen 
Welec-Geräten, wenn auch in eingeschränkter Form bei den 4-Kanälern, 
sodass nur zwei Kanäle funktionieren. Ob man das auch mit 
funktionierender Firmware als "für den Anwender brauchbar" bezeichnen 
kann lasse ich mal offen.
Womöglich steigt die Motivation den zweiten FPGA auch noch zu 
implementieren, wenn erst einmal eine funktionstüchtige Firmware bereit 
steht?
Was die ADCs angeht, so würde ich schwer vermuten, dass die bei Kanal 3 
und 4 an den gleichen Pins hängen wie auch bei Kanal 1 und 2. Das würde 
zumindest logisch erscheinen.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@alex

> Ich habe schon in der Firma wegen dem zu hohen
> Druck bekannt gegeben, dass ich mit sehr hoher Wahrscheinlichkeit bald
> kündigen werde.

Das kommt mir sehr bekannt vor. Junge engagierte Mitarbeiter, die noch 
nicht so lange dabei sind ordentlich ausquetschen, da diese sich ja noch 
nicht so wehren...

Da hilft nur eins: Erst mal weitermachen und nebenbei nach was Besserem 
suchen. So hab ich das auch gemacht. Danach gings mir in jeder Hinsicht 
besser. Jetzt hab ich sogar Zeit nebenher dieses Open Source Projekt zu 
machen. Das wär vorher nie gegangen.



@Kurt

Du meintest sicherlich LEON und nicht NIOS. Also ich zögere da momentan 
noch da ich die Unterstützung der Kanäle 3 + 4 erstmal noch nicht sehe. 
Das schränkt natürlich die Brauchbarkeit ein. Zumindest für alle 
Besitzer eines 4 Kanalgerätes. Bei dem Aufwand den die Erstellung einer 
vollwertigen Firmware für den LEON erfordert möchte man da natürlich 
auch keine Kompromisse machen.

Also ich wäre da deutlich motivierter wenn nicht der Vorteil des LEON 
Designs mit dem Nachteil der unvollständigen Hardwareunterstützung 
erkauft wäre.

Grundsätzlich müßte ich auch mal drüber nachdenken ob ich die 
Firmwarestruktur der NIOS-Implementierung übernehme um beide Linien 
weiter unterstützen zu können oder ob ich da einen Schnitt mache und nur 
noch das LEON-Design unterstütze.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt mal was Anderes Ich kämpfe immer noch mit der sin(x)/x 
Interpolation. Wie man auf dem Screenshot sieht bleiben trotz 
Interpolation immer noch Reste vom Zero Padding stehen. Cutoff Frequenz 
ist 0.1 normiert auf die Abtastfrequenz -> d.h. 0.1 * 2.5 GHz = 250 MHz.

Bei 0.05 das Gleiche. Trotzdem habe ich irgendwie das Gefühl die Cutoff 
Frequenz ist noch zu hoch. Hat hier jemand gute Vorschläge?

Ich habe mir übrigens jetzt ein Programm geschrieben welches mir den 
Filterkernel berechnet. Das liegt bei der nächsten Version mit dabei, 
falls jemand selbst FIR-Filter berechnen möchte. Hier die 
Bildschirmausgabe:


* Windowed sinc FIR filter
*
*  Type                         : low pass 10th order
*  Filter length (order + 1)    : 11
*  Cutoff frequency (normed)    : 0.100000
*  Window                       : Blackman
*  Gain                         : 2.500000
*  Fixed point width            : 15
*  Integer factor (fixed point) : 32768
*
*
*  floating point               fixed point
*  ---------------------------------------------
*  h[0] = -0.000000             h[0] = 0
*  h[1] = 0.006564              h[1] = 215
*  h[2] = 0.070701              h[2] = 2316
*  h[3] = 0.269282              h[3] = 8823
*  h[4] = 0.554480              h[4] = 18169
*  h[5] = 0.697946              h[5] = 22870
*  h[6] = 0.554480              h[6] = 18169
*  h[7] = 0.269282              h[7] = 8823
*  h[8] = 0.070701              h[8] = 2316
*  h[9] = 0.006564              h[9] = 215
*  h[10] = -0.000000            h[10] = 0


Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Also ich zögere da momentan
> noch da ich die Unterstützung der Kanäle 3 + 4 erstmal noch nicht sehe.
> Das schränkt natürlich die Brauchbarkeit ein. Zumindest für alle
> Besitzer eines 4 Kanalgerätes. Bei dem Aufwand den die Erstellung einer
> vollwertigen Firmware für den LEON erfordert möchte man da natürlich
> auch keine Kompromisse machen.

Das du diese Bedenken äußern würdest haben wir erst gestern Abend im 
SkypeChat vorher gesagt. Dennoch hoffen wir, Kurt und ich, dass du dich 
davon nicht abschrecken lassen wirst und es Alex die notwendige 
Motivation verschafft die Implementierung zu vervollständigen.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@branadic

Ich werd mir das noch mal durch den Kopf gehen lassen.


@all

Wegen der Filter bin ich etwas weiter gekommen. Das hängt wohl mit der 
Cutoff Frequenz in Verbindung mit der Filterlänge zusammen. Bei 
niedrigen Cutoff Frequenzen muß die Filterlänge größer sein, damit die 
Rechteck-Characteristik im Frequenzbereich annähernd erhalten bleibt.

Heißt übersetzt: Ich habe mal einen Filterkernel mit 17 Koeffizienten 
berechent (statt 11) und schon waren bei 10ns/div die Zacken weg.

Für 5 und 2ns muß ich den Filter vermutlich ziemlich lang machen, was 
die Berechnung natürlich verlangsamt - mal sehen.

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> @Kurt
>
> Du meintest sicherlich LEON und nicht NIOS. Also ich zögere da momentan
> noch da ich die Unterstützung der Kanäle 3 + 4 erstmal noch nicht sehe.
> Das schränkt natürlich die Brauchbarkeit ein. Zumindest für alle
> Besitzer eines 4 Kanalgerätes.

Sicher, der Leon ist gemeint. Da die Brauchbarkeit mit dem Nios und den 
dämlichen Filtern gegen Null tendiert, zumindest für sinnvolle 
Messungen, würde ich das fehlen von 3 Kanälen nicht als große 
Beeinträchtigung sehen.

Die Leute, die mit dem Welec nur an irgendwelchen µCs rummessen, sind 
wohl mit dem Nios eher zufrieden. Das Oszi soll aber nicht als Ersatz 
für einen 50€ Logicanalyzer dienen, sondern Messungen bis mindestens 
100Mhz ermöglichen, was zurzeit definitiv nicht gegeben ist und sich 
dank Nios auch mit der Huckepackplatinen nicht ändern wird.


Hayo W. schrieb:
> @branadic
>
> Ich werd mir das noch mal durch den Kopf gehen lassen.

Sehr gut, danke.

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Ton hier gefällt mir im Moment überhaupt nicht - sowohl in Alex' als 
auch in Hayos Richtung werden Forderungen statt Bitten gestellt und es 
ist wohl weder produktiv noch motivierend, hier von "dämlichen Filtern" 
zu sprechen.
Beide haben schon sehr viel geleistet und beide tun das ausschließlich 
in ihrer Freizeit - glaubt ihr da ist dieser Ton angemessen?

Stattdessen sollte man versuchen, eine Lösung für das Henne-Ei Problem 
des Leon zu finden: solange nur zwei Kanäle ansprechbar sind, ist die 
Motivation gering, mit der Firmwareentwicklung zu beginnen und solange 
es keine Firmware gibt, möchte niemand die fehlenden zwei Kanäle 
angehen.

Das Samplen der Kanäle 3 und 4 dürfte kein Problem sein - wenn man bei 
Welec mitgedacht hat dann sind die ADCS am zweiten FPGA identisch 
angebunden wie am ersten. Als Hürde sehe ich hier nur die Kommunikation 
zwischen den FPGAs - wenn man Informationen hätte, wie die beiden im 
NIOS Design verbunden sind dann könnte man das sicher relativ zügig 
implementieren.
Die Programmiermaschine Hayo wird sich bestimmt nicht zweimal bitten 
lassen, die Firmware auf viel leistungsfähigerer Basis umzusetzen, wenn 
erst einmal die Grundlage(inklusive Doku aller Schnittstellen / 
Register) vorhanden ist.

Die Frage ist also: wie bekommt man heraus, wie die FPGAs verbunden 
sind?

Wenn diese Info vorhanden wäre könnte eventuell sogar ich die Zeit 
finden, mich um die Schnittstelle zu kümmern - versprechen kann ich da 
aber leider nichts, da ich beruflich auch recht eingespannt bin.


Michael

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> und es
> ist wohl weder produktiv noch motivierend, hier von "dämlichen Filtern"
> zu sprechen.

Ok, meine Formulierung war etwas undeutlich. Mit "dämlichen Filtern" 
sind natürlich nicht die gemeint, die Hayo programmiert hat, sondern die 
zur Zeit im FPGA implementierten. Die sorgen nämlich dafür, dass die 
Signale bei höheren Frequenzen und Amplituden gnadenlos verstümmelt 
verden.

Michael H. schrieb:
> Beide haben schon sehr viel geleistet und beide tun das ausschließlich
> in ihrer Freizeit

Das bestreitet niemand! Aber auch andere Leute, wie branadic, Walter und 
ich haben viel geleistet, und die wollen langsam Ergebnisse sehen, die 
nun mal in erster Linie vom Leon abhängen.

Um es nochmal deutlich zu sagen, es ist wirklich großartig, was Hayo und 
die anderen Programmierer schon geschafft haben, und in welchem Tempo. 
Aber von den vielen Entwicklern (früher bestimmt 15 Leute) ist nur noch 
ein Drittel übrig geblieben: Hayo, Jörg, Walter, branadic Alexander 
vieleicht und ich.

Damit das Projekt nicht vollständig entschläft, ist es sicher erlaubt 
fordernde als auch motivierende Worte zu sprechen.

Mfg,
Kurt

PS:
Kurt Bohnen schrieb:
> würde ich das fehlen von 3 Kanälen nicht als große
> Beeinträchtigung sehen.

Natürlich fehlen nur 2 Kanäle ;-)

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> Der Ton hier gefällt mir im Moment überhaupt nicht - sowohl in Alex' als
> auch in Hayos Richtung werden Forderungen statt Bitten gestellt und es
> ist wohl weder produktiv noch motivierend, hier von "dämlichen Filtern"
> zu sprechen.

Mir war nicht klar das Michael ein Moralapostel war/ist. Aber im ernst, 
mir ist primär egal was dir gefällt oder nicht, aber niemand hat 
gefordert, sondern lediglich nachgefragt und versucht zu motivieren.
Das wir mit Alex's Haltung beim vorerst aktuellen Single-FPGA-Design zu 
bleiben und Hayo's Haltungen keinen Plattformwechsel durchzuführen 
solange nicht beide FPGAs implementiert sind war absehbar.
Das ist ein Problem und muss irgendwo auch zur Sprache gebracht werden, 
wenn nicht hier, dann wo?

Michael H. schrieb:
> Beide haben schon sehr viel geleistet und beide tun das ausschließlich
> in ihrer Freizeit - glaubt ihr da ist dieser Ton angemessen?

Na ein Glück haben alle anderen Entwickler inkl. mir beruflich 
mitgewirkt und nicht ihre Freizeit geopfert und mit "glaubt ihr" fühle 
ich mich durchaus mit angesprochen.
Mein Nachfragen um die Programmierer zu motivieren zieht sich durch alle 
Threads wie ein roter Faden, doch so langsam bin ich der A***leckerei 
schlichtweg überdrüssig, denn genauso kommt es mir langsam vor! Man ist 
ständig auf die Laune Einzelner angewiesen.

Ich kann niemandem vorschreiben womit er sich beschäftigen sollen, 
allerdings bin ich und das habe ich mehrfach zum Ausdruck gebracht, der 
Meinung, dass viele der in letzter Zeit umgesetzten Spielereien die 
Funktion nicht wirklich verbessert und damit keinen wirklichen 
Fortschritt gebracht haben. Wir erinnern uns an die verschiedenen 
Farbpaletten, den Logikpegeln und ähnliche Dinge.
Der wirklich größte Fortschritt dürfte mit Abstand die Implementierung 
der Huckepackplatine gewesen sein. Und hier möchte ich daran erinnern, 
dass das weit über ein Jahr mit viel Nachfragerei gebraucht hat. Wenn 
das so weitergehen soll, dann wird auch in den nächsten Jahren kein 
Paradigmenwechseln stattfinden und der Leon nie den Weg ins Welec 
schaffen, davon bin ich mehr als überzeugt.

Darüber hinaus sind viele der anfänglichen Entwickler mittlerweile 
abgesprungen, das Projekt artet also immer mehr zu einer One Man-Show 
aus und die Arbeit der übrigen Entwickler geht in der Beweihräucherung 
einer einzelnen Person unter, das missfällt mir.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey, nicht streiten!

Ich habe durchaus Verständnis, dass jeder für seinen Standpunkt und 
seine favorisierten Projekte eintritt. Ich fühle mich jetzt auch nicht 
angegriffen, wenn kritische Anmerkungen gemacht werden.

Ist ja klar, das jeder seine Anliegen etwas pushen möchte und daher hier 
zur Sprache bringt. Kein Problem. Dazu ist das Forum da.

Ich möchte zum Stand der Dinge nochmal darauf hinweisen, dass das 
primäre Ziel meiner Entwicklungen bisher die Verbesserung der originalen 
Plattform war, so dass in überschaubarer Zeit ein benutzbares Oszi dabei 
herauskommt. Das ist, finde ich, auch schon recht weit gediehen.

Kurts etwas pessimistische Einschätzung teile ich da nicht. Gut, das 
Teil ist nicht unbedingt die erste Wahl für ein HF-Labor, aber für den 
Hausgebrauch reicht das locker aus. Davor hatte ich nur ein 50MHz 
Analog-Oszi von Philips - Da kann unser DSO mehr als locker mithalten.

Und auch für das Meiste was ich damals im Studium in den Laboren gemacht 
habe hätte das WELEC ausgereicht. Da hätte ich mich als Studi gefreut 
wie ein Schneekönig wenn ich sowas gehabt hätte (und das für den 
Preis!).

Das jetzt die Möglichkeit besteht auf eine leistungsfähigere "Hardware" 
umzuschwenken übt natürlich einen gewissen Reiz aus. Aber es sollte 
Allen klar sein dass es einige Zeit dauern wird bis da was Brauchbares 
mit echtem Nutzwert herauskommt, da wie schon mehrfach erwähnt die 
Resourcen bei allen hier auf die Freizeit beschränkt sind.

Ich denke auch die absoluten Befürworter einer Portierung auf das LEON 
Design werden Verständnis dafür haben, dass auch weiterhin erstmal die 
Verbesserung der aktuellen Firmware Priorität bei mir hat.

Das soll nicht heißen, dass die Portierung nicht stattfindet, sondern 
dass das Ganze auch mit den richtigen Vorüberlegungen angegangen werden 
muß. Weiterhin macht das Ganze nur Sinn, wenn auch weiterhin 
Unterstützung seitens der FPGA-Entwickler kommt. Alex hatte ja 
angedeutet, dass er evtl. wieder zur Verfügung steht wenn sich seine 
berufliche Situation entspannt.

Also gehen wir das Ganze mal mit etwas Gelassenheit an und sehen mal 
Schritt für Schritt was sich machen läßt.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, zur One Man Show wollte ich noch was sagen.

Ich beanspruche die Lorbeeren des bisher Geschafften keinesfalls für 
mich allein. Da sind zahlreiche Beiträge im Laufe der Zeit eingeflossen, 
ohne die wir nicht da wären wo wir jetzt sind. Im Changelog habe ich die 
Mitstreiter vermerkt (hoffe ich habe niemanden vergessen). Auch im 
Coding habe ich versucht die Stellen kenntlich zu machen.

Es ist nurt einfach so, dass ich offensichtlich am konstantesten die 
Zeit für das Projekt aufbringen kann (und will).

Jeder hat die Möglichkeit selbst was beizutragen oder auch nur sich 
selbst seine eigene angepasste Firmwareversion zu basteln. Alle Sourcen 
sind frei verfügbar und ich gebe jederzeit gerne Hilfestellung.


Gruß Hayo

Autor: Roberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Trage zwar nichts zur Entwicklung bei, als ab und zu mal die neue 
Version zu probieren und fleißig hier mitzulesen.. , aber ich möchte 
auch mal meine Meinung kundtun.

Ich sehe die Zukunft auch im Leon Design, aber wenn es dann bei einem 4 
Kanal DSO nur 2 Kanäle nutzbar sind, würde ich da nicht mitumsteigen.

Ich weiß, branadic, da kommt schon wieder einer und machte deine 
Anststrengungen und A...l zunichte.

>Und auch für das Meiste was ich damals im Studium in den Laboren gemacht
>habe hätte das WELEC ausgereicht. Da hätte ich mich als Studi gefreut
>wie ein Schneekönig wenn ich sowas gehabt hätte (und das für den
>Preis!).

Sehe ich auch so!

Einige hier wollen halt ein HF DSO, aber viele hier sehen es wie Hayo, 
dass sie schon froh sind, dass sie ein günstiges 4 Kanal DSO haben das 
besser ist als das alte 50MHz Analog Osci. (bei mir 20MHz :-) )

>Jeder hat die Möglichkeit selbst was beizutragen oder auch nur sich
>selbst seine eigene angepasste Firmwareversion zu basteln. Alle Sourcen
>sind frei verfügbar und ich gebe jederzeit gerne Hilfestellung.

Sehe ich auch so!
(Obwohl ich am wenigsten dazu beitrage ;-) )

l.G. Roberto

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roberto schrieb:
> Ich sehe die Zukunft auch im Leon Design, aber wenn es dann bei einem 4
> Kanal DSO nur 2 Kanäle nutzbar sind, würde ich da nicht mitumsteigen.

Das letzte Wort dazu hat Alex doch noch gar nicht gesprochen, aber 
momentan beißt sich die Katze selbst in der Schwanz: Der eine will nicht 
damit anfangen Firmware zu bauen wenn es nur zwei Kanäle sind, der 
andere will das Design nicht auf 4 Kanäle weiterentwickeln, wenn es 
keinen Fortschritt bei der Firmware gibt. Entweder überwindet sich einer 
von beiden oder aber die Sache ist gestorben.

Hayo W. schrieb:
> Das jetzt die Möglichkeit besteht auf eine leistungsfähigere "Hardware"
> umzuschwenken übt natürlich einen gewissen Reiz aus. Aber es sollte
> Allen klar sein dass es einige Zeit dauern wird bis da was Brauchbares
> mit echtem Nutzwert herauskommt, da wie schon mehrfach erwähnt die
> Resourcen bei allen hier auf die Freizeit beschränkt sind.

Jedem dürfte klar sein, dass es einige Zeit brauchen wird, bis der Leon 
den aktuellen Stand vom NIOS-Design hat. Jörg hatte einmal 
vorgeschlagen, dass man vielleicht mit einen HAL arbeiten könnte, dann 
könnte die Entwicklung bilateral voranschreiten und alle wären 
glücklich.

Roberto schrieb:
> Einige hier wollen halt ein HF DSO, aber viele hier sehen es wie Hayo,
> dass sie schon froh sind, dass sie ein günstiges 4 Kanal DSO haben das
> besser ist als das alte 50MHz Analog Osci. (bei mir 20MHz :-) )

Es gibt kein HF DSO und 200MHz -3dB-Gerenze sind nun auch kein 
besonderes Alleinstellungsmerkmal.

Die Huckepackplatine vermag ihr vollständiges Potential, messen bis 
200MHz, nun mal erst richtig zu zeigen, wenn sicher gestellt ist das 
keine Filter die digitalisierten Signale wieder zunichte macht, aber das 
ist mit dem NIOS nun mal nicht der Fall. Das sollte langsam auch bei 
allen angekommen sein. Da hilft auch ein Umschalten des ominösen 
Registers herzlich wenig, denn ich will mit einem Gerät schließlich 
messen und nicht nur Zufallsbilder erzeugen, die frei interpretierbar 
sind. Das Filter, zumindest wird vermutet das es eines ist, beeinflusst 
in hohem Maße den Frequenzgang, sodass aus einer Eingangsstufe mit 
flachem Frequenzgang etwas völlig vermurkstes wird. Und bisher ist nicht 
klar, wie sich das Filter deaktivieren lässt. Schwer nachzuvollziehen, 
dass ihr euch damit zufrieden geben wollt, denn auch bei einem 20MHz 
Rechteck greift das Filter schon in vollem Maße und verformt die 
Flanken.

Die Motivation die Huckepackplatine zu entwickeln war ja gerade das 
Welec zu verbessern. Die erste logische Konsequenz dazu war die 
Unterstützung der Huckepackplatine durch die Firmware. Es hat ewig 
gedauert, weit über ein Jahr, aber dank Jörg ist diese Unterstützung nun 
gegeben. Die nächste logische Konsequenz aus dem Welec ein Messgerät zu 
machen ist nun einmal der Plattformwechsel hin zum Leon-Design. Nicht 
zuletzt deswegen, weil es OpenSource ist und wir den Entwickler an der 
Strippe haben.

Hayo W. schrieb:
> Es ist nurt einfach so, dass ich offensichtlich am konstantesten die
> Zeit für das Projekt aufbringen kann (und will).

Ich will nicht sagen das du die anderen vergrauelt hast (ich erinnere an 
die OS-Version), aber die Zusammenarbeit mit dir schien ja nicht ganz 
einfach zu sein. Mich wundert es dann nicht das die Leute dann 
irgendwann die Nase voll hatten.

Hayo W. schrieb:
> Jeder hat die Möglichkeit selbst was beizutragen oder auch nur sich
> selbst seine eigene angepasste Firmwareversion zu basteln. Alle Sourcen
> sind frei verfügbar und ich gebe jederzeit gerne Hilfestellung.

Das sagt sich immer wunderbar einfach "Bau dir deine eigene Version..." 
Programmierung ist nun mal nicht jedermanns Metier, so wie du vielleicht 
auch nur bedingt Ahnung von analoger Schaltungstechnik haben wirst.

Das ist innerhalb des Projektes von Anfang an ein Problem gewesen, 
Hardwareentwickler und Softwarenentwickler haben einfach nicht Hand in 
Hand zusammengearbeitet, stattdessen musste gebettelt werden, dass 
wichtige Funktionen für die Hardwareentwicklung in Software umgesetzt 
werden. Das funktioniert natürlich eine gewisse Zeit lang, aber dann 
verlieren die Leute die Lust am Projekt weiterhin mitzuwirken. Wen 
wundert es, dass der ursprüngliche Entwicklerkern schon lange nicht mehr 
existent ist?
Vielleicht lag das aber auch daran, dass dem Projekt eine RoadMap 
gefehlt hat, an der klar die Aufgaben und Ziele erkennbar gewesen wären.

Ich mach dir das nicht mal zum Vorwurf Hayo, aber es muss auch mal klar 
gesagt werden, alles unterliegt deiner Laune. Und momentan liegt diese 
bei Spielereien, die die Funktionalität des Gerätes im Ursprung nicht 
verbessern. Hätte Jörg sich nicht daran gemacht die Arbeit der 
Hardwareentwickler durch Integration der Ansteuerung der 
Huckepackplatine zu unterstützen würden wir heute noch darauf warten. Du 
hast deine beiden Huckepackplatinen ja nun auch weit über ein Jahr, ich 
nehme an die liegen immer noch schön verpackt? Soviel zum Thema Hand in 
Hand arbeiten.

Ich wundere mich nach wie vor, dass niemand der sich mit 
Huckepackplatinen eingedeckt hat das hier je moniert hat. Ob diese Leute 
mittlerweile auch resignieren? Auf jeden Fall ist seit einiger Zeit 
wieder erkennbar, dass sich der Kreis der Akteure reduziert hat.

Hayo W. schrieb:
> Ich möchte zum Stand der Dinge nochmal darauf hinweisen, dass das
> primäre Ziel meiner Entwicklungen bisher die Verbesserung der originalen
> Plattform war, so dass in überschaubarer Zeit ein benutzbares Oszi dabei
> herauskommt. Das ist, finde ich, auch schon recht weit gediehen.

> Ich denke auch die absoluten Befürworter einer Portierung auf das LEON
> Design werden Verständnis dafür haben, dass auch weiterhin erstmal die
> Verbesserung der aktuellen Firmware Priorität bei mir hat.

Offenbar haben wir da ganz unterschiedliche Vorstellungen von dem 
Begriffen "benutzbar", "Oszi" und "Verbesserung". Unbestritten ist dass 
das Welec schneller geworden und die ein oder andere Funktion nun 
gegeben ist, aber wenn der Signalerfassungsteil schon fehlerhaft ist 
nützt der ganze Aufwand im Anschluss herzlich wenig, das Signal ist dann 
einfach unwiederbringlich hin. Irgendwie will das nur niemand einsehen. 
Warum dann noch darin Energie verschwenden? Warum so resistent? Ich kann 
das beim besten Willen nicht nachvollziehen und die Logik dahinter 
entzieht sich mir!

Ich sehe in den jüngsten Aktivitäten nur Spielereien. Ziel sollte nach 
meiner Auffassung die Verbesserung der Basis sein und diese lässt sich 
mit dem NIOS nun einmal nicht bewerkstelligen. Ferrari-rot macht aus 
einem Käfer nun mal noch kein schnelles Auto!
Da ich aber merke das man hier als Einzelperson gegen Windmühlen oder 
eingesessene Altkonservative ankämpft und ich es offen gestanden auch 
leid bin mich hier immer und immer zu wiederholen geb ich jetzt Ruhe. 
Macht doch was ihr wollt. Begnügt euch weiterhin mit "Blingbling" statt 
mal da anzugreifen wo wirkliches Verbesserungspotential steckt, um aus 
dem Welec ein DSO zu machen.

branadic

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja branadic,

es ist aber kein böser Wille, dass dies der aktuelle Stand ist.
Es liegt auch am riesigen Aufwand, den jeder scheut. Wenn ich mir
auf SFN allein die Liste an Software anschaue, die nur zum
Aufspielen des LEONs nötig ist und dann nicht erkennen kann, was
jetzt auf welcher Plattform läuft. Und damit hat man noch nicht
einmal eine laufende Toolchain zum Programmieren.

Ich mache mal einen Vorschlag: Hayo erstellt ein C++-Framework. Ob
vom NIOS übernommen oder neu, muss er selbst entscheiden. Dann kann
mit laufender Toolchain im TopDown-Verfahren dieser Rahmen mit der
NIOS-Menüstruktur ohne echte Funktion gefüllt werden. Das kann auch
branadic, dazu muss man kein Meisterprogrammierer sein. Anschließend
kann dann die Funktion vom NIOS portiert werden, Schritt für
Schritt.

Grüße, Guido

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es will doch niemand, dass jetzt alle Nutzer sofort auf den Leon 
umsteigen. Dessen Firmware hat doch erst Alpha Staus. Bis da eine Beta 
draus wird, die man dem Nutzer zum testen anbieten kann, dürfte es noch 
viel Arbeit sein.
Und bis dahin läuft der Leon nur im RAM, sodass man jederzeit wieder mit 
dem Nios seine "Messungen" machen kann.

So riesig kompliziert, die Leon Toolchain zu installieren ist es auch 
nicht. Das habe sogar ich geschafft. Es könnte allerdings sein, dass die 
Anleitung im Wiki noch etwas ergänzt werden müsste.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
branadic schrieb:

> Der eine will nicht damit anfangen Firmware zu bauen wenn es nur zwei Kanäle 
sind...

Das habe ich nicht gesagt. Ich sagte ich zögere etwas weil da erstens 
(wie Guido ganz richtig schrieb) die Hürden für den Einstieg genommen 
werden müssen. Das betrifft in der Tat vor allem Toolchain, Anleitungen 
und technische Doku.
Zweitens ist schon erstmal recht viel zeitlicher Aufwand damit verbunden 
bis man erste Ergebnisse erwarten kann, während in der NIOS-Umgebung 
dank vorhandener Basis schneller Resultate erzielt werden können. Das 
die technische Basis beim LEON deutlich besser ist, ist völlig klar.

 Jörg hatte einmal
> vorgeschlagen, dass man vielleicht mit einen HAL arbeiten könnte, dann
> könnte die Entwicklung bilateral voranschreiten und alle wären
> glücklich.
Das würde aber den Performancevorteil unter Umständen wieder auffressen, 
was ich eigentlich schade fände.

> Die Huckepackplatine vermag ihr vollständiges Potential, messen bis
> 200MHz, nun mal erst richtig zu zeigen, wenn sicher gestellt ist das
> keine Filter die digitalisierten Signale wieder zunichte macht,
....
> Die nächste logische Konsequenz aus dem Welec ein Messgerät zu
> machen ist nun einmal der Plattformwechsel hin zum Leon-Design. Nicht
> zuletzt deswegen, weil es OpenSource ist und wir den Entwickler an der
> Strippe haben.

Keine Frage, das ist ein echtes Argument.

> Ich will nicht sagen das du die anderen vergrauelt hast (ich erinnere an
> die OS-Version), aber die Zusammenarbeit mit dir schien ja nicht ganz
> einfach zu sein. Mich wundert es dann nicht das die Leute dann
> irgendwann die Nase voll hatten.

Hmm, da fühle ich mich aber doch etwas mißverstanden muß ich sagen. Ich 
habe damals mehrfach erklärt warum ich gerne an einer eigenen Version 
der Firmware festhalten wollte. Ich habe alle Entwicklungen auch der 
OS-Version zur Verfügung gestellt und umgekehrt auch einige Sachen aus 
der OS-Version übernommen.

> Das sagt sich immer wunderbar einfach "Bau dir deine eigene Version..."
> Programmierung ist nun mal nicht jedermanns Metier,

Das ist schon klar, aber wenn man nicht selber programmierren kann ist 
man halt auf Andere angewiesen. Ich wollte nur auf die grundsätzlichen 
Möglichkeiten hinweisen, die sicherlich auch der Eine oder Andere hier 
nutzt. Ich versuche weiterhin auch die Vorschläge hier aus dem Forum 
einzuarbeiten und dabei auf Vorlieben der Mehrheit einzugehen.

> Wen wundert es, dass der ursprüngliche Entwicklerkern schon lange
> nicht mehr existent ist?

Das ist aber nichts Ungewöhnliches. Die Wenigsten widmen sich so 
langfristig einem Projekt, da irgendwann persönliche Umstände den Fokus 
auf andere Dinge lenken.

> Vielleicht lag das aber auch daran, dass dem Projekt eine RoadMap
> gefehlt hat, an der klar die Aufgaben und Ziele erkennbar gewesen wären.

mag sein.

> Ich mach dir das nicht mal zum Vorwurf Hayo, aber es muss auch mal klar
> gesagt werden, alles unterliegt deiner Laune. Und momentan liegt diese
> bei Spielereien, die die Funktionalität des Gerätes im Ursprung nicht
> verbessern.

Unbedingtes Ja. Das ganze ist für mich eine Spielwiese die ich in meiner 
Freizeit nutze um mich an Themen auszutoben mit denen ich aufgrund 
meiner beruflichen Tätigkeit leider nichts mehr zu tun habe, die ich 
aber mächtig interessant finde.

Das ich da zum Teil die Prioritäten bei der BF-Version vorgebe ist doch 
klar. Das würde jeder Andere auch machen, und das denke ich kann man mir 
doch nicht zum Vorwurf machen. Das war ja der Grund, warum ich neben der 
OS-Version meine eigene beibehalten hatte. Ich wollte für mich selbst 
die Prioritäten setzen können.


> Hätte Jörg sich nicht daran gemacht die Arbeit der
> Hardwareentwickler durch Integration der Ansteuerung der
> Huckepackplatine zu unterstützen würden wir heute noch darauf warten.

Da hast Du vermutlich Recht. Das lag aber leider auch daran, dass die 
Harwareentwickler die Sache nicht zuende gedacht hatten und mir die 
entsprechenden Informationen zur Ansteuerung fehlten. Wenn Jörg das 
nicht zuende gedacht und entwickelt hätte wäre es auch etwas schwierig 
geworden.

> Du hast deine beiden Huckepackplatinen ja nun auch weit über ein Jahr,
> ich nehme an die liegen immer noch schön verpackt?

Ist richtig, erst wollte ich mal Jörgs Fortschritte abwarten. Ich glaube 
es funktioniert zwar soweit schon, aber eine endgültige Rückmeldung über 
den Stand der Dinge mit Probemessungen und Screenshots fehlt noch. Ich 
vermute mal, dass Jörg beruflich auch recht eingespannt ist. Das wäre 
doch was für Dich, die Firmware unterstützt die Platine ja schon. Außer 
Jörg (und Dir?) hat aber wohl noch keiner Selbige eingebaut oder?

> Ich wundere mich nach wie vor, dass niemand der sich mit
> Huckepackplatinen eingedeckt hat das hier je moniert hat. Ob diese Leute
> mittlerweile auch resignieren?

Das glaube ich eher nicht. Ich denke es wird einfach nur in Ruhe 
abgewartet wie sich das entwickelt.

> ...aber wenn der Signalerfassungsteil schon fehlerhaft ist
> nützt der ganze Aufwand im Anschluss herzlich wenig, das Signal ist dann
> einfach unwiederbringlich hin. Irgendwie will das nur niemand einsehen.

Ganz so schlimm ist es auch wieder nicht, Die Signale werden in einem 
gewissen Frequenzband schon ganz anständig dargestellt. Ich habe da 
schon mehrfach den Vergleich mit dem Tektronix 2465A gemacht und fand 
das nicht so schlecht.

> Da ich aber merke das man hier als Einzelperson gegen Windmühlen oder
> eingesessene Altkonservative ankämpft...

Oha, wer soll sich denn den Schuh anziehen ein Alkonservativer zu sein? 
Ich bin ja selbst auch nicht mehr taufrisch, aber das wäre wohl etwas zu 
viel des Guten.

> und ich es offen gestanden auch
> leid bin mich hier immer und immer zu wiederholen geb ich jetzt Ruhe.

Das ist aber nicht der Sinn der Diskussionen hier. Es soll ja keiner 
Mundtot gemacht werden. Also laß Dich nicht davon abhalten Deine Meinung 
zu äußern.

> Ich sehe in den jüngsten Aktivitäten nur Spielereien.
Ja aber auch die erfreuen das Herz...

> Ziel sollte nach
> meiner Auffassung die Verbesserung der Basis sein
Ja da hast Du natürlich auch recht. Ich bin ja auch nicht abgeneigt, 
sondern stürze mich jetzt nur nicht gleich mit lautem Hurra in die 
Sache.

Ich habe aber die Absicht mein 2-Kanal Oszi als LEON Plattform 
umzufunktionieren und mal zu prüfen wie ich da weiter vorgehen kann.

Hinweise und Tips zur LEON Entwicklungs-Toolchain sind willkommen.

Gruß Hayo

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollten wir für das Leon-Design nicht ev. einen neuen Thread
öffnen? Es wird schon über lange Zeit parallel zum bisherigen
Stand verlaufen.

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Unbedingtes Ja. Das ganze ist für mich eine Spielwiese die ich in meiner
> Freizeit nutze um mich an Themen auszutoben mit denen ich aufgrund
> meiner beruflichen Tätigkeit leider nichts mehr zu tun habe, die ich
> aber mächtig interessant finde.

Die selben Themen könntest du auch auf dem Leon bearbeiten...
Auch müsste während der Arbeit am Leon die Nios Entwicklung nicht 
vollständig ruhen, obwohl meiner Meinugn nach deine Firmware sehr nahe 
an der Perfektion ist!

Hast du konkrete Probleme/Fragen zur Installation der Toolchain?

Fühlt sich jemand der stillen Mitleser die noch nichts zum Projekt 
beigetragen haben dazu berufen, die Anleitung zu erweitern?

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Da hast Du vermutlich Recht. Das lag aber leider auch daran, dass die
> Harwareentwickler die Sache nicht zuende gedacht hatten und mir die
> entsprechenden Informationen zur Ansteuerung fehlten. Wenn Jörg das
> nicht zuende gedacht und entwickelt hätte wäre es auch etwas schwierig
> geworden.

Das möchte ich doch mal richtig stellen, wie das Ganze umgesetzt und 
angebunden werden sollte wurde vorgegeben. Das sich das als unpraktisch 
erwiesen hat und Jörg eine schönere Lösung gefunden hat ist eine andere 
Geschichte.

Hayo W. schrieb:
> Ist richtig, erst wollte ich mal Jörgs Fortschritte abwarten. Ich glaube
> es funktioniert zwar soweit schon, aber eine endgültige Rückmeldung über
> den Stand der Dinge mit Probemessungen und Screenshots fehlt noch. Ich
> vermute mal, dass Jörg beruflich auch recht eingespannt ist. Das wäre
> doch was für Dich, die Firmware unterstützt die Platine ja schon. Außer
> Jörg (und Dir?) hat aber wohl noch keiner Selbige eingebaut oder?

Die Rückmeldung kam, auch wenn der Allgemeinheit nur bedingt bunte 
Bildchen gezeigt worden sind. Von Walter sind auch Probemessungen 
veröffentlicht, die die Schwächen durch das öminöse Register eindeutig 
verdeutlicht haben, zugleich aber den wirklich flachen Amplitudengang 
der neuen Eingangsstufe dokumentieren. Was erwartet man noch?
Die Implementierung von Jörg funktioniert, auch das sollte mittlerweie 
bekannt sein.

Hayo W. schrieb:
> Ganz so schlimm ist es auch wieder nicht, Die Signale werden in einem
> gewissen Frequenzband schon ganz anständig dargestellt. Ich habe da
> schon mehrfach den Vergleich mit dem Tektronix 2465A gemacht und fand
> das nicht so schlecht.

Ich weiß nicht ob dein 2465A defekt ist oder du dir die Ergebnisse schön 
reden möchtest, mein 2465A und das menschliche Auge sagen etwas anderes. 
Bei 1GS und 10 Stützstellen bei einem 100MHz Sinussignal würde ich doch 
etwas anderes erwarten als das, was auf dem Welec zu sehen ist.

branadic

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
branadic schrieb:
> Ich weiß nicht ob dein 2465A defekt ist oder du dir die Ergebnisse schön
> reden möchtest, mein 2465A und das menschliche Auge sagen etwas anderes.
> Bei 1GS und 10 Stützstellen bei einem 100MHz Sinussignal würde ich doch
> etwas anderes erwarten als das, was auf dem Welec zu sehen ist.

Mach das mal konkret und verweise nicht auf riesige pdf-Dateien, die
sich naturgemäß kein Schwein anschaut. Mein W2012A ist bis 100 MHz
spezifiziert, üblicherweise -3 dB, und kann viel mehr in diesem
Rahmen. Hast du vielleicht etwas falsch verstanden?

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach Guido,

nur weil du noch mit 14k-Modem unterwegs bist und dir vielleicht zu fein 
bist dir die Arbeit anderer anzuschauen heißt das nicht, dass die 
Messungen nicht dokumentiert worden sind. Um es dir mundgerecht zu 
kredenzen hier noch mal der direkte Link:

http://welecw2000a.sourceforge.net/docs/Hardware/P...

und nach wie vor findet man alles zum Thema Hardwareverbesserung hier:

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

branadic

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nix Modem, DSL, aber nach 20 Sekunden habe ich den Downloadvorgang
mal wieder abgebrochen. Ich erwarte mir auch nichts neues davon.
Bilder mit der Huckepackplatine auf dem Welec, die einen Vorteil
belegen, gibt es wohl noch nicht. Auch Jörg wollte keine publizieren.
Sorry, deinen Messprotkollen traue ich soviel wie denen von jedem
anderen. Ist wahrscheinlich eine Berufskrankheit, hat sich bisher
aber immer bewährt.

Gruß, Guido

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay Guido, ich lasse es jetzt einfach dabei, bevor ich dir gegenüber 
ausfallend werde. Denk was du willst, ich lege keinen Wert auf deine 
Meinung!

branadic

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido schrieb:
> Bilder mit der Huckepackplatine auf dem Welec, die einen Vorteil
> belegen, gibt es wohl noch nicht.

Doch. Sind in den PDFs. Aber wenn du nichtmal die Zeit hast, den 
Download abzuwarten, wird es dir auch zu viel Arbeit sein die Platinen 
ins Oszi einzubauen, oder?

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja Kurt, bestellt sind sie ja. Aber vllt. werde ich sie vor
dem Einbau noch durchmesen müssen?

Gruß, Guido

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido schrieb:
> Aber vllt. werde ich sie vor
> dem Einbau noch durchmesen müssen?

Ganz ehrlich Guido, das ist mehr als daneben und auch dir sollte langsam 
klar werden, dass du dich gerade lächerlich machst!

branadic

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, ok. Du bist DER Guido, ich dachte schon wir hätten 2. ;-)

Extern durchmessen dürfte Aufwändig werden. Besser mit Lupe/Mikroskop 
kontrollieren und alle Ein- und Ausgänge gegen Masse auf Kurzschluss 
prüfen.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
branadic schrieb:
> Ganz ehrlich Guido, das ist mehr als daneben und auch dir sollte langsam
> klar werden, dass du dich gerade lächerlich machst!

Immer langsam branadic. Auch andere Forumsteilnehmer sind
berufstätig und haben in diesem Zusammenhang Messmöglichkeiten, die
über den Hobbybereich hinausgehen. Aber auch hier zu Hause bin ich
nicht so karg ausgestattet, bis 500 MHz reicht es.

Jo Kurt, ich bins, im anderen Forum ja auch.

Grüße, Guido

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido schrieb:
> Immer langsam branadic. Auch andere Forumsteilnehmer sind
> berufstätig und haben in diesem Zusammenhang Messmöglichkeiten, die
> über den Hobbybereich hinausgehen. Aber auch hier zu Hause bin ich
> nicht so karg ausgestattet, bis 500 MHz reicht es.

Es hat auch niemand bestritten das auch du Messmöglichkeiten hast, aber 
jetzt daher zu kommen und zu meinen, nur wenn du die Messungen 
durchgeführt hast sind sie auch glaubwürdig ist armseelig und lächerlich 
hoch drei. Mit solchen Aussagen sorgst du selbst dafür, dass man die 
Achtung und den Respekt vor dir verliert, weil du ihn selbst für andere 
nicht aufbringst. Im Gegenteil, du strafst die Arbeit anderer damit ab. 
Schäm dich Guido und das meine ich ganz genau so wie ich es schreibe!

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi branadic,

ich meinte auch nicht eine Rückmeldung über die grundsätzliche Funktion 
der Platine, die ich nicht in Zweifel ziehe, sondern vielleicht einige 
Screenshots mit Testsignalen die die korrekte Ansteuerung zeigen.

Weiterhin bietet ja die Platine die Möglichkeit den Meßbereich nach 
unten bis 1mV/div aufzubohren. Das habe ich aber bislang in der Firmware 
noch nicht berücksichtigt, weil ich nicht weiß ob das sinnvolle 
Ergebnisse liefert, oder das Ganze dann im Rauschen untergeht.

Auch die Skalierungsfaktoren sind wohl noch nicht auf dem letzten Stand.

Also salopp ausgedrückt ein paar Actionbilder der eingebauten Platine 
wären ganz nett. Jetzt wo die kalte Jahreszeit anfängt habe ich wohl 
auch eher die Zeit mal die Platine einzubauen die Du mir 
freundlicherweise schon bestückt hattest. Dann kann ich da vielleicht 
auch was zu beitragen.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> ich meinte auch nicht eine Rückmeldung über die grundsätzliche Funktion
> der Platine, die ich nicht in Zweifel ziehe, sondern vielleicht einige
> Screenshots mit Testsignalen die die korrekte Ansteuerung zeigen.

Soweit ich das weiß hat Jörg keinen Signalgenerator oder ähnliches. 
Zudem haben seine Messungen bisher am offenen Gerät stattgefunden und 
sind daher nicht 100% repräsentativ.

Hayo W. schrieb:
> Auch die Skalierungsfaktoren sind wohl noch nicht auf dem letzten Stand.

Theoretisch sollten sie das sein. Ich hatte ja das folgende ExcelSheet 
zur Verfüfung gestellt, mit dem sich die Skalierungsfaktoren für alle 
Einstellungen ermitteln lassen und anhand dessen man auch die 
notwendigen Einstellungen am PGA/VGA nachvollziehen kann:

http://welecw2000a.sourceforge.net/docs/Hardware/W...

Hayo W. schrieb:
> Also salopp ausgedrückt ein paar Actionbilder der eingebauten Platine
> wären ganz nett

Ich muss gestehen, dass ich von solchen bunten Bildern nicht sonderlich 
viel halte, da deren Aussagekraft zweifelhaft ist. Aber offenbar lässt 
man sich hier nur damit überzeuge, Diagramme und Grafiken scheinen eher 
zweitrangig zu sein.

Zudem hat Walter ja Bilder in seinen letzten Dokumentationen, auf die 
ich schon mehrfach verwiesen habe. Dazu muss man aber auch bereit sein 
sich die Zeit zu nehmen einen Blick auf die Dokumentation zu werfen. Die 
Prosa darin hält sich stark in Grenzen und nur die notwendigen Hinweise 
sind niedergeschrieben worden. Ansonsten sind Bilder und Grafiken zu 
sehen.

Wenn ich die Zeit finde werde ich bunte Bilder machen.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurt Bohnen schrieb:
> Hayo W. schrieb:
>> Unbedingtes Ja. Das ganze ist für mich eine Spielwiese die ich in meiner
>> Freizeit nutze um mich an Themen auszutoben mit denen ich aufgrund
>> meiner beruflichen Tätigkeit leider nichts mehr zu tun habe, die ich
>> aber mächtig interessant finde.
>
> Die selben Themen könntest du auch auf dem Leon bearbeiten...
Ja schon richtig, ich wollte auch nur grundsätzlich darauf hinweisen, 
dass das Ganze Projekt eigentlich nur Spielerei ist. Allerdings eine 
sehr interessante mit viel Lerneffekt.


> Auch müsste während der Arbeit am Leon die Nios Entwicklung nicht
> vollständig ruhen,
Das Problem ist da die verfügbare Zeit.

> Hast du konkrete Probleme/Fragen zur Installation der Toolchain?
Noch nicht. Ich muß mich erstmal durch die vorhandenen Informationen 
arbeiten, bevor ich da präzise Fragen stellen kann.

Grundsätzlich sieht meine Arbeitsliste so aus:

1. LEON Demo zum Laufen kriegen. Diesen Schritt hatte ich ja schon mal 
in Angriff genommen, war aber leider gescheitert. Bevor das nicht klappt 
brauche ich wohl gar nicht erst weiter zu machen.

2. C/C++ Entwicklungsumgebung (SDK) installieren und ein eigenes 
Testkompilat erstellen um die grundsätzliche Funktionalität zu 
überprüfen.

3. Grundsätzliche Gedanken machen zur zukünftigen Programmstruktur.

4. Die NIOS-Firmware evtl. an diese Struktur anpassen um 
Plattformübergreifend entwickeln zu können.

5. Die vorhandenen LEON Hardwaretreiberroutinen für die neue 
Programmstruktur portieren/anpassen

6. Schritt für Schritt die neue Firmware implementieren.


Gibt es für das SDK auch schon Anleitungen? Für welche Betriebssysteme 
gibt es die Entwicklungsumgebung? (Windows?, Linux?) Wo kriege ich das 
SDK her?

Dazu gibt es vermutlich auch schon Anleitungen, aber ich bin da noch 
nicht so weit vorgedrungen. Es gibt da also noch einiges zu tun.

Übrigens sind die fehlenden zwei Kanäle nicht die einzige Einschränkung. 
Das LEON-Design unterstützt nur einen UART. D.h. es gibt nur entweder 
eine RS232 oder eine USB-Unterstützung. Welches von beiden Alex da jetzt 
vorgesehen hat muß ich noch prüfen.


Gruß Hayo

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi branadic,

darf ich wieder aufhören mich zu schämen? ;-)

Gruß, Guido

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt muß ich mal lachen, denn manchmal kann es schon lustig mit euch 
sein!!!

Gruß Michael

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist ja was los!

Wollte auch schon länger mal was schreiben, zum Thema Leon, 
Software-Migration, Zeitpläne.

Zeitpläne und Hobbyprojekte passen schon mal gar nicht zusammen. 
Erwartungshaltungen auch nicht, denn wir reden hier von Dingen die Leute 
in ihrer Freizeit tun. Wieviel sie davon aufbringen und woran sie Spaß 
haben ist ihnen schwer vorzuschreiben.

Ich habe selbst das Leon-Design noch nicht ausprobiert. Eine 
geschlossene und aktuelle Anleitung wie dafür vorzugehen ist wäre 
natürlich eine prima Hilfe. Nur falls das noch nicht zusammengetragen 
ist. Das kann auch jemand tun der nicht entwickelt.

Ich will da "irgendwann" aber mit Sicherheit ran. Vorher gibt es 
dummerweise noch 2 andere große Hobbyprojekte abzuschließen, und meine 
Ehe gilt es auch zu erhalten. Deshalb bin ich nur so sporadisch dabei.
Die Voraussetzungen sind eigentlich prima: Ich bin hauptberuflich 
langjähriger Softwareentwickler im Embedded-Bereich, unsere Firma macht 
anspruchsvolle ASIC- und FPGA-Designs. Ich kann selbst leider kein HDL, 
aber könnte Alex' Design zu gegebener Zeit mal mit den Profis im 
Kollegenkreis durchgehen. Davon verspreche ich mir noch was, denn mit 
Verlaub und allem Respekt, Alex hat(te) da noch nicht so viel Erfahrung. 
Spatzen auf dem Dach, zugegeben.

Branadic hat meinen Vorschlag einer Hardware-Abstraktionsschicht 
zitiert, und Hayo ihn als möglicherweise performancefressend kritisiert. 
Das sehe ich nicht so, dann wären die Schnittstellen falsch gewählt bzw 
implementiert.
Im Gegenteil, ich denke ordentliche Interfaces wären sogar ein Gewinn. 
In der Nios-Software fallen mir ständig (naja, wenn ich denn mal da 
reingucken muß) ungeschickte Dinge auf. Wenn der Autor Datenstrukturen , 
Arrays, und das Schlüsselwort "const" gekannt hätte wäre auch schon viel 
gewonnen.

Das "Schlimmste" was passieren könnte wäre wenn Hayo sich abguckt wie 
die Leon-Hardware bedient wird und das dann alternativ in die 
Nios-Software reinzwingt. Dann hätten wir ein noch unwartbareres Monster 
als jetzt schon.
Eine ordentliche Struktur sollte vorher schon her. Meine vielleicht 
etwas zu naive Vorstellung der Vorgehensweise wäre:
- Zusammentragen der Hardwareansteuerung in beiden Designs
- Definition der Schnittstellen, z.B. mit Doxygen
- gemeinsamen Build-Flow für beide Platformen aufsetzen
- Implementation dieser unteren Schichten
- Portierung von Codeteilen aus dem Nios-Design, bzw. ordentliche 
Neuimplementation nach schlechter Vorlage
- Weiterentwicklung

Natürlich ist das erstmal eine Konsolidierungsphase oder gar ein Schritt 
zurück, bevor es dann viel besser weitergehen kann. Und macht 
wohlmöglich keinen Spaß, siehe oben. Aber wird früher oder später 
kommen, daran glaube ich schon.

Ich habe mal etliche Jahre in einem recht großen Open-Source Projekt 
mitgearbeitet (www.rockbox.org), war zeitweilig einer der 
Hauptentwickler. Aus deren FAQ, ich könnte es nicht besser ausdrücken:

Why are you developing X when you should be doing Y?

You make the common mistake of confusing Rockbox development with that 
of commercial projects. There is not much of an agenda for the 
development of Rockbox. Anyone who wants to write new features can do 
that.

If there is a current "huge emphasis" on the X functionality, it is 
because one or more developers, decided he/they wanted to write it. It's 
not because "Rockbox project management" decided function X is a more 
important feature than anything else.

That is the nature of free software: people write code that scratches 
their own itches, or that simply is fun to write. Everybody working with 
Rockbox is doing it for fun. A wide or narrow audience actually has only 
little bearing on the choice of features to implement.

The moment someone with a bit of time to spare and the necessary 
programming skills (or a will to learn them) feels function Y is a 
sufficiently useful feature, it will be written.

(That could be you.)


@Hayo: habe ich mal irgendwo gelesen, daß du in oder bei Hamburg wohnst? 
Demnächst könnte ich da in der Nähe sein, vielleicht können wir uns mal 
zusammenhocken.

Jörg

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,

habe Deine Email heute morgen erhalten und kurz beantwortet. Leider 
komme ich hier in der Firma über den Proxy nicht an meine Emails, daher 
hier meine Gedanken zu dem LEON-Projekt.

Mein anfängliches Zögern beruht unter anderem darauf, dass ich 
eigentlich ungern halbe Sachen machen möchte wenn sich hier die 
Möglichkeit bietet die Firmware neu aufzusetzen.

Das wiederum bedeutet aber (hatte ich ja schon angedeutet), dass die 
NIOS-Firmware auf die neue Struktur angepasst werden müßte um beide 
Plattformen weiterhin parallel supporten zu können.

Und genau dieser zeitliche Aufwand hat mich etwas abgeschreckt. Aber ich 
bin eigentlich Deiner Meinung, dass man nicht die LEON-Plattform nach 
den alten NIOS-Strukturen ausrichten sollte sondern umgekehrt.

Ehrlicherweise muß ich zugeben das mir hier etwas die Erfahrung fehlt, 
da ich bislang nur sehr hardwarenah (Studium) und danach nur noch im 
SAP-Umfeld Software entwickelt habe.

Du erwähnst z.b. ein Tool wie Doxygen, da bräuchte ich dann etwas 
Nachhilfe. Bin aber auf jeden Fall interessiert etwas dazuzulernen.

Ich denke es gibt da einige Ideen auszutauschen und es kommt auch dem 
NIOS-Projekt zu Gute wenn die Softwarebasis mal geradegerückt wird.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatte gerade etwas Zeit und habe mal Doxygen runtergeladen und 
ausprobiert. Nicht übel! Das macht ja eine ganz nette Übersicht und ist 
einfacher zu bedienen als ich dachte.

Was dabei besonders auffällt ist ein Punkt der mir auch schon länger am 
Herzen liegt - die Namenskonvention.

Es gibt da ein ziemliches Durcheinander bei der Namensgebung, das auf 
jeden Fall beseitigt werden muß um eine vernünftige Basis zu schaffen.

Gruß Hayo

Autor: Robert S. (razer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Was dabei besonders auffällt ist ein Punkt der mir auch schon länger am
> Herzen liegt - die Namenskonvention.

Crazor hat sich schon vor zeiten dazu mal Gedacnken gemacht und einen 
Coding Standard am Wiki verfasst: 
http://sourceforge.net/apps/trac/welecw2000a/wiki/...

Vielleicht lässt sich auf den aufsetzten oder er sich anpassen.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Robert,

das ist ein guter Hinweis. Den Beitrag kannte ich noch nicht. Zu 95% 
stimme ich den Vorschlägen zu und setze das bei meinem Coding auch schon 
so um.

Nur beim Identifier Naming benutze ich entgegen Crazors Vorschlag 
eigentlich ganz gern den CamelCaseStyle und nicht so gerne den c_style, 
da dieser die Bezeichner oft ziemlich in die Länge zieht. Manchmal 
benutze ich auch Kombinationen davon (ist natürlich nicht ganz 
konsistent dann).

Aber da müßte man sich dann eben festlegen, da das die Lesbarkeit des 
Codes wesentlich beeinflussen kann.

Leider hat sich der WELEC-Programmierer einen Dreck um irgendwelche 
Namenskonventionen geschert und so fliegen da Unmengen von 
unterschiedlichen Bezeichnern durch die Firmware. Da eine Linie 
reinzubringen ist schon etlicher Aufwand.

Dazu kommt, dass sämtlich Variable global deklariert sind. Ich würde da 
eigentlich etliche Variablen lieber je nach Kontext in die 
entsprechenden Klassen verlegen.

All das ist ne Menge Arbeit, die nach außen keinerlei sichtbare 
Auswirkungen hat, aber zukünftige Entwicklungen begünstigt.

Gruß Hayo

Autor: manfred.h (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kollegen,

habe aus alter Gewohnheit wieder einmal ins Forum reingeschaut. Dabei 
habe ich bemerkt, dass ihr gute Fortschritte macht. Gratulation.

Ich selber habe meinem defekten Oszi noch eine Chance gegeben und es 
meinem Sohn nach Wien zur Reparatur geschickt. Sollte der nichts 
ausrichten, was zu befürchten ist, kann ich das Oszi oder einzelne Teile 
davon eventuell Interessenten von euch zuschicken. Aber bitte noch etwas 
Geduld. Ihr lest dann davon.

Habe mich inzwischen mit einem OWON eingedeckt, da es von WELEC ja keine 
Geräte mehr gibt. Bin damit im Moment sehr zufrieden und kann so weiter 
meinem Hobby frönen :-)

Manfred

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manfred,

schreib doch mal ein paar Details zu Deinem neuen Spielzeug. Mich würde 
mal interessieren mit welchen Eckdaten das Gerät aufwartet und ob die 
Spezifikationen auch wirklich so zutreffen.

Ist die Firmware einigermaßen Bugfrei?

Welches Gerät (Typenbezeichnung) ist es denn?

Gruß Hayo

Autor: manfred.h (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

wollte nicht allzuviel für ein neues DSO ausgeben. Es gibt bei EBAY den 
100MHz-2Kanaler OWON SDS7102 um 337 Euro, dazu kommen 17Euro Zoll, 
Versand ist gratis. Ich habe eine LiPo-Batterie und den VGA-Ausgang 
dazugekauft (+72Euro), also alles in allem 426,-. Mangels Testequipment 
kann ich nicht sagen, wie genau die Spezifikationen eingehalten werden.

Auffallend: sehr schnelle Lieferung aus Hongkong in 3 Tagen, handlich, 
leicht, 4 Stundenbetrieb mit Batterie, beeindruckender 
800x600-SVGA-Bildschim, gute Triggerung (Combitrigger geht ab) auf jeden 
Kanal alternierend möglich, 2mV bis 50V, wenig Rauschen, 10M 
Speichertiefe (tolle Sache), Timebase 2ns/div bis 100s/div, 1GS/s, wobei 
gestoppt und dann weit in die Tiefe gezoomt werden kann, 2 verschiedene 
Automatikmessungen, diverse Speichermöglichkeiten, auch von ganzen 
Serien bis zu 1000 Bilder, usw...

Die Firmware ist an etlichen Punkten verbesserungsfähig, das hättest du 
besser hingekriegt. Die Hardware scheint ok zu sein. Für meine 
Bedürfnisse wirklich ein beeindruckendes Gerät.

Anbei noch ein Bild Einer Messung von heute.

Manfred

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
manfred.h schrieb:
> Anbei noch ein Bild Einer Messung von heute.

Da sind sie wieder - die Zeitangaben der Cursor bezogen auf den 
Triggerzeitpunkt ;-)

Gruß
Rainer

Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Manfred

SDS7102 compared to W2022A is more expensive and buggy,see on 
youtube.And
with Welec we have electrical diagrams and a continuos improvement..
Regards

Sandro

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
You are right Sandro,

but I have to admit that features like VGA-Output, big 800x600 TFT, deep 
memory and LiIo- Accu are nice to have.

Another interesting thing I found about it is the (perhaps) possibility 
to hack the DSO to the next higher bandwidth level. The bandwidth is 
limited by the LMH6518 amplifier which bandwidth can be set up to 900 
MHz by SPI programming - fascinating.

On the other side the chinese developers made some bad (HF) mistakes on 
the PCB-design and finishing. Some of them can (perhaps) be corrected by 
Yourself (like floating grounds or unshielded cables).

I'm flirting with the idea to get one (SDS8102 / 2GHz) as template for 
some new ideas and reference for our WELEC.

Maybe we need a new OWON thread...   ;-)

Regards Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok ich hab es gemacht! Das SDS8102 ist bestellt.

Sollte bis zum Wochenende da sein. Habe es allerdings beim deutschen 
Importeur bestellt da mir Garantie und Rückgabemöglichkeit den Aufpreis 
wert sind.

Das dürfte ein interessanter Vergleich werden. Mal sehen was man für 
unser WELEC so abkupfern kann :-).

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gehe schwer davon aus, dass du dir das fünfteilige Video auf 
"duröhre" angeschaut hast?
So viel mehr als den alternierenden Trigger wirst du auch nicht finden. 
Und soweit ich die Kritik vernommen habe scheint auch das Owon 
erhebliche Schwächen in Hard- und Software aufzuweisen. Als Beispiel sei 
nur mal der Triggerausgang genannt.

Ist dagegen bekannt, dass Rigol in die 600MHz (DS6062 und DS6064) und 
1GHz-Klasse (DS6102 und DS6104) vorgedrungen ist? Damit hebt sich Rigol 
von den anderen Geräten wieder etwas ab.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja die Videos kenne ich.

Zur Firmware:

Der Händler in Chemniz sagte mir, dass die neueste Firmwareversion drauf 
ist (von letzter Woche). Alle bislang bekannten Fehler sollen wohl 
behoben sein, mal sehen...

Zur Hardware:

Ja, ich weiß von einigen Fehlern im Design. Nachdem was ich gesehen habe 
kann man aber einige selbst beheben bzw. zumindest verbessern.

Wenn das Ding sich als überbezahlte Brotdose entpuppt schicke ich es 
einfach zurück. Das ist eben der Vorteil beim einheimischen Händler, 
auch wenn er etwas teurer ist als die Direktimporte. Über ein RIGOL 
hatte ich auch schon nachgedacht, auch über ein Hantek. Bei letzterem 
finde ich es sehr charmant, dass da Linux drauf läuft.

Letztlich fand ich aber das OWON am interessantesten. Bei meiner Auswahl 
war mir die Bandbreite nicht ganz so wichtig, da mein Bedarf deutlich 
unter 100MHz liegt, und das SDS8102 bis ca. 150MHz sinusförmige Signale 
noch ganz akkurat darstellt (es gibt da irgendwo einen deutschen Test). 
Wichtiger war mir die höhere Abtastrate von 2GHz, weil man dann mehr 
echte Meßpunkte hat und das dargestellte Signal dann auch mehr der 
Wirklichkeit entspricht.

Btw, was ich interessant finde ist die theoretische Möglichkeit die 
Bandbreite aufzubohren in dem man den Eingangsverstärker umprogrammiert 
(wie auch immer).

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Eingangsverstärker hat den gleichen VGA an Board wie auch die 
Huckepackplatine, den LMH6518 und der wird via SPI konfiguriert. 
Allerdings macht das "Aufbohren" nur begrenzt Sinn, da zum Einen Nyquist 
die Finger mit im Spiel hat, zum Anderen sind bei denen weitere Bauteile 
im Signalpfad, die die Bandbreite bereits vorher begrenzen.

http://www.mikrocontroller.net/attachment/122374/O...

aus dem Thread:

Beitrag "Neue OWON-Oszilloskope? Owon SDS6062 60MHz"


branadic

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Das SDS8102 ist bestellt.

Gibt es da einen Ansatz, eigene Software reinzukriegen? Sprich, ist das 
Ding offen?

Jörg

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, genug gemutmaßt!

Das Teil ist um 14:00 angekommen (hitverdächtig schnell - gestern 
bestellt!) und ich bin seitdem am Testen.

Erster Eindruck:
Keine überberbezahlte Brotdose sondern für den Hausgebrauch eine feine 
Sache. Das Menü empfinde ich als etwas umständlich im Vergleich zu 
unserem Baby, aber man kommt recht schnell damit klar. Wie schon öfters 
in einigen Foren angemerkt ist die Haptik der Menüknöpfe mit dem "Klick" 
nicht so schön wie unsere Softbuttons, aber es funktiomniert.

Die Drehknöpfe sind leider nicht wie unsere gummiert, sondern nur aus 
Plastik. Das hört sich aber schlimmer an als es ist. Es läßt sich 
trotzdem recht gut bedienen.

Was mir etwas besser gefällt als beim WELEC, das ist der Umstand, dass 
die Drehencoder für die Funktionen die häufiges Drehen erfordern 
(Zerolevel-Verstellung, Pretrigger-Scrolling etc.) keine Rastung haben. 
Sie fühlen sich also an wie Analogdrehknöpfe und "rattern" daher auch 
nicht.

Auch der Trigger macht einen sehr stabilen Eindruck. Die einzelnen 
Triggeroptionen werde ich noch testen.

Ich werde also wohl das Teil nicht wieder zurückschicken sondern für 
weitere Vergleiche behalten. Ich habe ja auch noch etwas Zeit mir das zu 
überlegen.

Grundsätzlich macht die Firmware erstmal einen stabilen Eindruck - 
Fehler konnte ich auf die Schnelle noch keine finden.


@Branadic

> Der Eingangsverstärker hat den gleichen VGA an Board wie auch die
> Huckepackplatine, den LMH6518 und der wird via SPI konfiguriert.

Das ist ja Witz an der Sache!

Die Hinweise kannte ich schon, danke. Grundsätzlich gehe ich aber schon 
davon aus, dass eine Umprogrammierung die Bandbreite auf 200 oder 300MHz 
erhöt.


@Jörg

Soweit ich weiß gibt es da momentan noch nichts Aktuelles. Dafür ist die 
Büchse wohl noch zu neu. Aber so wie die sich verkauft wird das wohl 
nicht ausbleiben. Die original Firmware ist wohl, wie ich irgendwo 
gelesen habe, verschlüsselt.

Ich dachte beim Bandbreitenhack auch an die Möglichkeit da an den SPI 
einfach andere Hardware dranzuhängen, die die Initialisierung macht.

Wenn Du am 3.12. vorbeikommsz kannst Du Dir ja ein eigenes Bild von dem 
Gerät machen.

So, werd jetzt noch ein wenig rumspielen, wär ja gelacht wenn ich nicht 
doch noch ein paar Fehler finde. Ein genauerer Vergleich mit unserem 
Schätzchen folgt natürlich auch noch.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rainer W. schrieb:

> Da sind sie wieder - die Zeitangaben der Cursor bezogen auf den
> Triggerzeitpunkt ;-)

Du hast recht, beim Owon sind alle Horizontalangaben auf den 
Triggerzeitpunkt bezogen. Ich stelle aber beim Testen an einigen Stellen 
fest, dass das nicht immer so praktisch ist. Am Besten man kann es sich 
so einstellen wie man es braucht...

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So,

da das Thema etwas umfangreicher werden könnte, hab ich mal einen 
Parallel-Thread aufgemacht.

Beitrag "WELEC W2000A vs. OWON SDS8102"


Da werde ich dann den Vergleich fortführen. Hab auch schon die erste 
Macke gefunden :-).

Gruß Hayo

Autor: wirehead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls mir jemand eine defekte Mainboardplatine zukommen lassen möchte 
könnte ich ein deteiliertes Röntgenbild anfertigen. Dann könnte man 
vieleicht die Verbindungen der Adcs sehen.
Ansonzten muss ich meine ausbauen was etwas dauern kann.

Gruß
Torsten

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cool, wie kommst Du denn zu sowas? Ein Röntgengerät hat man ja 
eigentlich nicht so im heimischen Bastelzubehör oder?

Und wie verkraften die Bauteile die Strahlung? Ist das unkritisch?

Gruß Hayo

Autor: Stephan S. (outsider)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Was mir etwas besser gefällt als beim WELEC, das ist der Umstand, dass
> die Drehencoder für die Funktionen die häufiges Drehen erfordern
> (Zerolevel-Verstellung, Pretrigger-Scrolling etc.) keine Rastung haben.
> Sie fühlen sich also an wie Analogdrehknöpfe und "rattern" daher auch
> nicht.

Da wurde ja auch schon einiges versucht andere Encoder aufzutreiben, was 
aber immer auch recht teuer wäre. Hat sich die eingebauten Encoder im 
Welec mal jemand genau angeschaut? Ich hab mir überlegt ob man da nicht 
irgendwo mit dem Seitenscheider ansetzen könnte und einfach den 
Rastmechanismus rauszwickt oder blockiert. Käme man da irgendwie ran?

Autor: Sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

den Versuch das PCB zu röntgen hab ich auch schon gemacht. Auf einem 
medizinischem Röntgengerät. Den Bauteilen hat es auf jeden Fall nicht 
geschadet. Das Ergebnis war aber nicht sehr aufschlussreich. Man 
erkannte zwar die einzelnen Bauteile und auch die Die-Träger und Pins, 
Details wie die Leitungen auf und im PCB waren aber leider nicht zu 
erkennen. Auch mit einem höher auflösendem Gerät wird es wohl schwierig 
da das massive Innenleben der IC's die "Sicht" auf die darunter 
liegenden feinen Strukturen versperrt.

Gruß Sunny

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan S. schrieb:

> Ich hab mir überlegt ob man da nicht
> irgendwo mit dem Seitenscheider ansetzen könnte und einfach den
> Rastmechanismus rauszwickt oder blockiert. Käme man da irgendwie ran?

Hab ich noch nicht gesehen. Wenn man die Feder von außen einfach 
beseitigen könnte wäre das natürlich nicht schlecht. Dann würde ich bei 
mir sofort einige Encoder davon befreien.

Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
>> Ich hab mir überlegt ob man da nicht
>> irgendwo mit dem Seitenscheider ansetzen könnte und einfach den
>> Rastmechanismus rauszwickt oder blockiert. Käme man da irgendwie ran?
>
> Hab ich noch nicht gesehen. Wenn man die Feder von außen einfach
> beseitigen könnte wäre das natürlich nicht schlecht. Dann würde ich bei
> mir sofort einige Encoder davon befreien.

Ich kann euch verraten dass das nicht geht, die Encoder sind wie sie 
sind. Die einzige Möglichkeit die ihr habt, kauft euch die Alps-Encoder 
bspw. von Reichelt STEC11B04. Vielleicht gibt es die anderswo noch 
günstiger. Die sind kompatibel, lediglich die Welle ist als geschlitzen 
Welle ausgeführt und haben Impulse: 15 / Rastungen: 30.
Man müsste also die Welle passend auf die Encoderknöpfe 
zurechtfeilen/fräsenDie Rastung ist um Welten weicher und nicht so hart 
wie bei den Welec-Encodern. Selbst die Variante mit Taster STEC11B03 
fühlt sich gut an.
Warum ist eigentlich noch niemand das Front-Panel angegangen? Das ist ja 
nur eine 2-lagige Platine. Man könnte die überarbeiten und gleich ein 
paar Encoder mit Taster an den richtigen Stellen vorsehen. Außer den 
Softbuttons ist das ja keine große Sache. Sonderlich teuer dürfte eine 
solche Leiterplatte auch nicht werden, selbst mit Gold-Finish.

branadic

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die ALPS-Encoder gibt es auch "voll kompatibel", mit abgeflachter Welle. 
Ich hatte mir damals Darisus als möglichen Lieferanten rausgesucht.

Das Frontpanel überarbeiten habe ich auch mal kurz erwogen, wenn auch 
aus anderem Grund: um das LCD weiter nach vorne zu setzen. Derzeit würde 
es mit dem Platinenfortsatz der die Softbuttons trägt kollidieren.
So eine Platine wäre recht groß und daher nicht ganz billig. Ein paar 
Encoder mit Taster bekäme man bestimmt leicht fliegend verdrahtet. Es 
sind eh nur 4 Eingänge frei.

Jörg

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mich bei Alps mal etwas umgeschaut und folgende Encoder 
herausgesucht:

Kanal-Offset: ohne Rastung, ohne Schalter --> EC11E1530401
Vertikalablenkung: mit Rastung, ohne Schalter --> EC11E15204A3
Horizontalablenkung: mit Rastung, ohne Schalter --> EC11E15204A3
Triggerzeitpunkt: ohne Rastung, mit Schalter --> EC11E153440D
Triggerlevel: ohne Rastung, mit Schalter --> EC11E153440D
Multifunktionsencoder: ohne Rastung, mit Schalter --> EC11E153440D

Alle Encoder haben 15 Impulse pro Umdrehung.
Zu den Schalterfunktionen:

Multifunktionsencoder: frei konfigurierbar für Menufunktionen
Triggerzeitpunkt: ein Druck stellt zurück auf 50%
Triggerlevel: ein Druck stellt auf 50% Triggerlevel oder auf Null

Damit wären 3 von 4 freien Eingängen belegt.

branadic

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich denke das mehr Impulse besser wären um feinfühliger scrollen zu 
können, die kann man bei der Auswertung immer noch runterrechnen, wenn 
aber Impulse fehlen kann man keinen mehr dazuzaubern. Nach einigen 
Impulsen kann man das Scrollen dann softwaretechnisch immer noch 
beschleunigen.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sehe ich auch so.

Autor: Stephan S. (outsider)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich glaub ich will nicht so viel Geld für ein neues Frontpanel und 
ne Menge neuer Encoder ausgeben. Das läppert sich bei so vielen Encodern 
ganz schön. Ich dachte halt einfach nur dass es vielleicht eine 
Einfachstlösung gibt um die Rastung los zu kriegen. Vielleicht kann man 
das Gehäuse ja irgendwo anbohren oder aufbiegen um an den Mechanismus 
ranzukommen. Vielleicht müsste man mal einen opfern und zerlegen. Oder 
röntgen. Ich bin jetzt noch eine Woche in China, aber dann könnte ich 
mich der Sache mal annehmen.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
branadic schrieb:
> Alle Encoder haben 15 Impulse pro Umdrehung.

Aber 30 (zarte) Rastungen, hier gab es nachfolgend wohl 
Mißverständnisse.
Die Kurbelei bliebe also unverändert, aber fühlt sich besser an und es 
gibt optional eine Taste.

Wir müßten noch klären, ob das FPGA die letzten 4 Bits auch der Software 
zur Verfügung stellt.

Jörg

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan S. schrieb:
> Also ich glaub ich will nicht so viel Geld für ein neues Frontpanel und
> ne Menge neuer Encoder ausgeben.

Angenommen man nimmt alle mit zarter Rastung, wie Jörg das so schön 
formuliert hat, dann käme der Preis für ein 4-Kanalgerät gerade mal auf 
27,-€ zzgl. Versand, dafür hätte man dann drei zusätzliche Taster.

9x EC11E15204A3 + 3x EC11E15244G1

Ein 2-Kanalgerät käme auf 18,-€.

5x EC11E15204A3 + 3x EC11E15244G1

Ich finde das jetzt nicht so viel wie du das erscheinen lassen wolltest.

branadic

Autor: Stephan S. (outsider)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist tatsächlichnicht so viel wie ich dachte. Wo gibts die denn zu 
dem Preis? Ich hatte die teurer in Erinnerung.

Wenn wir ein paar Leute mehr zusammen kriegen würden, dann sind auch die 
Leiterplatten nicht so teuer. Leiterplattenfläche ist garnicht so teuer 
wenn die Stückzahlen höher werden. Nur bei einstelligen Stückzahlen ists 
immer unangenehm teuer.

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kommt ganz darauf an, wo man die bestellt, Darisus wurde ja als 
mögliche Quelle genannt. Es gibt aber auch noch andere Distributoren wie 
RS etc.

Ich habe noch mal drüber geschlafen und finde, dass es eine gute Idee 
ist alle bis auf die Encoder für die Ablenkungen zu tauschen. Diese 
gehen recht schwer und fühlen sich daher wie Schalter an. Das würde ich 
so auch lassen wollen. Alle anderen Encoder werden gegen solche mit 
zarter Rastung getauscht. Die Encoder für Triggerlevel, Triggerposition 
und der Multifunktionsencoder gegen solche mit Taster. Ich für meinen 
Teil denke, dass das die beste Kombination ist, mit einem guten Spektrum 
an Haptik.

Das käme dann 24,50€ zzgl. Mwst. für ein 4-Kanäler gleich.

branadic

Autor: Alexis Sch. (seraptin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da währe ich auch mit dabei! Ich hatte sowas schon länger vor, 
allerdings bin ich wie so oft einfach nicht dazu gekommen.

Um ehrlich zu sein sind die Taster einer der Punkte die mich am meissten 
stören am Welec. Hier schonmal vielen Dank an branadic für die 
Recherchearbeit und die ganzen Hardwareverbesserungen :)

Autor: Stephan S. (outsider)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre das dann mit den Tastern? Würden die original Drehknöpfe noch 
passen? Was ich nicht wollte, wäre ein Oszi was dann auf den ersten 
Blick verbastelt aussieht weil die Knöpfe zu weit raus stehen müssen um 
noch weg zum Drücken zu haben, oder abgesägte oder abgefeilte Knöpfe um 
den Weg zu ermöglichen.

Und wenn schon eine neue Leiterplatte gemacht wird: gibts sonst noch was 
anderes was da mit drauf könnte? Könnte ja auch was sein, was jetzt 
garnicht mal unbedingt was mit der Bedienung zu tun hat.

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An alle Sammelbesteller: Bitte beachtet meine Infos und Updates im 
Hardware Thread!

[Alle Bestellungen die keinen USB-Host enthalten sind fertig verpackt 
und werden morgen abgeschickt.]

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wäre bei einer Sammelbestellung bzgl. Drehencoder und Platine mit 
einem Statz für das 4-Kanal und einem Satz für das Zweikanalgerät dabei. 
Unter Umständen hätte mein Kumpel auch noch Interesse für sein W2022A.

Übrigens ist das mit den Drucktasten im Encoder wirklich sehr praktzisch 
wie ich beim OWON feststelle. Allerdings finde ich den Kraftaufwand für 
das Auslösen etwas zu hoch. Man schiebt das Gerät wenn es frei steht 
dann über den Tisch.

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Sammelbestellung werde ich dann auch noch übernehmen.
Alle Interessenten melden sich bitte an meine sourceforge Adresse (zu 
finden auf 
http://sourceforge.net/apps/trac/welecw2000a/wiki/...)

Die USB-Host Sammelbesteller würden keinen Versand zahlen. Alle anderen 
2,50€.

Preis für 2 Kanäle: 21,07€ inkl. Steuer (+ Versand)
Preis für 4 Kanäle: 29,21€ inkl. Steuer (+ Versand)

Wenn es genug Mengenrabatt gibt, wird es auch noch etwas günstiger.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind die Drehencoder dann auf der Originalplatine?

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nochmal langsam, was sind das für andere Drehencoder? Mehr 
Impulse/Umdrehungen oder nur ein weicheres rasten + Kontakt zum drücken?

Autor: Marc Braun (tvdog)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kurt,

ich wäre auch dabei beim Austausch der Encoder in meinem W2022A.
Du hast PN.

Vielen Dank nochmals.

Gruß
Marc

Autor: Sebastian S. (sebastian_s47)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich würde vorschlagen, die Diskussion zu den Dreh-Encodern im 
Hardware-Thread weiter zu führen 
(Beitrag "Wittig(welec) DSO W20xxA Hardware") - genügt ja 
wenn hier ein Hinweis dazu steht und dann im anderen Thread die Details 
geklärt werden.

Gruß
Sebastian

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal das Startverhalten der Software beschleunigt. Mein 4Kanäler 
braucht nun nur noch 9 Sekunden vom Einschalten bis zum Wellenzappeln, 
vorher waren es 18 Sekunden. Also doppelt so schnell.  :-)

Und das mit 2 ganz einfachen Maßnamen, da waren immense Warteschleifen:

1.) beim LED-Selbsttest schalte ich die LEDs nur noch ein, kein Geblinke 
mehr, das abgewartet wurde bevor es weitergeht

2.) der Splash-Screen macht keine künstliche Verzögerung des 
Bootvorgangs mehr. Er ist trotzdem knapp 2 Sekunden zu sehen währen das 
Oszi zuende initialisiert. Wer sich sehr dafür interessiert kann ja 
später mit Utility->About in Ruhe nachschauen.

Anbei die Firmware und auch der Quellcode, zur besseren Auffindbarkeit 
haben meine bescheidenen Änderungen einen Kompilerschalter "QUICKSTART" 
drumrum. Ich hoffe Hayo mag das einpflegen, auch wenn er kürzer 
gewürdigt wird.

Wenn man das ganze mal richtig angeht läßt sich da bestimmt noch einiges 
mehr rausholen. In der Software wird viel blockierend gewartet (und 
Multitasking kann sie nicht), m.E. oft unnötig lang, so langsam ist die 
Hardware nicht. Eine Irrtumsquelle dürfte die Funktion nr_delay() aus 
der Nios-Lib sein. Deren Argument sind nicht Millisekunden, sie wartet 
deutlich länger. Ich hatte es mal gemessen, aber wieder vergessen...

Jörg

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg H. schrieb:
> Ich habe mal das Startverhalten der Software beschleunigt. Mein 4Kanäler
> braucht nun nur noch 9 Sekunden vom Einschalten

Endlich mal wieder ein praktischer Beitrag im Firmware Thread....
Danke Jörg!

Jürgen

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg H. schrieb:
> Ich habe mal das Startverhalten der Software beschleunigt. Mein 4Kanäler
> braucht nun nur noch 9 Sekunden vom Einschalten bis zum Wellenzappeln,
> vorher waren es 18 Sekunden. Also doppelt so schnell.  :-)

Ich fand das an sich nicht weiter störend, deshalb habe da an der 
Bootsequenz auch nichts verkürzt. Ist aber natürlich kein Problem das 
Ganze grundsätzlich zu verkürzen.


> Und das mit 2 ganz einfachen Maßnamen, da waren immense Warteschleifen:

> 1.) beim LED-Selbsttest schalte ich die LEDs nur noch ein, kein Geblinke
> mehr, das abgewartet wurde bevor es weitergeht

Hatte ich als LED-Test so konzipiert da man die Funktion ganz gut 
erkennen kann. Läßt sich bei Bedarf natürlich auch verkürzen oder 
weglassen.

> 2.) der Splash-Screen macht keine künstliche Verzögerung des
> Bootvorgangs mehr. Er ist trotzdem knapp 2 Sekunden zu sehen währen das
> Oszi zuende initialisiert. Wer sich sehr dafür interessiert kann ja
> später mit Utility->About in Ruhe nachschauen.
Kann man machen. Das geht aber auch erst seit den letzten 
Firmwareversionen. Vorher war immer noch ein DeleteSplash() nötig.

> Anbei die Firmware und auch der Quellcode, zur besseren Auffindbarkeit
> haben meine bescheidenen Änderungen einen Kompilerschalter "QUICKSTART"
> drumrum. Ich hoffe Hayo mag das einpflegen, auch wenn er kürzer
> gewürdigt wird.
Auf die Würdigung kann ich auch verzichten :-) - es geht ja im 
Wesentlichen um die Identifizierung der Firmwareversion.


> Wenn man das ganze mal richtig angeht läßt sich da bestimmt noch einiges
> mehr rausholen. In der Software wird viel blockierend gewartet
Das ist richtig, aber eigentlich meistens mit Grund.

> (und Multitasking kann sie nicht)

Jein, wenn man das Warten über einen Timer löst ist es quasi wie 
Multitasking. Wird auch an einigen Stellen gemacht.



> Eine Irrtumsquelle dürfte die Funktion nr_delay() aus
> der Nios-Lib sein. Deren Argument sind nicht Millisekunden, sie wartet
> deutlich länger.

Stimmt, das Delay ist nur grob geschätzt, aber an einigen Stellen ganz 
nützlich

Ich baue die Änderungen gerne ein wenn es glückliche DSO-Besitzer 
erzeugt :-)

Gruß Hayo

Autor: tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

ja - bitte so schnell wie möglich booten. Sollte wirklich mal jemand 
Probleme mit einer LED haben, dann wäre ein Testmodus im Utility-Menü 
nützlicher als jedesmal beim Einschalten zu warten.

Die Wahrscheinlichkeit, dass 1. tatsächlich mal eine LED ausfällt und 
dass man 2. beim Einschalten auch tatsächlich "inventur macht" und alle 
LEDs checkt ist so gering, dass man einen Ausfall in der Regel ohnehin 
erst im Betrieb bemerkt und dann beim Einschalten genau aufpasst - und 
hier wäre man mit einem Eintrag im Utility-Menü genauso gut bedient.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ist was dran - und Du hast mich auf die Idee gebracht dass man einen 
LED-Test im Hardwaremenü einführen könnte.

Besten Dank

Hayo

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt ihr die Firmware ausprobiert, bzw. habe ich mich undeutlich 
ausgedrückt? Beim Booten werden nach wie vor alle LEDs eingeschaltet, 
solange bis das UI richtig loslegt leuchten sie. Ihr habt also immer 
noch die Möglichkeit, diese ach so unzuverlässigen LEDs bei jedem Booten 
zu überprüfen.  ;-)

Ich finde, Geräteentwickler sollten sich durchaus Mühe geben, dem 
instant-on so nah wie möglich zu kommen. Steve Jobs hat einem Mac-OS 
Entwickler zur Motivation seinerzeit vorgerechnet, das er mit ein paar 
Sekunden extra ganze Menschenleben an Zeit vernichtet.

Hayo: Der Compilerschalter kann dann natürlich raus, das war nur zum 
Testen und Finden.

Jörg

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch doch, das hatte ich schon richtig verstanden, aber die Idee einen 
LED-Test im Hardwaremenü unterzubringen fand ich trotzdem gut. Zur Not 
kann man den auf einer Party dann als Lichtorgel benutzen ;-)

Zur Zuverlässigkeit: Ich bin halt in einer Zeit aufgewachsen als es noch 
keine LED gab und alle Geräte noch Kontroll-Lämpchen hatten. Da war war 
es schon nicht unwichtig einen Test zu machen. Bei den LED heutzutage 
hat das wohl eher Unterhaltungswert.

Gruß Hayo

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>kann man den auf einer Party dann als Lichtorgel benutzen

Dann aber bitte den LED-Test auch an die FFT anbinden! ;-)

Viele Grüße,

egberto

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In Verbindung mit den Huckepackplatinen ist mir ein scheinbarer Fehler 
in der Firmware aufgefallen, nämlich eine Querbeinflussung des DAC bei 
Kanal 3 und 4, was offenbar auf einen Überlauf zurückzuführen ist. Dreht 
man den Offset auf Kanal 3 über die Grenzen hinaus wird Kanal 4 
beeinflusst und anders herum.
Weiterhin passt die Kalibrierung derzeit noch nicht. Kanal 2 wird zwar 
für die 5er Bereiche abgeglichen, aber bei den restlichen Ablenkungen 
passt der Offset nicht, Kanal 3 und 4 bekomme ich gar nicht kalibriert. 
Da läuft irgendwo etwas erheblich schief.
Mit der Huckepackplatine ist es notwendig den DC-Offset für jeden Kanal 
in allen Vertikalablenkungen zu Kalibrieren. Die ADC-Kalibrierung kann 
bspw. in der höchsten Vertikalablenkung vorgenommen werden, da die 
GND-Kopplung in der originalen Bestückung an der falschen Stelle sitzt 
und mit Huckepackplatine verschwindet.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
branadic schrieb:
> Dreht man den Offset auf Kanal 3 über die Grenzen hinaus wird Kanal 4
> beeinflusst und anders herum.

Wie ist das gemeint mit beeinflussen? Ich kann das leider bei mir ohne 
die Platinen nicht nachvollziehen. Kannst Du das noch etwas genauer 
beschreiben?

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Wie ist das gemeint mit beeinflussen?

In dem ich Kanal 4 verschiebe, obwohl ich an Kanal 3 den Offset 
verstelle.

branadic

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das auch, und mir ist seit der Bestätigung durch branadic klar 
daß ich da wohl noch mal ran muß. Vorher dachte ich da wäre irgendwas 
marginal oder ein Hardwareproblem bei mir, und zwischenzeitlich hatte 
ich schon wieder vergessen daß das Problem noch ungelöst ist...

Merkwürdig ist das ich am DAC-Handling gar nichts gemacht habe und das 
es ohne neue Eingangsstufe nicht auftritt.

Jörg

Autor: christopher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jungs!

Ich habe ein 2 Kanal Welec - ohne irgendwelche Hardware-Modifikationen.
Kann ich die aktuelle Firmware auch ohne irgendwelche Huckepackplatinen 
benutzen?

Hab das mal ein wenig überflogen - ihr macht ja spitzen Arbeit!

Bin eher etwas "Einsteigermäßiger" unterwegs und würde es mich nicht 
trauen in dem Oszi herumzulöten. Bietet jemand von euch profis auch - 
natürlich bezahlte - umbauten an?

Allerbeste Grüße

Christopher

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christopher,

ja, du kannst die neuste Firmware auch mit einem unmodifizierten Welec 
nutzen.
Ein Umbau wird erwartungsgemäß wohl niemand für dich durchführen, nicht 
weil alle egoistisch sind, sondern vielmehr weil du die notwendige Zeit 
dafür nicht bezahlen könntest. Die Bestückung der Huckepackplatine, der 
Ausbau der obsoleten Bauteile und die Umrüstung samt Einbau der 
Huckepackplatine kosten wirklich gut Zeit.
Am Feedback allein siehst du ja, wie wenig Leute sich die Umrüstung 
schon angetan haben obwohl sie sich mit Material eingedeckt haben. 
Entsprechend wenig Erfahrung liegt hier in Verbreitung vor. Leider, muss 
ich zum Bedauern feststellen. Umgerüstete Geräte wirst du zur Zeit nur 
in der Entwicklergruppe (Skype) finden.

branadic

Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Hayo
What compiler do you use for Welec firmware update?
I have only an editor and looking for a free compiler to do small FW 
mods

Regards,
Sandro

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz vergessen zu erwähnen, Offset-Verschiebung und der dazugehörige 
Marker passen jetzt natürlich auch nicht mehr zusammen. Vielleicht 
findest du ja die Zeit dein 2-Kanal-Welec mal umzurüsten Hayo? Wenn die 
Unterstützung mal bis zum Ende implementiert wäre würden sicherlich auch 
mehr Leute ihr Welec umrüsten.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sandro

How to get and how to use the SDK (devopment kit) is described in the 
documents which You will find in the "doc" directory of my 
"distrubution".



@Branadic

Ja die Umrüstung wollte ich demnächst mal in Angriff nehmen, aber die 
Probleme mit Kanal 3+4 kann ich dann trotzdem nicht sehen.

Hatte übrigens vorhin ein nettes Treffen mit Jörg und wir haben einige 
Ideen für die weitere Entwicklung ausgetauscht. Könnte noch ganz 
interessant werden, zumal Jörg über einige berufliche Erfahrung verfügt 
die uns da recht nützlich sein könnte.

Gruß Hayo

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Hatte übrigens vorhin ein nettes Treffen mit Jörg und wir haben einige
>
> Ideen für die weitere Entwicklung ausgetauscht.

Ganz meinerseits!

Wir haben Pläne geschmiedet für einen Software-Neuanfang, der auch 
andere Plattformen (Leon und ganz vage Owon) ermöglichen soll. Dafür zu 
gegebener Zeit ein neuer Tread, bzw. zum Mitmachen einen 
Architekturentwurf im Sourceforge-Wiki.

Vielleicht gewinnen wir ja auch neue Entwickler damit, macht hoffentlich 
mehr Spaß als der alte Code.

Jörg

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da das ein etwas langfristigeres Projekt ist, wird die bisherige 
Firmware  natürlich solange parallel weiterentwickelt bis die Neue 
einsatzbereit ist, es wird also auch erst mal weiterhin Updates auf 
Basis der 1.2.BF.x.x geben.

Erstes Ziel der neuen Entwicklungslinie ist erstmal der Hardwarelayer 
und als Grundlage dafür die genauere Untersuchung bzw. Dokumentation der 
NIOS-Hardwareansteuerung.

Ich denke es wird interessant...

Hayo

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachdem ich die Opensource Firmware bisher nur genutzt habe, habe ich 
jetzt selbst etwas umgebaut bzw. hinzugefügt.

Ich habe in meinem Oszi schon länger einen Li Akku eingebaut, allerdings 
ohne irgendwie die Spannung, Strom oder Kapazität zu überwachen. Diesen 
Umbau habe ich jetzt erweitert: Als Schutz- und Überwachungselektronik 
habe ich die Standardkombination aus Notebookakkus bestehend aus MM1414 
(als Kurzschlussschutz, Über- und Unterspannungsüberwachung) und BQ2060, 
zum messen von Gesamtspannung, Lade-/Entladestrom, Berechnung von 
Kapazität etc.

Abgerufen werden die interessanten Daten vom BQ2060 (momentan nur 
Ladezustand) über einen extra Mikrocontroller und per UART an das Oszi 
übertragen. Da zeige ich diesen Wert jetzt einfach nur noch an. Momentan 
auf UI_Plane3 am Rand des Gitternetzes. Am liebsten würde ich diesen 
Wert aber neben die aktuelle Abtastrate schreiben, aber auf welches 
Plane muss ich dann schreiben?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst Textausgaben in die - Text_Plane - schreiben. Die wird dann je 
nach eingestelltem Layout auf die richtige UI_Plane umgebogen.

Das gilt für die üblichen Ausgabebereiche über und unter dem Grid bzw. 
bei FFT auch neben dem Grid.

Allerdings ist da neben der Abtastrate eigentlich kein Platz mehr. Du 
kommst dann mit anderen Textausgaben ins Gehege.

Gruß Hayo

Autor: Omega G. (omega) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe nur ein Zweikanal Gerät, also hab ich da etwas Platz.

Danke für die Hilfe, ich hätte nie die richtige Plane gefunden!

Im Foto liegen Kanal 1 und 2 genau übereinander, deshalb sieht man nur 
eine Linie.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nett gemacht :-)

helfe jederzeit gerne.

Gruß Hayo

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo mal wieder,
gerade habe ich etwas mit einem STM32F407 gespielt und dabei mal die 
neue "Logic" Funktion des Welec ausprobiert. Leider wurde das 6MHz 
Rechteck dabei zu einer Nulllinie, unabhängig vom gewählten Logikpegel. 
Kann man da irgendwas fehlbedienen oder klappt es bei schnellen 
Digitalsignalen nicht?
Ich war auch etwas verwundert, kein 3.3V CMOS in der Liste zu sehen.

Da ich die Funktion eine gute Idee für das Basteln an Digitalschaltungen 
finde, würde es mich freuen, wenn andere ihre Erfahrungen damit posten 
könnten.

Viele Grüße
Michael

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich muß zugeben, dass diese Funktionen bislang nur rudimentär getestet 
sind. Ich gelobe aber Besserung. Vor Weihnachten schaffe ich das nicht 
mehr, aber im neuen Jahr sollte das hinhauen.

Gruß Hayo

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe einen neuen Thread zu der werdenden neuen Firmware aufgemacht, 
hier der Link:
Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

(Bisher war ich damit noch sozusagen im "stealth mode", außer gegenüber 
Hayo und dem Skype-Chat.)


Jörg

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:

> Hallo mal wieder,
> gerade habe ich etwas mit einem STM32F407 gespielt und dabei mal die
> neue "Logic" Funktion des Welec ausprobiert. Leider wurde das 6MHz
> Rechteck dabei zu einer Nulllinie, unabhängig vom gewählten Logikpegel.

So ich hab doch noch mal zwischen Arbeit und Klamottenpacken getestet. 
Ich konnte da keine Auffälligkeiten feststellen. Als Beispiel mal 
Screenshots zur TTL und LVTTL-Familie.

> Ich war auch etwas verwundert, kein 3.3V CMOS in der Liste zu sehen.
Die Pegel sind kompatibel zu LVTTL, daher kein extra Eintrag.


> Da ich die Funktion eine gute Idee für das Basteln an Digitalschaltungen
> finde, würde es mich freuen, wenn andere ihre Erfahrungen damit posten
> könnten.
Ja, da stimme ich zu. Da ich auch nur begrenzt Zeit zum Testen habe 
würde ich mich über Rückmeldungen freuen.

Am besten mit Screenshots im Logic und Normalbetrieb und kurzer 
Beschreibung (Logicfamilie, Frequenz).


Gruß Hayo

p.s. es gibt noch vor meinem Winterurlaub eine Xmas Edition - vermutlich 
morgen.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael

Mir ist gerade eine Idee gekommen woran es liegen könnte!

Hast Du einen Tastkopf mit 10:1 Teiler verwendet? Das wird nämlich zur 
Zeit noch nicht unterstützt. Da geht bei der 5.0 leider nur 1:1.

Bei der Xmas Edition versuche ich das mit einzubauen, mal sehen ob ich 
das noch schaffe.

Gruß Hayo

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hayo,
danke für die Mühe - da ich einen 10:1 Tastkopf verwendet habe, hat sich 
das ganze damit wohl schon geklärt.

Ich bin gespannt auf deine Xmas Edition, noch mehr bin ich aber gespannt 
was aus dem von Jörg angestoßenen Neubau der Software von Grundauf wird.
Sehr vielversprechend und schon erstaunlich weit gediehen, wenn man 
bedenkt, dass der Thread erst ein paar Tage alt ist.

Gruß
Michael

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der Tat - und die Xmas Edition profitiert auch schon davon, denn ich 
habe die schnelle MSTEP Multiplikation die Jörg entdeckt hat schon mit 
eingebaut da Jörg so nett war mir die modifizierten Dateien für den 
Compiler zur Verfügung zu stellen.

Der Geschwindigkeitszuwachs ist nicht von schlechten Eltern und läßt 
schon ahnen was wir mit der neuen Firmware evtl, erreichen können.

Kleiner Performancevergleich vorher/nachher:

                   vorher       mit MSTEP    [frames/s]
-------------------------------------------------------
QM (3 Slots)       211           243
FFT 512            160           256
FFT 1024            65           146


Das betrifft natürlich auch alle anderen Funktionen bei denen ausgiebig 
gerechnet wird.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frohe Weihnachten und viel Spaß beim Spielen.

Die FIR und sin(x)/x Routinen sind zwar schon zum Teil implemetiert, 
laufen aber noch nicht so ganz rund, daher sind sie erstmal nicht aktiv. 
Mit dem LED test könnt Ihr ja unter dem Weihnachtsbaum für Stimmung 
sorgen...  ;-)

Bin dann ab morgen im Ski-Urlaub.

Gruß Hayo

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann:

Schönen Urlaub und vieeel Schnee!

Gruß, Guido

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke,

ich muß mal sehen ob es bei uns im Hotel einen Internetzugang gibt, 
ansonsten

frohe Weihnachten und guten Rutsch.

Gruß Hayo

Autor: Paolo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thanks a lot, Hayo you are, as usua, very generous and kind...
Have a nice christmas and a very happy new year!!

Regards, Paolo

Autor: Interessierter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich finde es ja sehr spannend was hier passiert und hab Interesse an dem 
DSO.
Kann mir denn jemand mal sagen wo man das Ding kaufen kann?
Gurgel und E... sind da nicht so auskunftsfreudig....

Autor: Luc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hayo, Jörg and guys all!

Hayo, thanks You very, very much for the free time You provided 
generously to us and for this new firmware's version!!!
I installed your latest great job, the new 1.2.BF.5.1XE and I tried it a 
bit.
As always I am speechless, RESPECT!!!
I believe also thanks to the integration of the Jörg's code (RESPECT 
also to Him and to all who are involved in the Welec Project) the new 
firmware is incredibly much fast and much more responsive now.
The LED's test idea is brilliant as so its implementation and since the 
upcoming Christmas' holiday can be used as Christmas tree! ;-)
I have seen that some item in some menu it was reduced and this 
streamlines the management.
Some item are instead deactivated (grey) and they will available in the 
future, I hope soon.
Reduced items in Hardware Menu works great for me (W2022A and W2012A) 
even if there are only two setting (Factory and High Frequency, all 
other are now grey deactivated), I used High Frequency setting without 
any spikes' problem.

As always only for knowledge and no for criticism, follow the report 
about some issue I noted:
1) [W2022A & W2012A] The memory management seems to me do not works, 
when I save a waveform in memory 1 and after a new one in the memory 2 
or other, then memory 1 is missed and there is only the last I saved.
2) [W2022A & W2012A] In the Quick Measures, the Fall Time recognized 
fail on channel 2, it seem to me to be calculated as half of the real 
value: channel 1 recognize right and very accurate values as compared to 
other master oscilloscopes I have and I used as champions instruments. 
(*)
3) [W2022A only] Sometime using the Cursors features get garbage on the 
screen, show corrupt labels and wrong values, but this issue was even in 
the former release.

I take this opportunity to wish to You Hayo, Jörg and all guys a Merry 
Christmas!
RESPECT!

Danke und Frohe Weihnachten!

Luc

(*)W2022A is strikingly higher to the W2012A as response time, I believe 
because it is really about 200MHz bandwidth by selected inner 
componentistic circuitry or anyway its inner components are better than 
the same in the W2012A version.

Autor: Krunoslav O. (kruno3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frohe Weihnachten!

Ich habe die Xmas Edition in mein W2022A geflasht und kurz getestet 
(Testsignal). Recht schnell im Vergleich zum Original. Die Filterung und 
Combi-Triggerung sind supper, Displayeinstellungen (Status/Mono-Beige) 
ebenso, usw.
Danke für die Arbeit!
Ich fand auch ein Paar bugs mit dem Trigger welche ich berichten möchte:
1) Beim wechseln zwischen Edge und Pulse Width wird der Trigger-Source 
nicht mitgenommen. Z.B. Extern bei PulseWidth und Source1 bei Edge, nach 
dem Mode-Wechsel.
Ist dass gewünscht?

2)Pulse Width Mode funktioniert nicht richtig. Mal funktioniert der < 
wie es soll(reagiert auf die Zeit-Grenzen), mal der >.
Der der jeweils andere triggert dann immer (unabhängig von der 
eingestelten Zeitlimits) oder nie. Der >< funktioniert nie. Meistens 
triggert er nicht.
Es sieht so aus als würde die beim anderen eingestellte Zeit (die 
inaktive Zeit), oder dessen Logik, ins Triggern mitwirken.

3)Der External Trigger triggert bei PulseWidth immer, unabhängig von den 
Zeiteinstellungen, eigentlich unabhängig ob es einen Signal hat oder 
nicht sehe ich gerade(im Normal Mode).
Wenn die Trigger-Logik wie PulseWidth bei dem Extern nicht geht, man 
sollte die Edge und PulseWidth Tasten sperren.

4)Nach dem wechseln des PulseWidth Modes < zum >, wird nicht getriggert 
bis man die Zeiteinstellungstaste druckt, egal wie die Zeit vorher war. 
Kleinigkeit für den Benutzer, wahrscheinlich schwer zu finden.

5)AutoScale braucht manchmal seeehr laaaangee (>30"). Zweimal passiert.

Verbesserungsvorschläge gibt es wahrscheinlich ein Haufen. Ich werfe ein 
paar dazu:
-beige Funktionstasten sind nicht so mein Geschmack (Vorschlag grau),
-der Oszi reagiert sehr träge auf die Drehschalter und bekommt den 
Winkel der Drehung nicht ganz mit. Ist sicher schwerer Brocken, aber 
stört auch am meisten.
-bei der Zeitbasis 1" wird der Verlauf am Display live gezeichnet, bei 
500ms muss man warten bis alles aufgezeichnet ist. Geht das bei den 
kleineren Zeiten nicht mehr?
-wenn der Verlauf gezeichnet wird, wird der noch ausstehende Teil als 
Nulllinie gezeichnet. Leer wäre besser (ich weiß, Klugsch.....).

Nochmals großen Dank an alle beteiligten und schönen Gruß aus Wien,
Kruno

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessierter schrieb:
> ich finde es ja sehr spannend was hier passiert und hab Interesse an dem
> DSO.
> Kann mir denn jemand mal sagen wo man das Ding kaufen kann?
> Gurgel und E... sind da nicht so auskunftsfreudig....

Such' mal bei Ebay nach den Verkäufer "welecgmbh". Zur Zeit tröpfeln die 
wieder Geräte dort ein, oder du fragst mal mit der Kontaktfunktion an. 
Mit einer normalen Artikelsuche ist das schwer zu finden, weil "Welec" 
dort nicht mit drin steht. Vielleicht dürfen die das aus irgendwelchen 
Gründen nicht.

@All: auch frohe Weihnachten!
Ich mache derweil weiter an der neuen Firmware, siehe dort:
Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

Jörg

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein frohes neues Jahr,

bin gerade wieder aus dem Urlaub zurück und noch dabei alles aufzuräumen 
- daher nur eine kurze Rückmeldung.


Luc schrieb:

> Some item are instead deactivated (grey) and they will available in the
> future, I hope soon.
I also hope...

> Reduced items in Hardware Menu works great for me (W2022A and W2012A)
> even if there are only two setting (Factory and High Frequency, all
> other are now grey deactivated), I used High Frequency setting without
> any spikes' problem.
There is only one setting working better in the HF-Range (But also with 
a little spike problem). All others have more problems or don't work, so 
I decided to throw them out.

Also I reduced the entries in the pre gain menu to the three important 
settings.

- Standard for all unmodified scopes (using gain 1.25)
- 24.9 Ohm for modified input stage equipped with two 24.9 Ohm resistors
  and one 150 Ohm resistors (replacing 0 Ohm and 150 KOhm resistors)
- Add-On PCB for the new input stage on its own PCB


> 1) [W2022A & W2012A] The memory management seems to me do not works,
> when I save a waveform in memory 1 and after a new one in the memory 2
> or other, then memory 1 is missed and there is only the last I saved.
I'm sorry but I can't reproduce the problem. On my scopes it is working 
without problems -> see screenshots.


> 2) [W2022A & W2012A] In the Quick Measures, the Fall Time recognized
> fail on channel 2, it seem to me to be calculated as half of the real
> value: channel 1 recognize right and very accurate values
I can't reproduce this also. See screenshot.


> 3) [W2022A only] Sometime using the Cursors features get garbage on the
> screen, show corrupt labels and wrong values, but this issue was even in
> the former release.
Yes I also had the problem, but couldn't reproduce it after restart. Do 
You know how to force it?

Kind regards

Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Krunoslav O. schrieb:

> 1) Beim wechseln zwischen Edge und Pulse Width wird der Trigger-Source
> nicht mitgenommen. Z.B. Extern bei PulseWidth und Source1 bei Edge, nach
> dem Mode-Wechsel.
> Ist dass gewünscht?
Nein, hatte ich noch nicht bemerkt, da der Pulsetrigger recht wenig in 
Gebrauch ist (wg. unten genannter Gründe)


> 2)Pulse Width Mode funktioniert nicht richtig.
Ja ist leider ein bekanntes Problem welches sich nicht so einfach 
beheben läßt da die Triggeransteuerung im FPGA eingebrannt ist. Ich 
hatte schon mal die Idee da einen Workaround in die Firmware 
einzuarbeiten. Evtl. läßt sich da mit der neuen Firmware und den von 
Jörg gewonnenen Erkenntnissen etwas machen.


> 3)Der External Trigger triggert bei PulseWidth immer, unabhängig von den
> Zeiteinstellungen, eigentlich unabhängig ob es einen Signal hat oder
> nicht sehe ich gerade(im Normal Mode).
Ist aus den gleichen Gründen etwas unausgegoren. Ich tendiere auch dazu 
den PW-Trigger bei externem Betrieb ganz raus zunehmen.

> 5)AutoScale braucht manchmal seeehr laaaangee (>30"). Zweimal passiert.
Das hängt von der Anzahl der aktiven Kanäle und dem Signal ab. Die 
Autoscalefunktion arbeitet sich Stück für Stück durch alle Zeitbereiche 
und Spannungsbereiche bis alles passt. Im ungünstigsten Fall müssen erst 
alle relevanten Zeitbereiche und dann alle Spannungsbereiche durchsucht 
werden -> läßt sich per Terminal schön nachvollziehen, da ich die 
Debuggausgabe dringelassen habe.


> Verbesserungsvorschläge gibt es wahrscheinlich ein Haufen. Ich werfe ein
> paar dazu:
> -beige Funktionstasten sind nicht so mein Geschmack (Vorschlag grau),
Ist von Agilent so kopiert. Wir haben leider auch nur eine sehr 
begrenzte Farbpalette.

> -der Oszi reagiert sehr träge auf die Drehschalter und bekommt den
> Winkel der Drehung nicht ganz mit. Ist sicher schwerer Brocken, aber
> stört auch am meisten.
Ja, das ist auch ein bekanntes Problem das zum Teil im FPGA verbockt 
wurde. In der neuen Firmware könnte das etwas besser werden, da Jörg für 
die Eventverarbeitung eine Eventqueue vorgesehen hat die das Ganze 
(hoffentlich) etwas flüssiger verarbeitet.

> -bei der Zeitbasis 1" wird der Verlauf am Display live gezeichnet, bei
> 500ms muss man warten bis alles aufgezeichnet ist. Geht das bei den
> kleineren Zeiten nicht mehr?
Mit der aktuellen Polling-Eventverarbeitung leider nicht. Da ist das 
Ende der Fahnenstange schon erreicht. Mit der neuen queuegesteuerten 
Verarbeitung könnte da noch was machbar sein, wir werden sehen.

> -wenn der Verlauf gezeichnet wird, wird der noch ausstehende Teil als
> Nulllinie gezeichnet. Leer wäre besser (ich weiß, Klugsch.....).
Das Ganze ist ein Ringpuffer, dh. irgendwann fängt sowieso das alte 
Signal wieder an. Dann ist da auch keine Nulllinie mehr.

Gruß und willkommen an Bord

Hayo

Autor: Krunoslav O. (kruno3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo
Danke für die Antwort, macht einiges klar. Das letzte Punkt (Ringpuffer) 
auch, wobei ich es als störend empfinde und von anderen DSOs nicht 
kenne.
Gerade beim zweiten Durchlauf kommt ein neues Signal über das alte und 
man muss u.U. genau schauen wo der neue endet und das alte beginnt.
Ist aber nicht so wichtig.
Gruß
Kruno

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Krunoslav O. schrieb:

> Gerade beim zweiten Durchlauf kommt ein neues Signal über das alte und
> man muss u.U. genau schauen wo der neue endet und das alte beginnt.
Die Stelle ist einfach zu finden - genau beim roten Pretriggermarker am 
oberen Bildrand. Der markiert nämlich im USTB-Modus den aktuellen 
Zeitpunkt - so wie beim normalen Modus eigentlich auch.

Der Grund warum der Puffer nach der Aufzeichnung nicht gelöscht wird ist 
der, dass man im Speicher scrollen kann und sich beliebige vergangene 
Zeitpunkte bis zum Ende des Puffers ansehen kann.

Beim Shift-Modus ist der Puffer vor dem aktuellen Zeitpunkt ja leer, da 
kenne ich das so, dass das Signal als Nulllinie dargestellt wird (wie 
beim Herzschlagmonitor z.B.).

Gruß Hayo

Autor: Stephan S. (outsider)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin nach einem Jahr endlich mal wieder mit festem Wohnsitz in 
Deutschland und hab mal die neue Weihnachtsedition aufgespielt um die 
Akkus zu testen die ich aus China mitgebracht habe. Dazu ne kleine Idee: 
wie wärs wenn man die Zeiten ab z.B. 100 s/DIV nicht mehr in s/DIV, 
sondern in min/DIV skaliert? Wer kann sich schon ohne laufend rum zu 
rechnen was vorstellen wenn der Entladevorgang eines Akkus 2600 s 
gedauert hat? Selbst wenn man das Oszi als Langzeitdatenlogger für 
beliebige andere Daten nimmt denke ich dass Minuten sinnvoller wären.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Luc schrieb:
> Hi Hayo, Jörg and guys all!
> As always only for knowledge and no for criticism, follow the report
> about some issue I noted:
> 1) [W2022A & W2012A] The memory management seems to me do not works,
> when I save a waveform in memory 1 and after a new one in the memory 2
> or other, then memory 1 is missed and there is only the last I saved.
Ok, I got it now! When I made some tests with TTL circuits I had the 
same effect as You. I will try to fix it soon. Thanks for reporting :-)


> (*)W2022A is strikingly higher to the W2012A as response time, I believe
> because it is really about 200MHz bandwidth by selected inner
> componentistic circuitry or anyway its inner components are better than
> the same in the W2012A version.
I agree with You. While I made my tests with TTL circuits I could also 
see a difference between my 2022A and my 2014A. The Bandwidth of the 
2022A seems to be really better. On the 2022A the overshots of the 
TTL-signal (20MHz) could be seen very good, while the 2014A did not 
display them.

Hayo

Autor: Warhawk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich hab ein kleines Problem bei meinem W2022A mit dem Triggern auf einen 
Fankenwechsel. Ich verwende aktuell die Firmware 1.2.BF.5.1XE (per 
Ramloader hochgeladen)

Ich will einfach nur auf eine steigende Flanke von 0V auf 3V triggern.
Eingestellt habe ich bei Horizontal den Modus "Main" und eine 500ms 
Auflösung.

Der Trigger ist bei Edge auf positive Flanke, Source 1, PreTrigger 
200ms, eingestellt. Im Triggermenü Mode steht im Mode auf Normal, 
Coupling DC, Trigger Level 1.5V, Holdoff 100ms.

Wenn ich jetzt ein 1Hz Signal am Eingang anlege, triggert das Oszi 
nicht.
Die angezeigt Linie bleibt weiterhin auf 0V.
Stell ich die Horizontale-Auflösung des Oszi auf 1s ein, wechselt es 
automatisch in den Roll-Modus und ich kann das Signal sehen.

Hab ich irgend eine Einstellung vergessen oder kann es sein das mit 
meinem Oszi was nicht stimmt. (Das Oszi ist neu).

Vielen Dank für eure Hilfe.

Autor: Michael D. (mike0815)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Warhawk,

ich habe mich gerade dazu entschlossen die X-Mas Edition aufzuspielen 
und mal eben deine Einstellungen mit einem 1Hz Rechteck getestet.
Schau mal oben im Screenshot, ob diese mit deinen identisch sind.
Bei 200mS wird ca. alle 7Sec. getriggert, wie man an den LED's sehen 
kann.
Ab 1S Timebase kommst du automatisch in den USTB-Modus (Ultra slow 
Timebase), deswegen der Rollmodus, sonst würde man warscheinlich sehr 
lange warten müssen, bis sich auf dem Bildschirm was tut.
Im 2. Shot bin ich mal auf eine Sekunde gegangen.
Hast vorher ein Default-Setup gemacht?

Gruß Michael

Autor: Warhawk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

vielen Dank. ich hab nochmal die Defaults geladen und dann ging es.

Nach dem Aufspielen der Firmware hatte ich aber schonmal die Defaults 
geladen und die ADC Offset kalibiert.

Keine Ahnung warum es nicht ging, aber hauptsache es geht jetzt ;-)

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann ist ja alles gut.
Es kann sein, wenn das DSO zickt, man mehrmals Default-Setup drücken 
muß. Vielleicht wird auch nicht immer alles zurück gesetzt, wie auch 
immer...
Ich klatsch mir die Updates immer gleich ins Flash, denn wenn das Teil 
einfriert, komme ich um ein neues Einspielen eh nicht rum!

Btw.
Bis ich beim "Holdoff" auf 100mS angekommen bin, hab' ich mir einen Wolf 
gekurbelt!
Könnte man beim schnelleren Drehen des Enkoders nicht grössere 
Zeitsprünge implementieren?

Gruß Michael

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Warhawk schrieb:
> Keine Ahnung warum es nicht ging, aber hauptsache es geht jetzt ;-)

leider funktioniert es aber doch nicht. Warhawk hat da eine vollkommen 
richtige Beschreibung geliefert!
Ich habe in den letzten Wochen versucht mal ganz einfach mit meinem 
W2024A zu arbeiten. Oft wusste man nicht, ob das Signal, welches gerade 
mit einem simplen Flankentrigger untersucht wurde nun wirklich nicht da 
war oder ob nur das Oszi hing!!
Diese Hänger treten auf, wenn mann z.B. den Trigger zwischen den 
Eingängen umschaltet oder zwischen Normaltrigger und Combitrigger 
wechselt oder z.B. mal einen Singleshot benötigt. Ich denke, das rührt 
daher, das die Triggereinstellungen teilweise nicht vollständig oder in 
der Firmware an verschiedenen Stellen gesetzt werden und so diverse 
Einstellungen unbeabsichtigt nicht durchgeschalten werden.

Das beeinträchtigt leider den Spaß an der Freude sehr!

Grüße
Jürgen

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen schrieb:
> Ich habe in den letzten Wochen versucht mal ganz einfach mit meinem
> W2024A zu arbeiten. Oft wusste man nicht, ob das Signal, welches gerade
> mit einem simplen Flankentrigger untersucht wurde nun wirklich nicht da
> war oder ob nur das Oszi hing!!
> Diese Hänger treten auf, wenn mann z.B. den Trigger zwischen den
> Eingängen umschaltet oder zwischen Normaltrigger und Combitrigger
> wechselt oder z.B. mal einen Singleshot benötigt. Ich denke, das rührt
> daher, das die Triggereinstellungen teilweise nicht vollständig oder in
> der Firmware an verschiedenen Stellen gesetzt werden und so diverse
> Einstellungen unbeabsichtigt nicht durchgeschalten werden.

An dieser Stelle komme ich als nächstes mit der neuen Firmware an. 
Kanaleinstellungen und Offset kann ich mittlerweile, nun kommt Capturing 
und Trigger dran. Wird spannend, was ist wirklich in der Hardware 
kaputt, was in der alten Software, was läßt sich durch Workarounds noch 
hinbiegen, was nicht?
Dieses Arbeitspaket stelle ich mir aufwändiger vor als die bisherigen. 
Wir werden sehen...
Mit der kleinen schlanken Osoz-Firmware (Arbeitstitel) läßt sich 
jedenfalls schön schnell testen. Ein Download in das Gerät dauert 
derzeit 13 Sekunden, und selbst das liegt hauptsächlich an Zeichensätzen 
und Icons, die alle schon drin sind.

Jörg

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,
das hört sich alles sehr interessant an, was du da baust!
Vielleicht gibst du uns mal eine kleine, kompilierte Kostprobe für's RAM 
zum testen? Ist schon spannend...

Gruß Michael

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> Vielleicht gibst du uns mal eine kleine, kompilierte Kostprobe für's RAM
> zum testen?

Gern aber was soll diese Kostprobe denn tun?
Ich arbeite mich von unten hoch, baue einen Layer der die 
"Infrastruktur" des Gerätes in geordneter Weise zugänglich macht. Auf 
diesem Plattformlayer  setzt die Applikation dann auf.
Ist also maximal undankbar, bzw. understatement: nichts von dem wird 
nachher sichtbar sein, aber es macht die eigentliche Arbeit.

Natürlich tun die Programme, die ich da so reinlade schon etwas: es ist 
jeweils spezieller Test-Code für den Plattformlayer, mit dem ich z.B. 
Wertebereiche durchfahre, Geschwindigkeiten messe, Randbedingungen teste 
usw. Man soll sich ja später auf den Unterbau verlassen können.
Es gibt da halt nur recht wenig zu sehen.

Grüße,
Jörg

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits,

bin momentan etwas busy und daher nicht so oft in unserer Sache aktiv. 
Hier eine Korrektur des Flashproblems das Luc entdeckt hatte. Das neue 
CPU Timing welches ich nach Jörgs Forschungsergebnissen eingebaut hatte 
brachte die Flash-Schreibroutinen etwas durcheinander. Das ist jetzt 
wieder korrigiert. Weiterhin habe ich das Timing des USB-Host Interface 
angepasst, da dieses ebenfalls dadurch beeinflusst wird.

GRuß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab noch ein paar Fehler gefunden - die C3 gibt es morgen.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So hier die versprochene C3 in der ich keine Auffälligkeiten mehr finden 
konnte.

Gruß Hayo

Autor: Luc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hayo and guys all!

Hayo W. schrieb:
>So hier die versprochene C3 in der ich keine Auffälligkeiten mehr finden
>konnte.

Hayo, as always you are right and all troubles are gone: RESPECT!!!!!!!
Really impressive, no words, W2012A and W2022A both works like a charm, 
I have not noticed any problems!
The oscilloscopes work fine, really fast and responsive.
Now I am little hurry, however thank you very much Hayo, Jörgs and all 
who are involve in the Welec project.
Last but no least, the logics trigger are awesome, really terrific!

Vielen Dank!!!!!!!

Mit freundlichen Grüßen,

Luc

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier die C4 mit dem angepassten Timing für das USB-Host Interface.

Hayo

Autor: Letschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Muss man etwas spezielles beachten, wenn man die aktuelle Firmware an 
"unmodifizierten" Geräten im originalzustand verwendet?

Gruß
Letschi

Autor: wailer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo Sorry, but where I find the files Functions.txt Special?
Thanks so much for your work.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Letschi

Nein, die Firmware unterstützt in erster Linie originale Geräte und 
zusätzlich auch noch einige Hardwaremodifikationen. Wenn Du ein normales 
W20xxA hast kannst Du das also problemlos draufspielen. Bitte beachten, 
dass das nicht mit dem originalen Firmwareloader von WELEC geht. Hierfür 
entweder den WELEC-Updater von Markus nehmen oder besser das 
Perl-Skript. Anleitung findet sich im "Docs" Verzeichnis.


@wailer

You will find it in the "Docs" directory!




Hayo