mikrocontroller.net

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


Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

: Gesperrt durch Admin
Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das heißt du könntest nur die Kompressionsroutine übernehmen?

Eigentlich ja, aber das Coding von Falk ist doch ziemlich "kompakt" 
geschrieben und daher nicht ganz einfach nachzuvollziehen. Es gibt auch 
noch einige weitere Änderungen die ich dann anpassen müßte.

Ich hatte mir das schon mal angesehen, aber dann doch keine Zeit/Lust 
gehabt.
Vielleicht baue ich das demnächst trotzdem mal um.

>>Hayo W. schrieb:
>> Was ich mir vorstellen könnte wäre, dass abhängig von der Auswahl BF/OS
>> die Buttons eine jeweils eigene Beschriftung und Funktion haben

>Gute Idee! Bekomme ich dann den 5. Soft-Button als "Save to USB"?

Klar kein Problem. Ich vermute mal nur für die OS-Version solange ich 
die Kompressionsroutine noch nicht upgedatet habe?

Die Funktion die hinter dem Button steckt würdest Du dann zur Verfügung 
stellen?

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Die Funktion die hinter dem Button steckt würdest Du dann zur Verfügung
> stellen?

Na klar!

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versuche mal das zum nächsten Release vorzubereiten, für die 
Funktion mach ich Dir dann einen leeren Methoden-Body.

Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, danke.

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe nur ich ein Problem beim Norm-Trigger vom W2024 Ch3/4?

Mit der FW 2.9.C2 W2024 beobachte ich folgendes Problem: Ein normaler 
Edge-Trigger auf Kanal 3 bzw. 4 funktioniert bei Umschaltung der TB nur 
in jeder zweiten Stellung, also z.B. bei ... 20, 5 und 1 us/div kommt 
der Trigger durch und bei ... 10, 2 und 1 us/div kommt er nicht durch.

Dagegen hilft: Run/Stop auf 'Stop' und wieder auf 'Run'. Dann geht's auf 
den anderen Stufen, als ob dabei irgendetwas wesentliches wieder richtig 
gesetzt wird. Trigger auf Ch1/2 tut's immer.

Hat jemand eine Idee oder ist das ein (bekanntes?) FPGA-Problem?

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast recht, bei mir ist das auch zu beobachten. Ich kümmere mich 
darum.

Danke für den Tip

Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir tritt das nur bei Zeitbasen von 5ms bis 500ms auf. Hat hier 
jemand andere Erkenntnisse?

Das Problem müßte eigentlich auch bei älteren FW-Versionen auftreten. 
Muß ich nochmal prüfen.

Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, Problem ist behoben.

Hayo

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Ok, Problem ist behoben.

Klasse, hatte gerade alles von 2 ns/div bis 200 ms/div durchprobiert - 
trat überall auf. Aber du warst schneller.

Danke
Rainer

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

Bewertung
0 lesenswert
nicht lesenswert
Die 2.10 ist zwar noch nicht fertig, aber Du kannst ja mal bei diesem 
Vorabrelease prüfen ob das Problem bei Dir noch auftritt. Bei mir war 
alles ok.

Es ist auch schon die zusätzliche manuelle Triggerung via Single-Button 
und die Hardwareunterstützung des LTC 2602 drin.

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,
nächstes Problem:
Ich muss auf ein (beliebiges) Zeichen vom UART warten.
Dazu habe ich eine globale Variable angelegt die in der 
Hardware::ISR_UART() auf 1 gesetzt wird. Die Abfrage sieht dann einfach 
so aus:
rx=0;            //Globale Variable zurücksetzen
while(!(rx));    //Warte bis sie von der ISR gesetzt wird
rx=0;            //Wieder zurücksetzen (eigentlich hier unnötig)

Gibt es da eine elegantere Möglichkeit oder kann das so bleiben? Ginge 
auch eine Abfrage von  puart->np_uartstatus und puart->np_uartrxdata?

Das beliebige Zeichen ist zur Zeit ein Leerzeichen (0x20). Besteht die 
Gefahr dass ich damit etwas durcheinanderbringe?

Mfg,
Kurt

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Die 2.10 ist zwar noch nicht fertig, aber Du kannst ja mal bei diesem
> Vorabrelease prüfen ob das Problem bei Dir noch auftritt. Bei mir war
> alles ok.

Der Trigger über Ch3/4 scheint zu funktionieren.
Aber ganz weit bin ich mit Testen nicht gekommen, weil die Kiste jetzt 
sehr gerne total einfriert. Bis auf Softkey-Reset geht dann gar nichts 
mehr.

Gruß
Rainer

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

Bewertung
0 lesenswert
nicht lesenswert
Sorry,

hatte vorhin quick & dirty die Sache ausprobiert und dabei eine 
Endlosfalle mit eingebaut. Jetzt ist da ein Timeout drin und alles 
sollte gut sein.


@Kurt

Wenn Du das so machst, steht die ganze Kiste bis was vom UART kommt. Und 
wenn nix kommt, hast Du das Gleiche wie ich vorhin!

Also entweder einen Timeout einbauen, oder besser nur mit if() abfragen, 
denn dann kann die Hauptschleife weiterlaufen und die Abfrage wird 
jedesmal gemacht.

Hayo

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> hatte vorhin quick & dirty die Sache ausprobiert und dabei eine
> Endlosfalle mit eingebaut. Jetzt ist da ein Timeout drin und alles
> sollte gut sein.

Hajo, da kommt noch kein weißer Rauch.
Irgendwie scheint die Falle immer noch drin zu sein. Nur manchmal 
(etliche Sekunden) kommt die Bedienung durch, so dass man eine Chance 
hat die TB zu verstellen. Nix mit locker durchdrehen ...

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Rainer,

gib mir mal ein paar Details zu den verwendeten Einstellungen 
(Hardwaremenü, TB, aktive Kanäle, Spannungsbereich), denn bei mir lief 
das irgendwie problemlos.

Gruß Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
So - hab nochmal eine kleinigkeit geändert, damit die Bedienung bei 
Zeitbasen mit langer Abtastzeit etwas flüssiger wird. Bitte 
berücksichtigen, dass aber grundsätzlich das Ganze ab 20ms an aufwärts 
etwas langsamer wird, und damit auch die Reaktionsgeschwindigkeit auf 
das Human Interface.

Gruß Hayo

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hayo,

mmh, keine besonderen Einstellungen:
- Default Setup
- Trigger Norm, Ch.4 rising Edge, Level 2.5 V
- TB um die 1us/div, sofern machbar ;-)
- Signal: 5V Einzelpulse 1us auf Ch.4

Problem scheinen die Einzel-Events zu sein. Dabei verfängt das DSO sich 
gerne. Wenn ich aber statt dessen nach einem Soft-Reset das Probe Comp 
Signal dran habe, läuft alles.

Gruß
Rainer

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

Bewertung
0 lesenswert
nicht lesenswert
Noch einer!

Ich habe jetzt einen völlig anderen Lösungsansatz gewählt. Die Bedienung 
wird dadurch flüssiger und ich hatte auch keine Aussetzer bei meinen 
Tests. Diese Variante gefällt mir bislang am besten.

Probierts doch bitte mal aus.

Hayo

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Probierts doch bitte mal aus.

Signal: Probe Comp an Ch1, Einzelpulse an Ch4

Die Hänger sind in der 2.10.Pre4 weg, aber wenn Trigger auf Ch4 steht 
und ich die TB langsamer mache, kommen ab 10us/s bei Einzelpulssignal 
kein Trigger mehr durch, d.h. 2ns/div ..5us/div geht, 10us/div ... geht 
dann nicht mehr. Allerding: Wenn ich dann bei z.B. 20us/div auf 
Ch1-Trigger schalte (Erfassung läuft wg. Ch1.Signal) und wieder zurück 
auf Ch4, funktioniert auch Trigger auf Einzelpulse wieder, solange ich 
nicht von 5us/div auf 10us/div umschalte.

Wird an dieser Grenze irgendetwas Grundlegendes geändert?

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja zwischen 10µs und 5µs wird anscheinend die Betriebsart der ADC 
umgeschaltet, denn bei 5µs werden 16k Werte gesampelt und ab 10µs sind 
es dann nur noch 4k.

Genauer kann man das in der Programmers Reference sehen auf dem Reiter 
"Timebase Table".

Allerdings tritt das Problem bei mir nicht auf, außer ich wähle das 
Signal zu klein kleiner als ein Div hoch. Dann setzt der trigger schon 
mal aus. Aber sobald das Signal größer ist läuft alles ohne Aussetzer.

Können die Anderen hier das auch mal testen bitte? Nicht das ich der 
Einzige bin bei dem es keine Aussetzter gibt.

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> @Kurt
>
> Wenn Du das so machst, steht die ganze Kiste bis was vom UART kommt. Und
> wenn nix kommt, hast Du das Gleiche wie ich vorhin!
>
> Also entweder einen Timeout einbauen, oder besser nur mit if() abfragen,
> denn dann kann die Hauptschleife weiterlaufen und die Abfrage wird
> jedesmal gemacht.
>
> Hayo

Den Timeout mit if() habe ich schon drin, oben war nur ein (zu) stark 
verkürztes Beispiel. Sorry.

Es ging mir nur darum ob die Sache mit der globalen Variablen so in 
Ordnung ist oder man es besser machen kann.

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Allerdings tritt das Problem bei mir nicht auf, außer ich wähle das
> Signal zu klein kleiner als ein Div hoch.

An der Signalhöhe liegt es definitiv nicht (2,5 div und TL ca. 50%). Ich 
kann auch reproduzierbar zwischen 5 und 10us/div umschalten, Trigger Ch4 
mit Einzelpuls kommt nur bei 5us/div durch, dto. die 
rote/Ch4-Trigger-LED. Bei 10us/div rauscht nach gefühlten 30 s ein Puls 
durch (Spike auf Ch4) und dann triggert das DSO auch wieder aufs 
Einzelsignal.

Hilft das?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Prinzip mache ich das auch so mit globalen Flags. Allerdings solltest 
Du bei globalen Variablen den Namen möglichst sprechend wählen - z.B. 
USB_rx_flag oder USB_rx_request oder so, Dann wird das etwas 
übersichtlicher und besser lesbar.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rainer

Ich hatte etwas schwierigkeiten Deinen Fall nachzustellen, hab es aber 
jetzt hingekriegt. Die Pulse müssen schon sehr langsam kommen damit das 
Problem auftritt (1 Puls pro Sekunde).

Aber dann passiert es bei mir auch wie beschrieben. Mal sehen ob ich die 
Ursache lokalisieren kann.

Gruß Hayo

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Die Pulse müssen schon sehr langsam kommen damit das
> Problem auftritt (1 Puls pro Sekunde).
Tun sie, ich löse die von Hand aus.

Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf 
10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es 
sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft, der 
eigentlich hätte auf 0 gestellt werden müssen?

Gruß Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf
> 10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es
> sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft, der
> eigentlich hätte auf 0 gestellt werden müssen?

Keiner den ich benutze, aber es ist schon mal ein Ansatz für die Suche.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zück schon mal den Lötkolben, Hayo. Die Leiterplatten gehen heute noch 
in den Postkasten.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na Du bist aber fix. Da passt das ja das heute meine Lötstation gekommen 
ist.

Gruß Hayo

Autor: Charly B. (charly)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
moin moin Hayo,

hier was fuers Wochenende, hat mich ein paar stunden suche
gekostet obwohl meine Soft 'unschuldig' war

was du auf dem Bild siehst ist ein SYMETRISCHES Signal,
nur das Oszi zeigt was anderes, irgendwie als waehre dein
Puffer zu kurz oder wird ueberschrieben, oder ?

FW = BF2.8

vlG
Charly

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Charly, Hayo

Der am rechten Rand dargestellte Datenmüll stammt zeitlich aus einem 
anderen Bereich des Signals und taucht am rechten Rand immer auf, wenn 
das Fenster mit der Horizontalverschiebung ganz nach Rechts geschoben 
ist, d.h. am Ende der gesampleten Daten liegt. Horizontalregler a bissl 
nach links drehen und schon ist es nicht mehr zu sehen ;-)

Schönen Sonntag

Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Is ja'n Ding. Das war mir noch nicht aufgefallen. Muß ich mal 
ausprobieren.

Wegen der Triggeraussetzer auf Kanal 3 + 4 bin ich leider auch nicht 
weitergekommen. Ich denke aber dass es sich eher um ein minder 
priorisiertes Problem handelt oder?

Ich habe erst mal am Quick Print Menü weitergemacht, was schwieriger war 
als ich dachte, da ich (eigentlich wie immer) auf Altlasten in der 
Menüsteuerung gestoßen bin. Jetzt hab ich da aber aufgeräumt und alles 
ist gut. Ich werde nachher mal die fertige 2.10 hier hochladen.

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Ich habe erst mal am Quick Print Menü weitergemacht

Super,

ich werde die später meine neuen Funktionen schicken:
UC_rle_enc(...)
UC_SCREENSHOT_BW()
UC_SCREENSHOT()
UC_DUMPCSV()

Mfg,
Kurt

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Is ja'n Ding. Das war mir noch nicht aufgefallen. Muß ich mal
> ausprobieren.

Mit einem Sägezahnsignal läßt sich vielleicht am einfachsten klären, wo 
die Mülldaten herkommen.

> Wegen der Triggeraussetzer auf Kanal 3 + 4 bin ich leider auch nicht
> weitergekommen. Ich denke aber dass es sich eher um ein minder
> priorisiertes Problem handelt oder?

Das denke ich auch. Die W2022 Nutzer haben sowieso nur 2 Kanäle zum 
Triggern und die Frontend-Front lauert ja auch noch auf Einbindung der 
Chip-Ansteuerung.

Gruß
Rainer

Autor: Mirko B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wegen der Triggeraussetzer auf Kanal 3 + 4 bin ich leider auch nicht
> weitergekommen. Ich denke aber dass es sich eher um ein minder
> priorisiertes Problem handelt oder?

>>Das denke ich auch.

Sehe ich anders. Für mich hat das zuverlässige Funktionieren der 
Elementarfunktionen (z.B. Triggerung) oberste Priorität. Der Oszi ist ja 
immerhin ein Messmittel und ich möchte ihn auch so einsetzten (und mich 
drauf verlassen!).

Ich will hier aber keinem den Spaß verderben, Hayo soll das machen, was 
er am spannendsten findet (aber solche lästigen Bugs bitte nicht 
vergessen).

Da wir schon mal dabei sind - vielen Dank an alle, die hier ihre Zeit 
investieren!!


Viele Grüße,

Mirko

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

na dann bin ich gespannt auf die 10er. Mal eine kurze Frage am Rand, 
woran erkenne ich dann in der neuen Firmware, dass der DAC auch richtig 
unterstützt wird?
Ich hab den heutigen Tag genutzt meine DACs auszutauschen und zugleich 
meinen Kanal 4 etwas frei zu machen, damit die Huckepackplatine Platz 
findet.

branadic

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

Bewertung
0 lesenswert
nicht lesenswert
So, der Reihe nach:

- @Charly -> das Datenmüllproblem habe ich eben noch beseitigt.

- @Mirko -> ja ist irgendwie ärgerlich, aber wenn man einen 
zuverlässigen Trigger braucht muß man eben Kanal 1 oder 2 nehmen. 
Vielleich stoße ich noch auf eine Lösung.

- @Kurt -> alles klar, ich habe Dir eine leere Methode gebaut, die 
angesprungen wird wenn der USB-Button gedrückt wird. Zur Zeit gibt sie 
nur einen Text auf dem Terminal aus. Du Findest sie in der commif_t.cpp 
ganz am Ende -> void CommIF::Save2USB(void)

- @Branadic -> tja entweder funktioniert es mit dem 16 Bit DAC - oder 
nicht. Kann sein das ich den Registerwert noch um zwei Bit verschieben 
muß, das muß ich aber noch ausprobieren. Zur Zeit kann ich das ja leider 
noch nicht testen. Wenn Du umschaltest auf 16 Bit werden die drei 
anderen Kanäle sich nicht mehr verstellen lassen. Wenn es gut Läuft geht 
dann aber der Kanal 4.

Ansonsten einfach bescheid sagen, dann ändere ich das.

Zur 2.10:

- Es gibt jetzt zwei unterschiedliche Quick Print Menüs für OS und BF. 
Die Umschaltung erfolgt wie gehabt.

Gruß Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,
hier sind die geänderten Dateien. Ausgangsbasis war die 2.9_C2

Mfg,
Kurt

Jetzt warst du schneller. Mal sehen was du angestellt hast. ;-)

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht doch schon gut aus!
Aber wäre nicht ein eigener Eintrag im Screenshot-Versions Softbutton 
besser?
Und dann die 3 linken Softkeys wie in der OS-Version (Color, BW, CSV).

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Kurt,

ich hatte Dich in Deinem Post neulich so verstanden, dass Du da an der 
freien Stelle einen Button für den USB-Transfer hinhaben wolltest.

Hab ich Dich da falsch verstanden?

Wir können das natürlich noch ändern bei Bedarf.


Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

nach dem Umstellen des DAC auf LT2602 verschwinden bei Kanal 1 und 3 die 
Signale irgendwo außerhalb es Bildschirmes, Kanal 2 bleibt an gleicher 
Stelle.
Auch ein Calibrate DAC bringt die Signale für Kanal 1 und 3 nicht 
zurück.

Veränder ich nun die Position von Kanal 2 durch Drehen am Knopf, was ja 
in einer Änderung des DAC-Wertes resultieren sollte, bleibt das Signal 
an selber Stelle, aber das Kanal-Zeichen inkl. des Pfeiles (linker und 
rechter Bildschirmrand) wandert. Tut also noch nicht wie gewünscht.

branadic

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann sein dass ich mich da etwas undeutlich ausgedrückt hatte.
Das Dateiformat in dem gespeichert wird kann ich auf meinem µC 
einstellen.

Aber für die Art der Datenübertragung (Farbe, S/W, CSV) bauche ich je 
einen eigenen Softbutton.

Ich könnte zwar meine UC_ Funktionen mit den OS_ Funktionen 
zusammenlegen (die sind im Prinzip kompatibel, nur die RLE unterscheidet 
sich) aber das halte ich in der Entwicklungsphase nicht für sinnvol.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann baue ich das nochmal um und spendiere Deiner Funktion ein 
eigenes Menü.

Gruß Hayo

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hayo,

Hayo W. schrieb:
> Rainer W. schrieb:
>> Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf
>> 10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es
>> sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft...?
>
> Vielleich stoße ich noch auf eine Lösung.

Der Trigger läuft ja schon zuverlässig. Man hat "nur" die Totzeit nach 
der TB Umschaltung 5->10us. Falls an meiner etwas kühnen 32-Bit 
Vermutung etwas dran ist, wären das z.B. 34,4 s bei 125 MHz. Nur mal so 
ins Blaue gedacht...

Hayo W. schrieb:
> - @Charly -> das Datenmüllproblem habe ich eben noch beseitigt.

Kann es sein, dass da immer noch ein einzelnes falsches Datenwort am 
Ende mit ins Display rutscht? Sieht bei mir so aus...

Gruß
Rainer

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

Bewertung
0 lesenswert
nicht lesenswert
Jetzt noch 2 (optische) Kleinigkeiten:
In OS_SCREENSHOT_BW(void) und UC_SCREENSHOT_BW(void) muss die UI_Plane1 
noch mit in das Array. Also:
unsigned long *planes[] = {
    UI_Plane1, UI_Plane2, UI_Plane5, // UI_Plane3, UI_Plane4
    Channel_Plane1, Channel_Plane2, Channel_Plane3, Channel_Plane4,
    Channel_Math_Plane,
    Memory_Plane1, Memory_Plane2, Memory_Plane3,
    Marker_Plane1, Marker_Plane2,
    Grid_Plane,
    NULL
  };

In der UI_Plane1 scheint auch noch ein Fehler beim Zeichnen der 
Umrandung des rechten Softbutton zu sein. Auf dem Bild im Anhang sieht 
man dass die Umrandung nicht geschlossen ist.

Autor: Charly B. (charly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Hayo,
hab grad die neue Ver. eingespiel, werd heut mal testen...

aber 2 neue Fehler / 'Unschoenheiten'

1. ab einer TB >1ms muss man f. manuelles triggern im Single
mode die Single Taste mehrmals druecken ;(

2. der Pretrigger Wert wird beim langsamen durchdrehen der TB
nicht aktualisiert

vlG
Charly

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hayo

Rainer schrieb:
> Kann es sein, dass da immer noch ein einzelnes falsches Datenwort am
> Ende mit ins Display rutscht? Sieht bei mir so aus...

Das was da auf dem letzten Pixel noch zu sehen ist, stammt wohl vom 
Noise-Filter bei Einstellungen "smooth" oder "strong".

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kurt

baue ich mit ein.


@Charly

Stimmt, ist in Arbeit. Sollte in der nächsten Version behoben sein.


Danke für die Rückmeldung

Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo, hast du meine Meldung bezüglich der DACs gesehen? Scheint in den 
letzten Postings der anderen User irgendwie untergegangen zu sein.

brandic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi branadic,

sorry, der Post war tatsächlich etwas an mir vorbeigerauscht. Bin 
momentan immer noch etwas in Stress hier beim Rollout meines Projektes.

Welchen Kanal (bzw. Kanäle) hattest Du denn nun auf 16 Bit umgerüstet?

War das nicht Kanal 4?

Übrigens ist heute Deine Sendung bei mir angekommen - danke!

Muß mal sehen wann ich das einbauen kann, da muß man sich ja schon etwas 
Zeit für nehmen.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

da es sich bei dem DAC um einen DUAL DAC handelt werden pro gewechseltem 
DAC also auch zwei Kanäle in Mitleidenschaft gezogen (Kanal 1 + 2 und 
Kanal 3 + 4). Ich habe bei mir beide DAC gewechselt, demzufolge sind 
alle 4 Kanäle davon betroffen.
Da ich aber an meinem Kanal 4 etwas aufgeräumt habe, um Platz für die 
Huckepackplatine zu machen, kann ich dir nicht sagen was jetzt dort 
genau passiert.
Schön das die Sendung schon eingetroffen ist, dann kann es ja bald mit 
der Implementierung losgehen. Das freut mich.
Ein wenig Zeit wird man sicherlich brauchen, aber die größte Last, der 
Aufbau einer Leiterplatte, wurde dir ja schon abgenommen ;)

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es bei Dir momentan noch nicht funktioniert werde ich Dir bei 
Gelegenheit mal eine modifizierte Version bauen. Bin aber momentan echt 
im Streß, da ich ab morgen für den Rest der Woche eine Schulung gebe und 
mich auch noch vorbereiten muß.

Gruß Hayo

Autor: Charly B. (charly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:

> @Charly
>
> Stimmt, ist in Arbeit. Sollte in der nächsten Version behoben sein.

Danke Meister ! <tiefes verbeugen>

& viel erfolg bei der schulung, und hoffentlich haste keine
mit 'Teflonpfannenkopf' dabei :)

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, bin gerade nach Hause gekommen - und was finde ich im Briefkasten? 
Post von Linear Technology! Die Jungs haben mir doch tatsächlich zwei 
LTC2602 als kostenloses Sample geschickt und das ziemlich zügig.

Danke noch mal für den Tip!

Schade, dass ich momentan überhaupt keine Zeit habe etwas zu basteln. 
Naja, muß halt noch etwas warten.

Gruß Hayo

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi

mir ist gestern ein fehler in den math-funktionen aufgefallen.
messen wollte ich die restwelligkeit einer gleichspannung (8V). da sich 
an dem messpunkt noch ein welliger spannungsabfall (1Vpp) von einem 
shunt hinzu addiert, wollte ich diesen mit der CH1-CH2 funktion 
herrausrechnen.
beide kanäle waren dabei im 5V messbereich und die referenzlinien in der 
bildschirmmitte.
die überlagerte spannung vom shunt wurde zwar korrekt herraus gerechnet, 
allerdings stimte die skalierung des ergebnisses nicht. die 
ergebnisslinie lag nicht wie erwartet bei 8V sondern irgendwo bei 11V.

gruß sunny

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte nochmal an die Sammelbestellung für die Bauteile der 
Huckepackplatine erinnern. Die Frist endet Freitag Abend.

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


Mfg,
Kurt

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

bin wieder mal gerade erst zu hause angekommen und wollte mal kurz die 
Gelegenheit nutzen zu fragen wo ich denn den LTC2612 auf der Platine 
finde. Ist ja doch recht klein das Teilchen.

@Branadic

Du hast da doch bestimmt aktuell den Überblick oder?

Sonst such ich mir da bestimmt nen Wolf.

Gruß Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,
der LTC2612 ist im roten Kringel.

Mfg,
Kurt

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach, das ist ja gleich um die Ecke bei den Vorwiderständen die ich schon 
getauscht hatte.

Danke.

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

Bewertung
0 lesenswert
nicht lesenswert
Kurt Bohnen schrieb:
> Ich möchte nochmal an die Sammelbestellung für die Bauteile der
>
> Huckepackplatine erinnern. Die Frist endet Freitag Abend.
>
>
>
> Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Oh, danke, wäre mir sonst durchgegangen. Ich komme gerade aus dem Urlaub 
wieder und konnte das aktuell nicht verfolgen.

Mehr dort.

Jörg

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wieder ward es ruhig.

Es gibt ja anscheinend doch eine ganze Reihe Leute, die sich ein Welec 
zugelegt haben. Jetzt hat man mehrfach die Ausrede gehört, dass für 
Mikrocontrolleraufgaben das Welec ausreichend sei.
Nur wenige Leute wollen wirklich anspruchsvollere Messungen damit 
durchführen. Also Frage an all die Mikrocontroller-Programmierer, die 
ihr im Besitz eines Welec seid, warum könnt ihr Hayo beim Programmieren 
nicht unterstützen?

Wenn Hayo nichts implementieren kann, weil er gerade keine Zeit hat, 
passiert scheinbar überhaupt nichts mehr. Auf die Art und Weise kommt 
das Projekt nicht voran. Ich verstehe, dass Walter das Projekt verlassen 
hat und so langsam verliere auch ich die Lust immer nur zu warten..

branadic

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

Bewertung
0 lesenswert
nicht lesenswert
Wenn Hayo grade nichts dran tut würde ich mich anbieten mal meine 
Grafikfunktionen in seine Quellen zu mergen, die ich vor 1,5 Jahren in 
Subversion eingecheckt hatte.
Wie sieht der Entwicklungsflow derzeit aus? Hayo, kann ich mit die 
Quellen von dir "ausleihen" und dir das Resultat zurückschicken? Oder 
gibt es mittlerweile eine Versionsverwaltung?

Jörg

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
branadic schrieb:
> Also Frage an all die Mikrocontroller-Programmierer, die
> ihr im Besitz eines Welec seid, warum könnt ihr Hayo beim Programmieren
> nicht unterstützen?

Hast du selbst mal einen Blick in die Sourcen geworfen? Das ist kein
LED blinken lassen. Rechne mit 2 Wochen Vollzeit bis du leidlich
nachvollziehen kannst, wo was erledigt wird. Nur wenige werden
je verstehen wie was erledigt wird.

Gruß, Guido

Autor: Ingo M. (ingom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido schrieb:
> Rechne mit 2 Wochen Vollzeit bis du leidlich
> nachvollziehen kannst, wo was erledigt wird.

Außerdem müsste Hayo entscheiden, wer wo was ändern darf. Und dafür 
braucht er auch wieder Zeit. Vor allem braucht man auch SELBER Zeit. Ich 
hatte seinerzeit vorgehabt, Alex008 beim FPGA-Design zu unterstützen, 
aber aufgrund zuwenig Zeit davon Abstand genommen. Es macht keinen Sinn, 
wenn man nur halbe Arbeit abliefern kann.

Insofern finde ich es nicht schlimm, wenn dieses Projekt ab und zu mal 
eine kleine Pause einlegt. Dass es überhaupt schon soweit vorangekommen 
ist - alle Achtung! Dickes Kompliment an die Entwickler!

> Nur wenige werden je verstehen wie was erledigt wird.

Hat Hayo inzwischen eine Liste erstellt, wo was zu erledigen wäre? Wenn 
es viele kleine Teile wären, könnte man sich eher mal dran setzen.

Gruß Ingo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da kommt auch die Frage auf, was ist mit den ganzen anderen 
Programmierern der OS-Firmware?
Vor längerer Zeit gab es Zoff weil Hayo "sich quergestellt" hat. Danach 
haben anscheinend 5-10 Programmierer ihr Welec auf den Schrott geworfen 
und haben kapituliert. Nur Hayo hat tapfer weitergearbeitet und treibt 
auch jetzt noch das Projekt vorwärts. Das ist schon eine merkwürdige 
Geschichte!?
Wenigsten Jörg möchte "zurückkommen", vielen Dank!

Den Einwand von Guido muss ich leider bestätigen. Der Quelltext umfasst 
ca. 48000 Zeilen. Das ist etwas mehr als die normalen µC Projekte.

Vieleicht findet sich noch jemand der Alex helfen kann bei Software oder 
VHDL? Eine kleine Statusmeldung seinerseits wie weit er mit der 
Dokumentation gekommen ist, wäre auch schön.

Ist euch eigentlich aufgefallen dass die Auktionspreise für die Welecs 
deutlich gefallen sind? Früher waren es immer so 350€. Jetzt nur noch 
250-280€. Verlieren die Leute das Vertrauen in unser Projekt?



Sobald die Sammelbestellung für die Teile der Huckepackplatinen 
abgeschlossen ist werde ich noch eine Sammelbestellung für den USB-Host 
organisieren. Die Hardware ist fast endgültig fertig, die Firmware hat 
schon einen brauchbaren Funktionsumfang und läuft stabil genug.

Autor: Ingo M. (ingom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurt Bohnen schrieb:
> Vieleicht findet sich noch jemand der Alex helfen kann bei Software oder
> VHDL?

Gibt es irgendwo eine Übersicht, was noch zu erledigen wäre?

Gruß Ingo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido schrieb:
> Hast du selbst mal einen Blick in die Sourcen geworfen? Das ist kein
> LED blinken lassen. Rechne mit 2 Wochen Vollzeit bis du leidlich
> nachvollziehen kannst, wo was erledigt wird. Nur wenige werden
> je verstehen wie was erledigt wird.

Hallo Guido,

das Projekt gibt es doch auch nicht erst seit gestern und ganz ehrlich, 
eine LED blinken lassen hat mit Programmieren nicht das geringste zu 
tun.
Es ist halt blöd, wenn die Software ein reines 1-Mann-Projekt ist. Ich 
denke auch Hayo ist für Unterstützung dankbar.
Du hast dich ja scheinbar auch zurück gezogen.

Ingo M. schrieb:
> Insofern finde ich es nicht schlimm, wenn dieses Projekt ab und zu mal
> eine kleine Pause einlegt.

Genau das passiert, wenn nur noch einer am Projekt arbeitet und der Rest 
sich raus hält. Dann kann aber keine Rede mehr von "unserem 
Welec-Projekt" sein.


Zumindest hat meine Anfrage hier doch den Erfolg gebracht, dass sich 
einige Leute melden und ihre Unterstützung anbieten, das ist doch ein 
Anfang.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jungs,

nur keinen Stress. Bin zwar momentan noch etwas knapp an Zeit, aber nur 
keine Panik, es geht bald weiter. Ich sag morgen noch mal was dazu bis 
dann

Hayo

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
branadic schrieb:
> Du hast dich ja scheinbar auch zurück gezogen.

Schon, aber nicht weil ich mir irgendwann gesagt habe, da mache ich
nicht weiter. Die Unterbrechung, als Hayo abwesend war, hat mich halt
völlig rausgebracht, ich habe andere Projekte begonnen. Jetzt müsste
ich wieder bei Null anfangen und sehe dafür aber keine Notwendigkeit.
Der Aufwand wäre sehr groß, da C++ nicht meine Welt ist, und besser als
Hayo würde ich es doch nicht hinbekommen. Du musst einfach akzeptieren,
dass es nur sehr wenige Elektrotechniker gibt, die auf diesem Niveau
programmieren können. Andererseits gibt es nur sehr wenige Informatiker,
die genügend von Messtechnik verstehen um ein solches Projekt zu
stemmen. Herr Wittig könnte dir sicherlich ein Lied davrüber singen.

Und nocheinmal: Niemand hier hat etwas gegen SFN! Nur diskutieren
tun wir halt lieber hier.

Grüße, Guido

Autor: T. Dübel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido schrieb:
> Du musst einfach akzeptieren,
> dass es nur sehr wenige Elektrotechniker gibt, die auf diesem Niveau
> programmieren können. Andererseits gibt es nur sehr wenige Informatiker,
> die genügend von Messtechnik verstehen um ein solches Projekt zu
> stemmen.

Niveau hin oder her, Programmieren ist so anspruchsvoll nun auch wieder 
nicht, lassen wir doch mal die Kirche im Dorf. Es ist einfach nur so, 
dass die meisten einfach keinen Bock darauf haben, weil es eine stupide 
Arbeit ist. So umfangreich ist das Einarbeiten in die Thematik auch 
nicht, man ist nur zu bequem, weil es da ja jemanden gibt der die Arbeit 
für einen erledigt, so sieht es doch wohl aus! Hayo hat nur das größere 
Durchhaltevermöge gezeigt. Gesetz dem Fall Hayo hört auch auf, dann war 
es das mit eurem Projekt. Es hat schon immer geschadet seine Karten auf 
ein Pferd zu setzen, man sollte immer noch einen Trumpf in der 
Hinterhand haben.

Mit einer solchen Organisationsstruktur in einem Projekt ist man zum 
Scheitern verurteilt. Da kann man nur sagen, Welec-Projekt adé.

MFG, T. Dübel

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseirs,

ich sehe ich muß mir mal die Zeit nehmen einen längeren Beitrag zu 
schreiben.

Da meine Beweggründe für die eine oder andere Entscheidung anscheinend 
immer noch nicht ganz transparent für alle sind werde ich das noch mal 
erläutern:

Ich bin schon recht lange in der Softwareentwicklung tätig und weiß 
daher das ein Projekt welches von mehreren Entwicklern bearbeitet wird 
eine steuernde Instanz braucht die:

- Vorgaben macht
- koordiniert
- Ergebnisse prüft
- entscheidet welche Änderungen übernommen werden
- neue Releases herausgibt nachdem die Änderungen getestet wurden

Das gilt nicht nur für kommerzielle Projekte sondern auch für Open 
Source. Bei unserem Projekt gab es (auch wegen relativ dünner 
Personaldecke) sowas nicht. Das führt zum Teil zu etwas unkoordinierter 
Entwicklung und Wildwuchs.

Um hier unabhängig zu sein habe ich meine Version getrennt von der 
OS-Version weiterentwickelt und dann gegenseitig sinnvolle 
Verbesserungen ausgetauscht. Das ist auch immer noch der aktuelle Stand, 
obwohl zur Zeit an der OS-Version relativ wenig gearbeitet wird.

Zum Beitrag hier drüber:

Lieber T.Dübel,

Programmieren gehört zu den komplexesten Ingenieursleistungen überhaupt. 
Dass es nicht ganz so einfach ist wie Du behauptest sieht man an dem 
Ergebnis das die Firma WELEC nach mehreren Jahren Entwicklung 
abgeliefert hat und auf dem unsere Entwicklungen hier basieren.

Und gesetzt den Fall ich höre auf, so stehen alle bisherigen Arbeiten 
als Source mit Dokumentation zur Verfügung, so dass es keinen Grund gibt 
die Entwicklung nicht fortzuführen. Ich habe 2008 mit sehr viel weniger 
angefangen!


Zu SFN:

Ich finde es unbedingt wichtig, das wir alle Ergebnisse und 
Informationen an einer zentralen Stelle wie SFN zusammentragen um diese 
allen geordnet verfügbar zu machen. Das hat nichts damit zu tun, das ein 
großer Teil der Kommunikation hier im Forum stattfindet. Meine aktuellen 
Releases sind immer auch auf SFN zu finden. Hier im Forum habe ich 
einfach direkteren Kontakt zu allen Betroffenen.


@Jörg, Ingo, Guido, Kurt und alle die mithelfen wollen:

Meine aktuelle To Do Liste die mir so gerade einfällt sieht ungefähr so 
aus:

- Pretriggerwerte aktualisieren wenn TB geändert wird (ist in Arbeit)

- Unterstützung für 16 Bit DAC. Die erste Anpassung scheint noch nicht 
zu funktionieren. Ich hätte eine Idee wo noch etwas geändert werden 
müßte. Wenn sich jemand des Themas annehmen möchte kann ich gerne 
Hinweise zu den entscheidenden Stellen geben.

- Unterstützung für die Addon-Platine von branadic. Auch hier ist 
kurzfristige Hilfe willkommen damit die hardwareseitige Entwicklung 
weitergehen kann. Ich helfe auch gerne bei der Orientierung in der 
Source.

- Druckmenü für Kurt erweitern -> ist in Arbeit

- Manuellen Trigger prüfen und evtl. anpassen (geringe Prio)

- Math-Funktionen (+  -  *) prüfen überarbeiten (falsche Ergebnisse?)

- Neues USB-Interface weiterentwickeln und PC-Software erstellen.

- FFT-Bereich weiter entwickeln.

- Screenshot BF-Version auf die aktuelle Komprimierungsroutine der 
OS-Version updaten um etwas schneller zu werden und kompatibel zu sein.

Fehlt was entscheidendes?
Wenn Ihr Ergebnisse habt, baue ich die gerne mit in die Source ein.


Zu Subversion:

Ich hatte mit Rolfs Hilfe ein SVN-Verzeichnis bei SFN eingerichtet, aber 
die Synchronisation hat nur zwei mal geklappt, dann habe ich aus 
Versehen bei mir die Steuerdateien gelöscht und habe es dann nicht mehr 
hinbekommen. Ich müßte das also versuchen wieder neu einzurichten.


So erstmal genug

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hayo,
ich habe mich gestern Abend mal mit Walter über die Ansteuerung der 
Huckepackplatine unterhalten und er hat versucht mir die nötigen 
Änderungen zu erklären. Leider habe ich es nur zu 90% verstanden und 
muss nochmal nachfragen.

Danach werde ich ein Bildchen malen wie die Platinen angesteuert werden 
müssen.

Mfg,
Kurt

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Kurt,

das klingt gut. Wenn ich mich da nicht komplett neu reindenken muß kann 
ich da auch schneller eine Implementierung anbieten - bzw. jemand 
anderes hier.


@All

Ach ja, falls der Eine oder Andere Bedenken hat, dass ich mit der 
Entwicklung hier aufhöre, so möchte ich darauf hinweisen, dass ich mir 
extra für die Entwicklung und zum Testen der WELECS umfangreiches 
Equipment im Wert von über 1000 Euro zugelegt habe. Das haut man nicht 
mal eben so in die Tonne.

Also locker bleiben und Ruhe ausstrahlen ;-)


Gruß Hayo

Autor: Werner S. (werner_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

zu deinem Problem:

Hayo W. schrieb:
> Zu Subversion:
>
> Ich hatte mit Rolfs Hilfe ein SVN-Verzeichnis bei SFN eingerichtet, aber
> die Synchronisation hat nur zwei mal geklappt, dann habe ich aus
> Versehen bei mir die Steuerdateien gelöscht und habe es dann nicht mehr
> hinbekommen. Ich müßte das also versuchen wieder neu einzurichten.

Mögliche Abhilfe:
1.) Projekt von Sourceforge neu auschecken(in neuen lokalen Ordner).
2.) Sourcen, usw. vom Ordner ohne Steuerdaten direkt in den 
ausgecheckten Stand kopieren.
3.) dann ist ein Commit wieder möglich und sollte gleich vorgenommen 
werden.

zuküntig: Oft Committen und ggf. branches bei Teständerungen o.ä. 
verwenden.

weitere Fragen zu Subversion:
bitte gerne hier stellen...

MfG
Werner S.

Autor: alex008 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Liebe Oszilloskop-Gemeinde!

Wie Branadic, Hayo und Co schon behauptet haben, stimme ich zu, dass die 
Programmierung keine stupide Arbeit ist.

Das gilt besonders hier für den Embedded-Bereich, welcher sich mit 
Messtechnik, Signalverarbeitung wie hier zu tun hat.

Für das Programmieren hier muss man die Messtechnik gut verstehen und 
mittelmäßig selbst bauen können und digitale Schaltungen verstehen.
Die Programmiersprache C, C++ ist nunmal Standard in dem Bereich und 
keinesfalls Deppensicher. Zudem ergeben sich erschwerte Bedingungen auf 
Grund der spärlich vorhandenen Debug-Möglichkeit und der begrenzten 
CPU-Performance.

Für eine VHDL-Entwicklung ist unbedingt ein Niveau für einen 
Digitalchip-Entwickler nötig. Das war der Teil in unserem Studium, bei 
welchen die meisten Studienkollegen aufgrund der Fehleranfälligkeit und 
der Unüberschaubarkeit teils große Schwierigkeiten haben.
Weiters wollen die meisten im Berufsleben nichts mehr damit zu tun 
haben.

Eines ist klar, sich in einen unvollständigen fremden Source-Code 
einzulesen, ist sehr mühsam und kann manchmal so sehr frustrieren, dass 
jeder seine eigene Suppe kocht.

Die geringe Verbreitung der Hardware kommt noch dazu -
Kein Wunder also, dass wir so wenig Entwickler sind.

MfG
Alexander

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hayo

Eine Frage zur Screenshot-Funktion:
Früher konnte man durch "Doppel-Click" auf die Quick-Print-Taste einen 
ScreenShot auslösen, den man dann auf dem PC via RS232 mit dem 
entsprechenden w2000a-screenshot.exe empfangen konnte. Ist die Funktion 
gerade im Bau bzw. unter die Räder gekommen oder was macht das DSA jetzt 
bei Doppel-Click. Muß man da jetzt besondere Einstellungen vornehmen, 
damit der PC das mitbekommt? Mit der 2.10 bekomme ich z.Z. nur einen 
ScreenShot hin, wenn ich direkt die Tasten im Quick-Print Menü benutze, 
kann dann aber z.B. Cursoreinstellungen nicht dokumentieren.

Kannst du da, wenn du Zeit hast, mal ein paar erhellende Worte fallen 
lassen?

Gruß
Rainer

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,
hast du darauf geachtet das die Screenshot Version (BF oder OS) von PC 
und Oszi übereinstimmen?
Mfg,
Kurt

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

die Funkion sollte wie gehabt arbeiten. Wie Kurt schon sagt muß aber die 
richtige Version eingestellt sein (passend zur PC-Software).

Ich bin ja ohnehin gerade dabei die Druckfunktion für Kurt anzupassen, 
da kann ich das sonst noch mal testen.

Gruß Hayo

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was heißt "übereinstimmen"?
Die beiden w2000a-screenshot.exe sind schon etwas betagter (BF 
2.Nov.2010 bzw. OS 21.Sep.2010) und habe ich aus dem letzten FW-Update 
von Hayo (1.2.BF.2.10.zip). Gibt es da was aktuelleres? Auf PC-Seite 
funktioniert eigentlich alles, wenn ich den ScreenShot.exe auf Daten vom 
DSO lauern lasse. Nur der "Quick Print" Doppel-Click tut anscheinend 
etwas anderes als früher.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich prüf das mal und sag dann Bescheid.

Hayo

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Ich prüf das mal und sag dann Bescheid.

Das wäre prima, das DSO ist nach dem Doppel-Click beschäftigt, aber der 
PC merkt nichts von Daten.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja Du hast recht. Das hatte ich bislang noch nicht bemerkt. Ich vermute, 
dass ich durch den Umbau für Kurt da einen Fehler eingebaut habe. Das 
korrigiere ich natürlich zur nächsten Version.

Danke für den Hinweis

Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
So,

hab mich heute mal drangesetzt und einige Punkte abgearbeitet:

- neues Quick Print Menü mit Unterstützung für Kurts Projekt
- Pretrigger wird jetzt immer korrekt upgedatet
- 16 Bit DAC wird jetzt (hoffentlich) korrekt unterstützt. Ich habe mir 
mal die Spezifikation runtergeladen und das Registersetting angepasst
- Quick Print double push funktioniert wieder

Und jetzt geht es wieder ab zum Griechen. Bis nachher


Gruß Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,
das gefällt mir sehr gut und es funtkioniert!

Leider hast du vergessen die handleInChar anzupassen. Hier nochmal die 
benötigten Zeilen:
case    5:
    CommIF::UC_SCREENSHOT(); // -> UC version
break;
case    6:
    CommIF::UC_SCREENSHOT_BW(); // -> UC version black and white
break;
case    7:
    CommIF::UC_DUMPCSV();  // -> UC version
break;

Dann habe ich noch eine neue uc_dumpcsv die bei 2 Kanal Geräten auch nur 
Daten der 2 Kanäle überträgt.

Mfg,
Kurt

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok,

bin gerade vom Griechen zurück. Hatte ich übersehen. Ich bau das morgen 
mal ein und gebe dann eine neue Compilation raus.

@branadic
Es würde mich mal interessieren ob die 16 bit DAC-Ansteuerung jetzt 
funktioniert.


Gruß Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
Der frühe Vogel fängt den Wurm!

Alles schläft - einer fährt, oder so ähnlich. Also, hab noch ne 
Nachtschicht eingelegt und die Korrekturen eingebaut.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

was heißt hier alles schläft? Bin gerade erst nach Hause gekommen.
Die DAC teste ich nachher mal, jetzt ist erst einmal Augen ausruhen 
angesagt.

branadic

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also Hayo, DAC-Kalibrierroutine funktioniert noch nicht korrekt mit dem 
16bit DAC zusammen, die Signallinien landen nicht auf 0.

Beim Verstellen des DAC-Level wandern Signal und Kanalanzeige (links u. 
rechts) nicht gleichmäßig sondern die Kanalanzeige wandert gefühlt 
doppelt so schnell auf dem Bildschirm hoch und runter.

Dann hätte ich noch eine Anregung zu den flimmernden LEDs für Trigger 
Wait und Trigger Event. Wäre es vielleicht sinnvoller die Trigger Event 
LED solange dauerhaft leuchten zu lassen, solange hintereinander 
Triggersignale kommen und erst wenn 1s lang kein Triggersignal gekommen 
ist auf Trigger Wait umgeschaltet wird?
Das Flackern ist echt hart, man könnte meinen man schaut einen dieser 
asiatischen SciFi-Trickfilme.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
branadic schrieb:
> Also Hayo, DAC-Kalibrierroutine funktioniert noch nicht korrekt mit dem
> 16bit DAC zusammen, die Signallinien landen nicht auf 0.

Das hab ich mir gedacht. Die Kalibrierroutine ist auf den 14 Bit DAC 
optimiert. Das müßte ich dann anpassen wenn ich das Teil bei mir 
einglötet habe. Wie groß ist denn die Abweichung? -> Screebshot

> Beim Verstellen des DAC-Level wandern Signal und Kanalanzeige (links u.
> rechts) nicht gleichmäßig sondern die Kanalanzeige wandert gefühlt
> doppelt so schnell auf dem Bildschirm hoch und runter.

Das ist klar, denn die Schrittweite hat sich ziemlich stark geändert. 
Das muß ich auch noch anpassen.

Aber die Verstellung an sich funktioniert korrekt? Wie sieht es mit der 
Verstellgeschwindigkeit  Ansprechverhalten  Einstellgenauigkeit aus? 
Macht der Umbau Sinn?

> Dann hätte ich noch eine Anregung zu den flimmernden LEDs für Trigger
> Wait und Trigger Event. Wäre es vielleicht sinnvoller die Trigger Event
> LED solange dauerhaft leuchten zu lassen, solange hintereinander
> Triggersignale kommen und erst wenn 1s lang kein Triggersignal gekommen
> ist auf Trigger Wait umgeschaltet wird?

Das fände ich persönlich nicht so gut. Die Anzeige macht für mich so 
schon Sinn, auch wenn es zugegebenermaßen manchmal etwas hektisch 
blitzelt.

> Das Flackern ist echt hart, man könnte meinen man schaut einen dieser
> asiatischen SciFi-Trickfilme.

Deshalb habe ich die Möglichkeit vorgesehen die LEDs separat 
abzuschalten.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verstellung ist soweit in Ordnung, Geschwindigkeit etc ebenfalls. Der 
Umbau macht auf jeden Fall Sinn. Ich möchte daran erinnern, dass wir mit 
der Huckepackplatine zusätzliche Spannungsbasen von 5mV/div, 2mV/div und 
1mV/div dazu gewinnen und spätestens da wird eine feinere Verstellung 
notwendig sein.

Was die LEDs angeht, ich kann dir nur sagen wie das bei Tektronix gelöst 
ist, Disco-Licht gibt es dort nicht.

Übrigens ist es überhaupt nicht notwendig an der Frontplatte 
herumzuschnippeln oder mit Heißkleber rum zu sauen, wenn man Osram 
Topleds verwendet. Die sind hell genug auch durch die Frontfolie durch 
zu leuchten. Für rot verwende ich LS T67B (super-rot) und für grün LT 
T67C (true green). Das eher matschige grün im Welec scheint die LTG T676 
zu sein.

branadic

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

Bewertung
0 lesenswert
nicht lesenswert
So Branadic,

damit Du nicht so gefrustet bist über die Diskobeleuchtung habe ich Dir 
eine neue Kompilation gemacht mit überarbeiteter 16 Bit 
DAC-Unterstützung.

Eigentlich müßte es jetzt alles korrekt funktionieren. Ich habe die 
Ansteuerung jetzt so gemacht, dass man auf den Umschalter im 
Hardwaremenü eigentlich verzichten könnte. Die Ansteuerung ist nämlich 
eigentlich Sofwarekompatibel für alle drei DAC-Typen ausgelegt, so dass 
man sie beliebig tauschen kann ohne etwas anpassen zu müssen - 
vorausgesetzt man hat das von vornherein in der Ansteuerung 
berücksichtigt.

Ich muß wohl nicht erwähnen, dass WELEC das natürlich nicht so 
implementiert hat.

Sollte also jetzt alles korrekt sein werde ich in der nächsten Version 
den Schalter wieder rausnehmen.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
By the way - ich habe mir das Hirn zermartert was der 16 Bit DAC 
eigentlich bringen soll. Mir ist nix eingefallen. Vielleicht kannst Du 
mir da auf die Sprünge helfen.

Die Schrittweite ist nämlich nicht von der DAC-Auflösung abhängig, 
sondern wird in "Pixelschritten" vorgenommen. Und die sind bei den 
korrespondierenden Spannungsbereichen (5er/2er/1er) immer gleich.

Beim 16 Bit DAC sind dann die Werteschritte einfach nur Faktor 4 größer.

Oder hab ich da einen Denkfehler???

Gruß Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

die DAC-Implementierung schaut soweit gut aus, zumindest für Kanal 1 und 
2. Kanal3 macht einige Probleme:

1. Kanal3 bekomme ich durch den DAC-Abgleich nicht komplett auf Null, es 
bleibt ein geringer positiver Offset.

2. Bei Zeitbasen >10µs (<=25MS) entstehen auf Kanal3 und komischerweise 
nur dort unschöne Störungen, die bei Zeitbasen <=5µs/div (>=250MS) nicht 
zu sehen sind. Diese sind je nach DAC-Level unterschiedlich stark. Um 
Null herum füllen sie sogar bei einigen Leveln den halben Bildschirm, 
wie du den beiden Bildern entnehmen kannst.

Was den DAC angeht, so wird eine Verstellung um ein MSB bei Zeitbasen 
von 1mV/div einem großen Sprung auf dem Bildschirm entsprechen, daher 
hatte Walter den Tausch vorgeschlagen.
Zudem sollte sich der Signal-Störabstand des DAC-Ausgangssignals durch 
die höhere Auflösung in den anderen Spannungsbasen reduzieren. Immerhin 
wird jedwedes DAC-Rauschen mit verstärkt, weil das DAC-Signal relativ 
früh in den Signalzweig eingespeist wird und somit alle Verstärkerstufen 
durchläuft.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin moin,

ich hab mich noch mal drangesetzt und einige Testreihen zum DAC gemacht 
bzw. die Werte nachgerechnet und die techn. Specs verglichen.

Grundsätzlich bringt der 16 Bit DAC in den 5er Ranges keinen Vorteil und 
in den 2er Ranges nur wenig.

Die elektrischen Eigenschaften der drei Typen sind identisch.
Die Schrittweite beträgt beim 14 Bit DAC in den 5er Ranges 3/Pix und in 
den 2er Ranges 1 bzw. 2/Pix.

Beim 16 Bit Dac liegt die Schrittweite in den 5er Bereichen bei 12 bzw. 
13/Pix und in den 2er Bereichen bei 5/Pix.

Einen Auflösungsvorteil bringt es in den 1er Bereichen, da hier die 
Schrittweite des 14 Bit DAC bei 1/2Pix liegt. Heißt übersetzt, nur alle 
2 Pixel wird der DAC um 1 weitergestellt.

Das ist natürlich beim 16 Bit DAC besser. Hier liegt die Schrittweite 
dann bei 2 bzw. 3/Pix.

Die Werte kann jeder leicht selbst ermitteln, wenn er sich über ein 
Terminalprogramm die Variablenwerte ausgeben läßt (","). Die DAC-Werte 
findet man im fünften Abschnitt.


So Branadic,

nun zu Deinem Problem auf Kanal 3. Das scheint mir ein Hardwareproblem 
zu sein - kalte Lötstelle, Brücke etc.. Bei mir funktioniert sowohl der 
Zero-Abgleich als auch alles Andere. Keine Spikes oder sowas Ähnliches.

Die firmwareseitige Implementierung ist also ok.

Ich werde mir den DAC also auch einbauen um in den 1er Bereichen eine 
feinere Auflösung zu erzielen.

In der nächsten Version wird die Ansteuerung so sein dass keine 
Umschaltung mehr erforderlich ist und auch ein gemischter Betrieb (bei 
den 4 Kanalern) möglich ist.


Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Das scheint mir ein Hardwareproblem
> zu sein - kalte Lötstelle, Brücke etc

Das glaube ich nicht Hayo, weil die Spikes sofort weg sind, sobald die 
Samplerate >25MS beträgt, wie erklärst du das elektrisch?

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geschickter Einwand - aber wie erklärst Du Dir dass es nur bei 
bestimmten Zeitbasen auftritt obwohl die Zeitbasen keinen Einfluß auf 
die DAC-Ansteuerung haben?

Ich bin gerade bei der neuen Version, damit kannst Du das nochmal prüfen 
- und alle Anderen auch, da jetzt die DACS immer gleich angesteuert 
werden.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

ich behaupte ja nicht, dass es zwangsläufig an der DAC-Ansteuerung 
liegt, könnte auch was anderes im FPGA o.ä. sein. Ich kann dir nur nicht 
sagen was es ist, genauso wenig wie jemand beantworten kann, woher die 
Spikes auf den Kanälen genau kommen, denn im Leon-Design sind sie nicht 
zu finden.
Witzigerweise sind sie auf Kanal 1 in voller Signalhöhe zu sehen, auf 
Kanal 2 kippen sie um die Hälfte hoch und runter und auf Kanal3 sehe ich 
sie gar nicht, wenn nicht gerade der DAC-Level auf einer ungünstigen 
Position steht und die oben gezeigten Störungen produziert.

branadic

Autor: Ingo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alex008 schrieb:
> Für eine VHDL-Entwicklung ist unbedingt ein Niveau für einen
> Digitalchip-Entwickler nötig.

Welches Standardwerk empfiehlst du als Lektüre, um auf das Niveau eines 
Digitalchip-Entwicklers zu kommen?

Ich habe bisher noch keinen Chip entwickelt, weiß aber grundsätzlich, 
wie Chips entwickelt werden und kenne mich zumindest in Assembler und C 
sehr gut aus. Ich habe auch mal einen Compiler für einen 
Scheme-Prozessor geschrieben, das war sehr hardwarenah.

> Das war der Teil in unserem Studium, bei
> welchen die meisten Studienkollegen aufgrund der Fehleranfälligkeit und
> der Unüberschaubarkeit teils große Schwierigkeiten haben.
> Weiters wollen die meisten im Berufsleben nichts mehr damit zu tun
> haben.

Das bedeutet also, dass es nur wenig VHDL-Entwickler gibt? Wie sind zur 
Zeit die beruflichen Aussichten? Muss man sich international 
orientieren? Und wie sieht es mit Verilog aus? Das würde mich wirklich 
mal interessieren.

Gruß Ingo

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

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite in einer kleineren Chipentwicklungsfirma, bin selbst aber 
embedded Softwerker.

Nachdem was ich so manchmal mitkriege: VHDL ist kaum noch üblich, wird 
eher als Lehrsprache betrachtet. Die produktive Arbeit wird in Verilog 
erledigt. Das ist vielleicht so wie Pascal (oder Modula-2) vs. C.

War mal anders, als ich anfing war VHDL höher angesehen.

Jörg

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

Bewertung
0 lesenswert
nicht lesenswert
Ok werte Gemeinde,

ich war fleißig und habe die letzten Tage durchprogrammiert. Leider hat 
die Zeit nicht gereicht alle Punkte auf der Liste abzuarbeiten, aber die 
neue Version kann sich trotzdem sehen lassen.

Hier die Highlights:

- automatischer Support für 12/14/16 Bit DAC ohne Umschaltung! Auch 
gemischte Bestückung.

- neue Kalibrierroutine die für die neue DAC-Ansteuerung optimiert wurde 
und eine neue Kalibrierlogik hat, die jetzt den Offset dynamisch gegen 
Null approximiert. Weiterhin habe ich den ADC-Abgleich und den 
DAC-Abgleich zusammengelegt. Es gibt also nur noch einen Button für den 
Abgleich. Damit Ihr die neue Routine besser testen könnt habe ich die 
Debug-Ausgaben auf RS232 dringelassen. Ihr könnt Euch also den 
Abgleichvorgang in einem Terminalfenster ansehen und prüfen ob er 
wirklich auf Null geht.
D.h. der Offset liegt dann unterhalb der Anzeigegenauigkeit in allen 
Spannungsbereichen! Besser geht es nicht...

- Der freie Platz neben dem Kalbrierbutton hat auch schon eine neue 
Funktion bekommen. Hier kann man zwischen 4 verschiedenen 
Kalibriersätzen wählen (für branadic und alle die aktive Tastköpfe 
benutzen)

- Main Wheel Support für die Channel Delay Popups und für Average und 
Noise Filter.

- Weiterhin noch einige kleine Änderungen. (siehe changelog und 
special_functions.txt)

Gruß Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

ich hab die neue Version mal eingespielt, allerdings ist nach der 
Kalibrierung mein Kanal3 (über Kanal4 kann ich nichts sagen da 
teilentstückt) verschwunden. Hab mal zwei Kalibriervörgänge 
mitgeschnitten, vielleicht kannst du darin was entdecken?

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Branadic,

Dein Kanal 4 liefert wie erwartet keine Werte. Aber Kanal 3 wird korrekt 
kalibrtert.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

wie ich schrieb habe ich den teilweise entstückt, um Platz für die 
Huckepackplatine zu machen. Wirkt sich das jetzt etwa negativ auf die 
Kalibrierung von Kanal 3 aus?

branadic

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, du hast in der Zwischenzeit dein Posting editiert, auch gut...
Ich habe mich einmal durch die Calibration Sets gedrückt und wenn ich 
dann wieder bei Standard ankomme, dann ist Kanal 3 wieder da.
Noch was, Kanal 1 ist zu tief, also unterhalb der gedachten Nulllinie, 
woran kann das liegen?

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da haben sich unsere Posts wohl überschnitten. Ich hatte beim zweiten 
Überlesen schon gesehen dass Du den Kanal 4 rausgelötet hast.

Hast Du die Kalibrierung mal für alle 4 Kalibrier-Sets gemacht? Deinem 
Protokol entnehme ich aber, dass mit Deinem Kanal 3 alles genau richtig 
klappt. Also hakt es wohl woanders.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es könnte sein, dass die DAC-Skalierungsfaktoren für die 16 Bit DACs 
angepasst werden müssen. Dafür muß ich aber bei mir den 16 Bit DAC 
einbauen um das zu überprüfen.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, jetzt haben wir den zeitlichen Versatz wieder ausgeglichen :)

Also, nach der Kalibrierung muss ich mich einmal durch die Sets drücken, 
damit Kanal 3 wieder dargestellt wird. Vielleicht hängt das irgendwie 
mit meinem Kanal 4 zusammen, kann gut sein.
Kanal 2 und 3 liegen dann sauber auf Null, nur Kanal 1 liegt 6 Pixel 
unter Null. Hab das mit der Triggerlinie mal ausgezählt. Lässt sich das 
eigentlich irgendwie über das Terminal manuell erade biegen? Die 
Testschalter scheinen nicht mehr ganz aktuell zu sein oder irre ich mich 
da?

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warte mal,

ich seh mal kurz nach. Ich hatte die manuelle DAC-Kalibrierung extra 
drin gelassen.

Moment...

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ergibt sich ein Bild Hayo, die Abweichung hat was mit der Position 
auf dem Bildschirm zu tun, bei Kanal 1 fällt das nur gleich so extrem 
auf, weil der Kanal am oberen Bildschirmrand klebt. Kurbel ich Kanal 3 
auch nach oben auf die Position von Kanal 1, dann weißt er den gleichen 
scheinbar negativen Offset auf. Spannungspegel und Bildschirmposition 
passen nicht 100% zusammen, dass ist alles.
In der Bildschirmmitte ist auch bei Kanal 1 alles in Ordnung.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ok hab's,

also mit shift + Z kannst Du den Testkanal verstellen der den wirksamen 
Kanal vorgibt.

Den Spannungsbereich für den kalibriert wird mußt Du von Hand einstellen 
(5er oder 2er oder 1er) mit der normalen Bereichseinstellung auf dem 
Frontpanel.

Du mußt natürlich auch ein Kalibrierset ausgewählt haben mit dem Du 
testest.

Die kalibrierung kannst Du dann mit Shift + E hochzählen und mit Shift + 
W runterzählen.

Das Ergebnis kannst Du Dir dann mit "," ansehen.

Bei mir liegen die Offsetkorrekturen bei:

* CH1 DAC correction 1:   406     * CH3 DAC correction 1:   448    *
* CH1 DAC correction 2:   478     * CH3 DAC correction 2:   506    *
* CH1 DAC correction 3:   400     * CH3 DAC correction 3:   427    *
* CH2 DAC correction 1:   358     * CH4 DAC correction 1:   418    *
* CH2 DAC correction 2:   422     * CH4 DAC correction 2:   478    *
* CH2 DAC correction 3:   373     * CH4 DAC correction 3:   427    *


Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok,

hast Du mal Dein Hardwaresetting geprüft?

Welchen Pre Gain hast Du eingestellt?

Das was Du da beschreibst deutet auf die Skalierungsfaktoren hin!

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

ja habe ich geprüft, das passt soweit auch alles, steht auf PreGain 
1.25. Messungen mit Multimeter und Oszi an einer Batterie oder an einem 
Labornetzteil zeigen auch näherungsweise das gleiche Ergebnis.

branadic

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

anbei mal drei Bilder, die verdeutlichen sollen, was Sache ist. 
Vielleicht hilft das bei der Fehlersuche?

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, das sind ganz klar die Skalierungsfaktoren, die nicht passen.

Wenn auf Gridmitte die Offsets Null sind aber oben und unten im Grid 
Aweichungen auftreten dann ist es das.

Die sind ja auch nur für den 14 Bit DAC ermittelt worden. Leider kann 
ich da erst tätig werden sobald ich den 16 Bitter bei mir drin habe.

Ich könnte sonst noch versuchen so nach Gefühl die Werte für Dich 
anzupassen, damit Du was zum Probieren hast.

Wie sehen denn die 5er und 2er Bereiche aus?

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du die Möglichkeit zu kompilieren? Die Faktoren findest Du in der 
tc_vars.cpp ab Zeile 1165.


float DAC_ScaleFactor[3][5] =

  gain 1/gain 1.25/24 Ohm/33 Ohm/addon
{{ 2.480, 2.480, 2.6456, 2.520, 2.476 },  // 1er ranges
 { 4.940, 4.940, 5.2912, 4.980, 4.952 },  // 2er ranges
 {12.360,12.360,13.2280,12.432,12.432 }};  // 5er ranges


Du könntest sie Dir einfach selbst anpassen.

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Wie sehen denn die 5er und 2er Bereiche aus?

Kann ich dir heute Abend sagen, muss ich prüfen.

Hayo W. schrieb:
> Hast Du die Möglichkeit zu kompilieren?

Nein, ich habe die Tool Chain nicht installiert, da ich mit 
Programmierung, die über Matlab/Octave hinaus geht, nicht wirklich was 
am Hut habe.

branadic

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Hast Du die Möglichkeit zu kompilieren?

Kann ich übernehmen. Welche Werte müssen denn geändert werden? Jeweils 
der letze in der Zeile?

Mfg,
Kurt

PS: Die Digikey Lieferung ist schon in Köln und müsste morgen ankommen.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein etwas anders,

am Besten Du suchst Dir eine Spalte aus - z.B. die Letzte. Die läßt sich 
dann anwählen über das Hardwaremenü Pre Gain -> "Addon".

Die drei Werte sind dann für jeweils einen Spannungsbereich. Der Oberste 
für die 1er Spannungsbereiche, der mittlere für die 2er und der unterste 
ist für die 5er.

Ich vermute, dass die Werte für den 16 Bit DAC einfach noch nicht genau 
genug sind und nur feinjustiert werden müssen.

Zum Justieren muß die Nullposition des Kanals möglichst weit oben oder 
unten sein um die maximale Abweichung zu haben.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mich aber etwas wundert, ist der Unterschied zwischen Kanal 2 und 
den beiden andern Kanälen. Kanal 2 sieht ja eigentlich ganz ok aus. Es 
sollte bei gleicher Eingangshardware eigentlich keinen Unterschied 
geben.

Ist da was an den Widerständen geändert worden?

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

verdammt, es ist schon so lange her... ich habe auf Kanal 1 und Kanal 3 
die 24.9Ohm drin, Kanal 2 hat noch die 0 Ohm drin. Den 150k hab ich 
allerdings nicht ausgetauscht.
Wenn ich jetzt die beiden Kanäle nach oben kurbel wird die Abweichung 
zur Nulllinie aber noch größer.
Hier stoßen wir also auf die erste Problematik, wie die ganzen 
Hardwareunterschiede gescheit in den Griff bekommen?
Ich könnte natürlich hergehen und alle Widerstände wie im Datenblatt 
vorgesehen bestücken, sprich 2x 24.9 Ohm und 150 Ohm. Das sollte dann 
aber auch die festgelegte Konfiguration für die Huckepackplatine sein, 
sonst bekommt man das nicht unter einen gemeinsamen Hut.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann ist ja alles klar. Es liegt also nicht am DAC. Mit der 24/150 
Ohm Bestückung passen die Faktoren der 24 Ohm Pre Gain Einstellung. Die 
habe ich auch drin.

Rüste die doch einfach um, das ist vom Aufwand her am einfachsten denke 
ich.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

passen tut es ja trotzdem nicht 100%ig, siehe Kanal 2 mit PreGain 1.25 
Einstellung.
Von den 24 Ohm halte ich ebenso wenig wie von den 33 Ohm, wenn man es 
richtig machen will, dann müssten es entweder 24.9 Ohm mit kleinster 
Toleranz und den 150 Ohm am ADC sein oder aber handverlesene 24 Ohm, die 
nominal 25 Ohm aufweisen mit den 150 Ohm am ADC. Alles andere macht 
schlichtweg keinen Sinn.
Schließlich soll es sich um ein Messgerät und nicht um ein Schätzeisen 
handeln.

branadic

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Nachtrag, Kanal 2 hatte ich seinerzeit nicht umgerüstet, weil 
da diese tollen nachträglich eingezogenen Leitungen im Weg waren.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kanal 2 sieht doch gut aus. Must Dir das mal im 5er Bereich ansehen, da 
ist weniger Rauschen drauf.

Sonst rüste das doch erstmal zurück auf Originalbestückung, dann können 
wir besser vergleichen.

Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kanal 2 ist doch auf Originalbestückung, sprich auf 0 Ohm Widerstände 
oder meinst du ich solle die DAC zurücklöten?
Das muss dann wirklich nicht sein, zumal die das Auslöten eh nicht 
überlebt haben, ein Nachteil von bleifrei gelöteten SMD-Bauteilen, wenn 
man die Leiterplatte beim Auslöten schonen möchte.

branadic

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, nein,

nicht den DAC zurückbauen, nur die Widerstände von Kanal 1 + 3. Oder 
damit leben, dass nur Kanal 2 richtig anzeigt.

Jedenfalls zeigt mir Dein Ergebnis, dass die DAC-Ansteuerung korrekt 
funktioniert. Ich werde das bei meinen Geräten auch mal umrüsten.

Gruß Hayo

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Branadic, ein Messgerät mit 8-Bit-Auflösung! Also schön ruhig
bleiben. ;-) Auch mit 10 Bit wird es kein Messgerät. Die Werte
sind doch nur Empfehlungen und solange die Software auf ein Pixel
genau darauf eingestellt werden kann ist doch alles o.k.

Gruß, Guido

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido schrieb:
> Also schön ruhig
> bleiben. ;-)

Vielleicht bleibst du noch ne Nummer ruhiger und schaust mal, wie groß 
die Abweichung tatsächlich ist? Im Rahmen dessen was möglich ist sollte 
man auch genau sein!

branadic

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon klar, dass das zuviel ist. Aber mit den Widerständen
muss es nicht so exakt sein. Das meinte ich.

Autor: ZackZack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nutze das FFT oft für Audio Projekte. Gibt es eine Möglichkeit, das 
das Spektrum feiner eingestellt werden kann? Das währe bei kleinen 
Frequenzen sehr sinnvoll.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die FFT-Sektion ist noch "under construction", d.h hier wird sich noch 
einiges tun.

Was meinst Du denn mit feiner einstellen? Die Auflösung der 
Spektrallinien ist durch die kleinste Abtastrate (500Sa/s) und die 
Bildschirmauflösung begrenzt. D.h. ich kann maximal eine FFT mit 1024 
Werten machen und habe dann 512 Spektrallinien.

War es das was Du meintest?

Gruß Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
So, für das Wochenende gibt es wieder was zum spielen.

Diesmal habe ich mich der Screenshot-Funktion angenommen und einen 
Rundumschlag gemacht (aufgeräumt und erweitert).

Auf der DSO Seite gibt es jetzt keine Unterscheidung mehr zwischen OS 
und BF-Version. Es gibt nur noch die Möglichkeit zwischen den Zielen PC 
und USB-Host zu wählen. Für alle Screenshots wird jetzt die schnellere 
Kompressionsroutine der 0.92.OS Version verwendet.

Auf PC Seite gibt es zwei neue Screenshot-Versionen. Beide können 
wahlweise eingesetzt werden und verwenden beide den gleichen 
Kompressionsalgorithmus.

- die neue OS-Version 0.93 hat sich bei der Parametererkennung über 
RS232 etwas geändert. Das heißt sie ist weiter abwärtskompatibel zu 
älteren Firmwareversionen (BF und OS), aber sie läßt sich genauso mit 
der neuen FW ansteuern und kann wie gehabt auch remote triggern.

- die neue BF-Version 2.0 hat jetzt den schnellen 
Kompressionsalgorithmus der OS-Version. Der Aufruf ist noch schlanker 
geworden, es kann optional der Port (bzw. das device) übergeben werden, 
muß aber nicht. Defaultmäßig wird wie bei der OS-Version COM1 bzw. 
/dev/ttyS0 verwendet.

Bei ASCII und CSV Format werden zusätzlich die aktuellen 
Einstell-Parameter übertragen und ans Ende der Datei gehängt.

Die alten Screenshotversionen können nicht mehr verwendet werden!!!

Gruß Hayo

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle zusammen,

habe mich gerade mit dem seriellen Update beschäftigt:
Für das .ram reicht es aus, das File mit

mode com1,115200,n,8,2     leider ist der mode-Befehl sehr buggy, meist 
geht 115200 nicht
copy /b tomcat.ram com1

zu übertragen.

Wichtig sind die 2 Stopbits, sonst ist die Übertragung zu schnell.

Der Transfer dauert dann 1313562*(1+8+2)/115200=125,426 Sekunden.
Alternativ die Übertragungsfunktion (Upload) eines Terminalprogramms 
verwenden, auch hier 2 Stopbits.


Dazu muss man allerdings das Kabel oder die DSUB-Buchse modifizieren, 
weil sonst ein Error kommt.
An der Dsub9-Buchse sind tatsächlich nur die Pins 2, 3 und 5 
angeschlossen, nicht einmal Shield liegt auf Gnd.

Um den copy-Befehl auf die Serielle zufriedenzustellen, müssen die Pins 
1,6,7,8,9 miteinander verbunden werden.

Zu der fackernden LED im Stop-Mode: hier wäre ein retriggerbares 
Monoflop das richtige, d.h. sobald ein Triggerereignis eintritt, wird 
ein Zähler wieder auf seinen Anfangswert (z.B. 50) gesetzt, um dann jede 
Millisekunde heruntergezählt zu werden. Solange er ungleich 0 ist. 
leuchtet die LED.
D.h. bei Signalen über 20 Herz soll die LED durchgehend leuchten.

Die kurze Leuchtdauer soll auch für das Leuchten bei Triggerauslösung 
gelten, hier leuchtet die LED etwas zu lange.

Lieber Hayo, ich habe großen Respekt vor Deinem Durchhaltevermögen und 
Deiner Konsequenz.
Vielen Dank von meiner Seite, dass Du alle meine Vorschläge umgehend 
realisiert hast.

Ist es möglich, das Menü für die LED-Steuerung zu erweitern?
Es wäre toll, wenn man bei der rechten LED zusätzlich auswählen könnte, 
ob sie bei einem potentiellen Trigger (trigger) aufblitzt oder nur bei 
einem tatsächlich ausgelöstem Trigger (trig'd = triggered).
Der Punkt "use Ch4-LED" sollte eigentlich eine separat aktivierbare 
Checkbox sein, um die LED umzuleiten, unabhängig von ihrem Modus.

Genauso könnte es man auswählbar machen, ob ein Druck auf Single im 
NORM-Mode
 - auf single schaltet (wie es momentan ist) oder
 - einen manuellen Trigger auslöst (was ich bevorzuge, man muss dann 
über Stop gehen, wenn man auf Single will.)


Noch was zur Spannungsanzeige des Triggerlevels: die stimmt nicht exakt 
mit der Voltage/Division überein. bei 50mV/div und Triggerlinie exakt 
ein Kasterl daneben wird 52mV angezeigt.

Zur Anzeige und Schrittgröße beim Drehen an der PreTrig-Time: die 
Anzeige sollte immer 3 gültige Stellen haben (ist von 9,0 bis 9,9 ms 
nicht der Fall) und eine Rastung soll sich immer auf die letzte Ziffer 
beziehen. Jetzt muss man z.B. 13 Rasten drehen, um von 99,0 auf 100,0 ms 
zu kommen  (oder 2 Rasten von 10,1 auf 10,2).

Oder man macht die Einstellung exponentiell, indem die Schrittweite 
immer z.B. 1% des angezeigten Wertes beträgt.
Und diese Schrittweite wünsche ich mir per Druck auf den Drehknopf z.B. 
zyklisch aus drei-acht Werten auswählen zu können (z. B. 1, 2, 5 digits, 
1%, 2%, 5% des momentanen Wertes).

Das sind viele Wünsche, ich weiß.
Bis demnächst

Autor: Niklas O. (nevm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

bzgl. Firmware v2.13:

Ich habe da einen merkwuerdigen Bug gefunden, den ich wie folgt
100%tig reproduzieren kann:

(1) Zeitbasis <= 50ns/Div
(2) Kanal 3 oder 4 aktivieren
(3) "Center Channel" Softbutton druecken

Bildschirmausgabe dann wie im ersten Screenshot. Tritt jedoch nicht 
bei Kanal 1 u. 2 auf.

Verschiebe ich Kanal 3 per Hand ein paar Pixel nach oben, kann ich gar
die Ausgabe wie im zweiten Screenshot provozieren.  Dies funktioniert
jedoch nicht bei Kanal 1, 2 und 4.

Verschiebe ich die Kanaele wieder woanders hin sind die Fehler weg.

Ob ich im Display Menue bei "Switch Drawing" Line() oder vertical pixel
eingestellt habe macht keinen Unterschied.

Der Bug tritt auch bei anderen, etwas langsameren Zeitbasen auf,
allerdings nicht genau in der Mitte.

Default-Setup und Abgleich habe ich vorgenommen.  Ich habe das W2024A.
Vorherige Firmware-Version war die 2.10, dort habe ich den Fehler
nicht beobachtet.

Niklas

Zusatz:  Lasse ich mir den Trace im Bug-Zustand auf RS232 als CSV
ausgeben finden sich viele Werte fuer den betroffenen Kanal mit 0
und 254, d.h., vermutlich ist es kein reiner Fehler bei der Zeichnung.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ihr Beiden,

danke für die Rückmeldung. Ich bin leider dieses Wochennde etwas knapp 
an Zeit, aber Eure Beiträge sind zur Kenntnis genommen. Ich muß mal 
sehen ob ich morgen oder übermorgen Abend dazu komme mich damit etwas 
näher zu beschäftigen.

Gruß Hayo

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch was, vielleicht hilft es Dir, Hayo, bei der Fehlersuche: Die 
Anzahl, wie oft auf Single gedrückt werden muss, bis ein Trigger 
ausgelöst wird, hängt von der Zeitbasis ab:
  1ms   1x
  2ms   2x
  5ms   4x
 10ms   8x
 20ms  16x
 50ms  32x
100ms  64x


@branadic: auch ich denke, dass man keine Widerstände selektieren 
braucht, sondern dass die Korrekturfaktoren eingebbar sein sollen. So 
kann man x-beliebige krumme Verstärkungsfaktoren wählen, um z.B. den 
ADC-Eingangsbereich optimal zu nutzen. Allerdings weiß ich nicht, ob 
ohne HW-Mul das von der Performance her sinnvoll ist.

Auf jeden Fall freut es mich, dass wieder alle an einem Strang ziehen 
und es zügig vorangeht. Ich komme ja kaum mit dem Flashen hinterher  ;-)

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Niklas,

es hat mir keine Ruhe gelassen. Ich habe mal versucht das nachzustellen, 
aber ich kriege es nicht hin. Welche Hardwareeinstellung hast Du 
gewählt?

Kann das noch jemand hier nachstellen, oder ist das ein spezielles 
Problem von Niklas?

Gruß Hayo

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

> es hat mir keine Ruhe gelassen. Ich habe mal versucht das nachzustellen,
> aber ich kriege es nicht hin.

Mhm, gerade, nachdem das Geraet fuer eine Stunde aus war, habe ich
es auch nicht sofort wieder reproduziert bekommen, erst nach
"Utility->Calibrate Offsets" klappt es wieder 100%tig.

(Nach "Warmlaufen" des Oszis kann ich btw. eine Verschiebung der
Nullinien gegenueber Kaltzustand feststellen, vllt. ist
zum Reproduzieren daher ein frisches "Calibrate Offsets" noetig.)

> Welche Hardwareeinstellung hast Du gewählt?

Du meinst "Utility->More->Hardware"?
ADC -> Factory
PreGain -> Factory

zudem in "Utility->More":
Delays: Ch1: 8ns / Ch2: 0ns / Ch3: 5ns / Ch4: 5ns

Das Geraet ist bis auf Schirmblech und zwei SMD LEDs beim Trigger
unveraendert.

Ich sehe auch gerade das branadic oben in seinem Beitrag vom 19.2.:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
einen aehnlichen Effekt beobachtet hat.

Niklas

Autor: Niklas O. (nevm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

ich habe die alte v2.10 mal ins RAM geladen, um zu schauen,
ob das Problem wirklich dort nicht auftaucht.

Ergebnis:  Auch bei v2.10 habe ich den Effekt bei Kanal 3 und 4,
allerdings nicht genau auf der Bildschirmmitte sondern etwas
versetzt (3-10 Pixel) nach oben.  Da ich meist "Center Channel" bzw.
"Dispatch Channels" benutze ist es mir wohl bislang nicht
aufgefallen.

Ebenso wie Hayo frage ich mich ob es ein isoliertes Problem bei
mir ist oder auch bei anderen 4-Kanal-Geraeten auftritt.

Wer testen moechte:
(1) Zeitbasis auf 50ns/Div einstellen, Trigger auf "Auto"
(2) Kanal 3 oder 4 auf Bildschirmmitte ("Center Channel")
(3) Pixelweise nach oben (oder unten) verschieben

Weiter frage ich mich, ob es sich um ein thermisches Problem
handeln koennte, da die Anzahl Ausreisser mit Aufwaermen des Oszis 
zuzunehmen scheinen.  Allerdings erklaert das nicht, warum der Fehler
beim Verschieben des Traces verschwindet bzw. ueberhaupt anscheinend
nur in der Bildschirmmitte auftritt.

Das sieht fuer mich daher eher nach einem Bug in der
Softcore-Firmware aus.

Anbei nochmal ein charakteristischer Screenshot, FW v2.10.

Niklas

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bevor ich verschwinde und bei meinen Schwiegereltern die Bude entrümple 
noch ein Gedanke:

Stell doch mal alle Delays auf 0ns und probier es nochmal.

Gruß Hayo

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

> Stell doch mal alle Delays auf 0ns und probier es nochmal.

Macht leider keinen Unterschied.  Auch die anderen Einstellungen
zu ADC und PreGain scheinen keinen Einfluss zu haben.

Niklas

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas O. schrieb:
> Wer testen moechte:

Hab' ich getan mit 'Default Setup' und dann wie oben. Bei mir am W2024A 
mit FW BF2.13 ohne Befund. Kommt mir wie ein klemmendes oberstes Bit 
vor? Hast du mal von außen ein Analogsignal (Sägezahn/Sinus) 
draufgegeben und beim Nulldurchgang geguckt?

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den gleichen Verdacht mit dem verklemmten Bit hatte ich auch schon.

Vorschlag zur Fehlersuche:

Auf der Platine des geöffneten DSO auf die Chips drücken. Teilweise sind 
die Lötverbindungen an den SMD-Bauteilen nicht optimal und verursachen 
dann so komische Effekte. Ich glaube Kurt hatte das mal an den 
RAM-Bausteinen.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann mir keine Ursache in der Platinenhardware vorstellen, die einen 
solchen Effekt verursachen sollte. Wenn die Daten digitalisiert und erst 
einmal im FPGA gelandet sind, wie sollen da die Bit kippen, wenn nicht 
gerade ein Fehler im FPGA oder in der Firmware vorliegt, das irgendwo 
irgendwelche Überläufe o.ä. stattfinden.
Ich habe bspw. auf Kanal 2 den Effekt, dass die "zufälligen" Spikes nur 
zur Signalhälfte kippen. Das kann kein Fehler der Platinen-Hardware 
sein, zumal mit Alex Design derartige Effekte bisher überhaupt nicht 
beobachtbar sind.

branadic

Autor: Niklas O. (nevm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo und Rainer,

scheint in der Tat ein klemmendes Bit zu sein.

Gerade wie vorgeschlagen nen Sinus angelegt.  Die Fehlwerte
treten genau wie erwartet beim Nulldurchgang auf.

Anbei Screenshot.  Nicht wundern, ich habe leider hier nichts
besseres als 750 kHz aus nem XR2206-basierten Generator und
bei Zeitbasen >100ns/Div treten die Ausreisser zu selten auf
als das ich das mit einem Screenshot haette aufzeichnen koennen.

Die Ursache ist damit wohl geklaert, danke an euch fuer den Tipp.
Kalte Loetstellen wuerden dann auch die beobachtete
Verschlimmerung bei Erwaermung erklaeren.

Aufschrauben und evtl. Nachloeten verschiebe ich aber erstmal
bis auf unbestimmt.

Niklas

Update:  Urgs, zweimal den selben Screenshot.  Kann man anscheinend
auch nicht wieder entfernen.

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas O. schrieb:
> Anbei Screenshot.  Nicht wundern, ich habe leider hier nichts
> besseres als 750 kHz aus nem XR2206-basierten Generator und
> bei Zeitbasen >100ns/Div treten die Ausreisser zu selten auf
> als das ich das mit einem Screenshot haette aufzeichnen koennen.

Sieht doch super aus. Meine Interpretation ist, dass das oberste Bit 
etwas verspätet schaltet und dadurch am Nulldurchgang steigend (0xFF -> 
0x00) gerne 0x80 auftritt bzw. fallend (0x00 -> 0xFF) der Wert 0x7F. Das 
wären dann Peaks nach Minus-FS bzw. nach Plus-FS. Der erste Fall ist 
genau in deinem Bild zu sehen. Am fallenden Nulldurchgang würde ich 
entsprechend einen Peak nach "+" erwarten. Das Problem wäre dann an 
einer Stelle, wo die Werte als 2er-Komplement vorliegen.

Die Verzögerung muß natürlich nicht zwingend durch eine schlechte 
(hochohmigere) Lötstelle entstehen, sondern kann auch an einem 
Timingfehler und temperaturabhängigen Toleranzen im FPGA liegen, was 
sich dann mit branadics Interpretation decken würde.

Hast du einen anständigen Lüfter drin?

Gruß
Rainer

Autor: Niklas O. (nevm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

Rainer schrieb:
> Der erste Fall ist genau in deinem Bild zu sehen.
> Am fallenden Nulldurchgang würde ich entsprechend
> einen Peak nach "+" erwarten.

Ich habe das ganze mal >5 Minuten mit "Display->Persist"
aktiviert bei 1us/Div aufzeichnen lassen.  Deine
Erwartung trat dort nicht ein, wobei wie gesagt
bei diesen langsamen Zeitbasen die Ausreisser selten
auftreten.  (Screenshot 1)

Ich habe auch mal die Amplitude (und damit die Steilheit
auf dem Screen) stark erhoeht und mir den fallenden
Nulldurchgang bei 50ns/Div angeschaut.  Dort sehe ich
dann die von Dir erwarteten "+" Peaks.  (Screenshot 2)
(Im aufsteigenden Durchgang entsprechend "-".)

Was ich nicht verstehe ist aber, warum ich, wenn ich den
Trace nach unten verschiebe, die Spikes weiterhin in
der Bildschirmmitte, und nicht wie ich erwarten wuerde
beim wahren Nulldurchgang, sehe?  (Screenshot 3)

Jetzt bin ich schon sehr irritiert.  Was passiert denn
mit den Werten der 4 interleaveten ADCs pro Kanal bis sie
irgendwann im Softcore ankommen und gezeichnet werden?
(Ich vermute mal dass die Softcore zeichnet, bitte
korrigiert mich wenn ich falsch liege, den Teil der
Firmware habe ich mir nie angeschaut.)

> Hast du einen anständigen Lüfter drin?

Originalluefter mit der Klebestreifen-Modifikation, jedoch
ohne vergroesserte Schlitze aussen.  Also "nein" :)

Niklas

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas O. schrieb:
> Ich habe das ganze mal >5 Minuten mit "Display->Persist"
> aktiviert bei 1us/Div aufzeichnen lassen.  Deine
> Erwartung trat dort nicht ein, ...

Mmmh. Da müßte man jetzt wissen, welche der Abtastwerte bei 1us/div für 
die Darstellung benutzt werden. Die Chancen die entscheidende Wandlung 
zu verpassen, ist da vielleicht schon zu groß und die Peaks, die da in 
die "falsche" Richtung gehen, könnten durch Rauschen entstehen, das da 
gerade in Gegenrichtung läuft (???).

> Was ich nicht verstehe ist aber, warum ich, wenn ich den
> Trace nach unten verschiebe, die Spikes weiterhin in
> der Bildschirmmitte ... sehe?  (Screenshot 3)

Ohne jetzt in den Schaltplan geguckt zu haben, vermute ich, dass die 
Signalverschiebung durch Addition eines Offsets aus dem DAC gemacht 
wird. Die ADCs messen immer bezogen auf die Bildschirmmitte (Man möge 
mich bitte korrigieren, wenn ich da falsch liege)

> Jetzt bin ich schon sehr irritiert.  Was passiert denn
> mit den Werten der 4 interleaveten ADCs pro Kanal bis sie
> irgendwann im Softcore ankommen und gezeichnet werden?

Gute Frage. Eine Möglichkeit wäre, dass der Peak immer vom selben ADC 
kommt. Aber dann wäre mir nicht klar, wieso Kanal 3 und 4 betroffen 
sind.

Werden die Peaks eigentlich plattgebügelt, wenn du ein Noise Filter 
aktivierst?

Als Lüfter bin ich mit dem "NOISEBLOCK 8X1R" von ex. Angelika sehr 
zufrieden (80 mm und nicht zu hören)

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mein Vorschlag ist immer noch (kostet auch nix) - schraub die 
Rückwand ab, starte das Gerät und provoziere den Fehler. Dann drückst Du 
auf den ADCs des dritten oder vierten Kanals etwas herum - die sind da 
frei zugänglich.

Wenn sich da nix ändert würde ich bei Gelegenheit die Chips auf der 
Rückseite der Platine in Angriff nehmen, aber dazu muß man etwas mehr 
auseinanderschrauben.

Wie gesagt hatte Kurt (wenn ich mich nicht irre) darauf hingewiesen dass 
das durchaus kein Einzelfall ist.

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Wie gesagt hatte Kurt (wenn ich mich nicht irre) darauf hingewiesen dass
> das durchaus kein Einzelfall ist.

Nein, das war wahrscheinlich Bruno. Ich hatte nur mal Lötzinnbrücke 
zwischen 2 Eingängen eines Schieberegisters.

Autor: Niklas O. (nevm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mal was anderes:  Man kann ja, wenn man bereits im
Mode/Coupling-Menue ist, durch abermaliges Druecken
der Taste Mode zwischen Auto, Normal und Combi umschalten.

Ich faende es sinnvoll, wenn eine Umschaltung analog
dazu auch bei Edge (Rising->Falling->Rising->...)
und Pulse Width (Time Qualifier-Variationen), als sowohl
fuer Main/Delayed (Main->Delayed->Main->... (nicht X-Y))
moeglich waere.

Das ganze habe ich gerade mal in 20 Zeilen eingebaut
(alles Ergaenzungen, keine Zeilenaenderungen).
Diff ist im Anhang.  Vllt. kann Hayo das ja bei der
naechsten Version einbauen.

Ansonsten, bzgl. Screenshot/Datendump:  Mittlerweile
benutzen wohl sowohl das Original als auch die
abgewandelte BF-Version die selbe Kompression (und
wohl auch selbes Protokoll).  Unterschied scheint
mir nach kurzem Blick eigentlich nur Verhalten
gegenueber dem Nutzer und moegliche Optionen zu sein.
(Plus Neuerungen wie Ausgabe Einstellungsparameter
bei CSV/ASCII.)

Ich finde es unschoen, da immer noch zwei Versionen
zu haben -- bei fast identischer Codebasis.

Wenn nichts dagegen spricht wuerde ich mich daran
machen, diese wieder zusammen zu fuehren.  Das
gewohnte unterschiedliche Verhalten "OS" vs. "BF"
gegenueber dem Nutzer kann man sicher durch Mitliefern
von zwei Batchdateien mit entsprechend gesetzten
Kommandooptionen beibehalten.

Niklas

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

bin gerade erst zurück.

@Niklas

Die Funktionen die Du da als Diff mitgeschickt hast baue ich natürlich 
mit ein, macht ja auch Sinn.

Auch das mit der Screenshotversion hab ich mir schon überlegt, da hast 
Du natürlich recht. Wir könnten die BF-Version auslaufen lassen und die 
OS-Version auf den Releasestand 1.00 bringen. Mittlerweile ist es ja ein 
"stable release".

Was dann noch übernommen werden müßte ist die Erweiterung bei ASCII und 
CSV, ansonsten funktioniert die OS genauso wie die BF-Version und kann 
aber noch zusätzlich remote triggern und Schwarzweiß-Shots machen. 
Machst Du das?

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, Du könntest den Namen verkürzen wie bei der BF-Version, dann muß 
man nicht immer so viel eintippen, sondern kann das Teil einfach ohne 
Parameter im Defaultmodus starten.

Gruß Hayo

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

> [Screenshot/Dump]
> [Uebernahme Erweiterungen]
> Machst Du das?

Ja.

Niklas

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

zur Vereinfachung der Bedienung habe ich folgenden wahrscheinlich 
einfach umsetzbaren Vorschlag:

Wenn man eine Kanal-Tasten (1..4) zur Aktivierung bzw. Deaktivierung 
eines Kanals drückt, werden in der aktuellen FW die Softkeys für die 
zugehörigen Kanaleinstellungen angezeigt. Wenn man jetzt einen Kanal 
deaktiviert, werden automatisch alle Softkeys disabled, was eigentlich 
niemand wirklich etwas bringt.

Sehr viel praktischer wäre, wenn entweder die Taste "Dispatch Channels" 
aktiv bliebe oder das ganze Menü auf einen der noch aktiven Kanäle 
geschaltet würde. Das ist immer richtiger/besser als ein komplett 
deaktiviertes Menü.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

da hast Du eigentlich recht. Ich versuche das mal zum nächsten Release 
einzubauen.

Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Alex hat das Wiki zum Leon3 etwas aktualisiert. Ich hoffe, dass in den 
nächsten Tagen weitere Infos und das aktuelle Preview hinzu kommen, vor 
allem aber die notwendigen Infos für die Programmierer-Fraktion.

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

Ich habe gestern mal das Design eingespielt und mich ein wenig darin 
umgeschaut. Macht schon einen guten Eindruck, auch wenn sich das 
natürlich nicht mit der aktuellen BF-Firmware vergleich lässt.
Die Geschwindigkeit ist jedoch beeindruckend.

Man sollte dann keine Angst davor haben, dass Design ruhig mal 
einzuspielen.

branadic

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo branadic,

erstmal verstehe ich nur Bahnhof, muss ich wohl mehrmals
durchlesen. Warst du damals mit dem urjtag weitergekommen?
Bei mir hatte es ganz vielversprechend ausgesehen.

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido schrieb:
> Warst du damals mit dem urjtag weitergekommen?

Was meinst du damit? Kann mich nicht erinnern an der Baustelle tätig 
gewesen zu sein.

branadic

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann habe ich das wohl verwechselt. Hatte nur in Erinnerung, dass
jemand das passende BSDL-File gesucht hat und dachte du warst das.

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@brandic

> Man sollte dann keine Angst davor haben, dass Design ruhig mal
> einzuspielen.

Die letzte Previev ist 7 Monate her, gibt es da eine aktualisierte 
W2000a.SOF und -BIN ?
Oder hattest du die vom letzten jahr eingespielt?

Gruß Michael

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> Die letzte Previev ist 7 Monate her, gibt es da eine aktualisierte
> W2000a.SOF und -BIN ?
> Oder hattest du die vom letzten jahr eingespielt?

branadic schrieb:
> Alex hat das Wiki zum Leon3 etwas aktualisiert. Ich hoffe, dass in den
> nächsten Tagen weitere Infos und das aktuelle Preview hinzu kommen, vor
> allem aber die notwendigen Infos für die Programmierer-Fraktion.

Ich denke die Frage hatte ich bereits beantwortet und im Wiki ist es 
auch erwähnt. Es handelt sich um eine neue Preview.

branadic

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Auf der DSO Seite gibt es jetzt keine Unterscheidung mehr zwischen OS
> und BF-Version. Es gibt nur noch die Möglichkeit zwischen den Zielen PC
> und USB-Host zu wählen.

Hallo Hayo,
wo schaltet man das denn um? Wenn ich Quick Print drücke passiert 
garnichts.

Mfg,
Kurt

Autor: Niklas O. (nevm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

anbei das vereinigte "OS+BF" W2000A Screenshot Programm in
der Version 0.94.

In Kuerze das Wichtigste:

Es gab einiges aufzuraeumen.  Im Wesentlichen sollte sich
das Programm wie gewohnt verhalten.  Die Dokumentation ist
updatet und die Kommandooption -h sollte jetzt wieder der
Realitaet entsprechen (wenn nicht ist das ein Bug, bitte melden).

Traces werden jetzt als trace-nnnn.suf und nicht als
screenshot-nnnn.suf gespeichert.  Die Option -r fuer Raw
funktionierte in der OS nicht mehr mit der Firmware und fiel
weg.  Es gibt eine neue Option -a, die, wie bei der BF Version,
so sie fuer Windows kompiliert wurde (und dann auch nur bei
Screenshots), zweimal \a, also Bell/Piepser, ausgibt nach jeder 
Uebertragung.  Zudem werden wie bei BF Parameter wie Zeitbasis,
Ranges, Kopplungen usw. ausgeschrieben.

Die .bat/.sh sind updatet, so dass diese auch funktionieren sollten
wenn man sie von einem anderen Verzeichnis aus ausruft.  Achja,
und die Parameter werden jetzt auch weiter uebergeben.

Damit zukuenftig klar ist, ob die Programmversion zur Firmware
passt, wird dies nun beim Start automatisch abgefragt.

Die Windows-EXE konnte ich nicht mit Scope testen.

Ansonsten:

Wer Ideen hat, was noch eingebaut werden sollte, kann sich gerne
hier melden.  Wenn alles passt und nichts grossartiges mehr
fehlt koennen wir die Version dann demnaechst 1.0 nennen.

Niklas

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super!

Das ging ja schnell!

Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
@Kurt

Es passiert nix? Bei mir sieht es so aus wie auf dem Screenshot, den ich 
übrigens mit der coolen neuen 0.94 gemacht habe - läuft gut!

Wie ist das bei den Anderen? Habt Ihr da Probleme?

Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Niklas

bei mir kommt während der Versionsprüfung die Meldung

 - unknown token:  handleInChar(FF), UartRxGuiCmd: 69

Hat das was zu bedeuten?

Ansonsten funktioniert aber alles bestens.

Gruß Hayo

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Niklas,

fleißig, fleißig. Danke

Niklas O. schrieb:
>
> Die Windows-EXE konnte ich nicht mit Scope testen.

Da geht der Daumen auch hoch - läuft

> Wer Ideen hat, was noch eingebaut werden sollte, kann sich gerne
> hier melden.

Mit der Formatierung des Headers bei ASCII und CSV kann ich noch nicht 
ganz warm werden. Wie wäre es mit etwas Kompakterem/Strukturierterem 
(ggf. <Tabs> vor den Argumenten), z.B.

[Header]
number_of_channels=4
channel_status=on;on;off;on
channel_ranges=5V/div;5V/div;0;5V/div
...
timebase=500KSa/s
values=Ch1;Ch2;Ch3;Ch4

[Data]
83;130;255;171
83;129;255;172
...

Um die Daten in einer Tabellenkalkulation einfach richtig skalieren zu 
können und eine Zeitachse zu generieren, wären die Angaben zu 'Ranges' 
und 'timebase' in zusätzlichen Parametern als reine Zahlen evtl. 
praktisch.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rainer W. schrieb:

> Um die Daten in einer Tabellenkalkulation einfach richtig skalieren zu
> können und eine Zeitachse zu generieren, wären die Angaben zu 'Ranges'
> und 'timebase' in zusätzlichen Parametern als reine Zahlen evtl.
> praktisch.

Ja das hatte ich mir auch schon überlegt, da ja die jetzigen 
Parameterangaben nur informativen Charakter haben, aber nicht gut 
automatisch auswertbar sind.

Hayo

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Hayo:
> bei mir kommt während der Versionsprüfung die Meldung
>  - unknown token:  handleInChar(FF), UartRxGuiCmd: 69
> Hat das was zu bedeuten?

So wie ich das sehe sind in der aktuellen Firmware
Debugging-Ausgaben eingeschaltet, zumindest teilweise.
(Siehe commif_t.cpp, Zeile 4'181.)
Wenn man auf der seriellen Konsole etwas eingibt, z.B. 'h',
kommt auch entsprechend 'handleInChar(68)' zurueck,
gefolgt von der Hilfe-Tabelle.  Dem Screenshot-Program
sind die zusaetzlichen Ausgaben an sich egal.

@Rainer:
> [Formatierung Header]
> Wie wäre es mit etwas Kompakterem/Strukturierterem
> (ggf. <Tabs> vor den Argumenten), z.B. [..]

Ja, das waere sinvoll.  Fuer ASCII sieht Dein Beispiel
schon gut aus, aber ich frage mich wie man das bei CSV
am Besten machen koennte, so dass man nicht manuell
nachbearbeiten und formatieren muss.  Gibt es vllt.
ein nicht zu schwer zu erzeugendes Tabellenformat das
Excel, OpenOffice Calc und so weiter einlesen koennen
welches einfache Formatierungen erlaubt?

@Rainer, @Hayo:
> Um die Daten in einer Tabellenkalkulation einfach
> richtig skalieren zu können und eine Zeitachse zu
> generieren, wären die Angaben zu 'Ranges' und 'timebase'
> in zusätzlichen Parametern als reine Zahlen evtl. praktisch.

Ja das sehe ich auch so.  Sollte man das noch weiter treiben
und gleich im Screenshot-Programm (optional) anbieten die
8-Bit-Zahlen in Spannungswerte umzuschreiben?  Zudem muessen
sicher nicht 16k Samples rausgeschrieben werden wenn die
Zeitbasis in Wirklichkeit mit weniger arbeitet.

Abgesehen davon:
Generell kann ich das Ganze auch so bauen, dass man mit
Templates arbeiten kann.  Man hat also z.B. eine Datei
rainer.tpl, mit Inhalt wie folgt:
[Header]
number_of_channels=%numchannels%
channel_ranges=%ch1range_str%;%ch2range_str%;5%ch3range_str%;%ch4range_str%
[..]
[Data]
_FOREACH_%ch1%;%ch2%;%ch3;%ch4%

...die dann zu Rainers Beispielausgabe expandiert.

Allerdings sollten meiner Meinung nach erst die vorherigen
Punkte klaeren und dies als zukuenftige Erweiterung ansehen.

Niklas

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Niklas,

als importfreundlichen Header könnte ich mir soetwas vorstellen:

[Header]
number_of_channels=<tab>4
channel_status=<tab>on<tab>off<tab>off<tab>off
channel_bandwith_limits=<tab>off<tab>off<tab>off<tab>off
values=<tab>Ch1<tab>Ch2<tab>Ch3<tab>Ch4
[Data]
160<tab>159<tab>152<tab>188

Excel liest das bei Einstellung Trennzeichen="Tab" gut ein.

Für die richtige Skalierung würde ich einfach Sampleabstand in 
Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere 
Headerzeilen aufnehmen.

Der ASCII-Export mit Templates wäre natürlich der wahre Luxus.

Gruß Rainer

Autor: Rainer W. (rawi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Hayo

ich bin da gerade noch auf folgenden Bug bei invertierter Erfassung 
eines Kanals gestoßen: Nach Drücken der STOP-Taste wird der Kanal oft 
nicht invertiert dargestellt.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rainer W. schrieb:

> Für die richtige Skalierung würde ich einfach Sampleabstand in
> Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere
> Headerzeilen aufnehmen.

Der Sampleabstand ergibt sind ja aus der Timebase die bereits übertragen 
wird. Das mit den Skalierungsfaktoren hatte ich auch auf dem Zettel, 
hab's aber erstmal verschoben, da man die float Faktoren auf DSO-Seite 
in Bytes zerlegen muß und auf PC-Seite wieder zusammenbauen muß. 
Grundsätzlich aber eine gute Idee, kann ich auch noch nachreichen (auf 
DSO-Seite).



> ich bin da gerade noch auf folgenden Bug bei invertierter Erfassung
> eines Kanals gestoßen: Nach Drücken der STOP-Taste wird der Kanal oft
> nicht invertiert dargestellt.

Sehe ich mir an und versuche es zu fixen.

Gruß Hayo

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Rainer:
> Excel liest das bei Einstellung Trennzeichen="Tab" gut ein.

Ah, jetzt verstehe ich auch wie Du das mit den Tabs vor den
Argumenten heute Morgen meintest.

Eigentlich koennten wir das Trennzeichen auch gleich frei
konfigurierbar machen.

@Rainer und @Hayo:
> Für die richtige Skalierung würde ich einfach Sampleabstand in
> Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere
> Headerzeilen aufnehmen.

Ich habe gerade mal geschaut wie ich an die Zero-Offsets
(ZeroLevelCh1-4) kommen kann.  Irgendwie scheint man da direkt
nur ueber USB dranzukommen, ansonsten muesste man bei RS232
den Output von ',' parsen.

Uebersehe ich da etwas?  Sonst muessten wir das wohl noch einbauen.

Ansonsten:  Gehe ich richtig der Annahme das ich den Spannungswert
ueber Z/(400/(24*8))+32-X/24*R, wobei Z=Zerolevel [0;400] fuer den
jeweiligen Kanal, X der ausgelesene Wert und R Range, also z.B.
5V/div, errechnen kann?

Niklas

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Das mit den Skalierungsfaktoren hatte ich auch auf dem Zettel,
> hab's aber erstmal verschoben, da man die float Faktoren auf DSO-Seite
> in Bytes zerlegen muß und auf PC-Seite wieder zusammenbauen muß.

Kann man da nicht einfach einen passend normierten Int32 übertragen. Das 
sollte doch reichen, um soetwas wie 1 mV/div bis 500 V/div abzudecken.

Gruß Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Niklas

Da zackern wir nicht lange rum. Alle Werte die Du brauchst schieben wir 
mit über die Schnittstelle als Shot. Sag mir was Du brauchst, ich bau 
das ein.

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem mit dem fehlenden Quick Print Menü ist erledigt. Nachdem ich 
nochmal die 2.12 und dann nochmal die 2.13 installiert hatte war es 
wieder da.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nanu,

ein scwarzes Loch für Menüs? Is ja strange. Aber wenn's jetzt geht ist 
ja alles ok.

Gruß Hayo

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe die Umrechnung zu Spannungswerten am Laufen.
Die noetigen Skalierungsfaktoren und die Zero-Offsets
uebertrage ich im Rahmen der anderen Parameter nach
dem Tracedump.

Es stellen sich jetzt fuer mich, bevor ich weiter
mache, folgende grundsaetzliche Fragen:

(1)  Die unkonvertierten Werte sind ja invertiert,
d.h., fuer eine positivere Spannung sinken die
Werte und vice versa -- was beim direkten Zeichnen
dann natuerlich auch invertiert ist gegenueber dem
Scope-Bild.

Soll dies so bleiben (es kann ja sein, dass es dafuer
einen guten Grund gibt) und nur optional umkehrbar
sein, oder sollten wir, wo wir gerade dabei sind,
das auch "beheben"?

(2)  Schon immer uebertragen wir stets stur 4x16kSa,
auch wenn wir weniger Kanaele haben und auch wenn
wir eine Zeitbasis eingestellt haben die nur mit 4kSa
pro Kanal arbeit (<=25MSa/s).  Das sollten wir
meines Erachtens auch gleich beheben und dem Programm
vom DSO sagen lassen, wie viele (aktive) Kaenele und
wie viele Samples es empfangen wird.

Ansonsten:
Ich wuerde vorschlagen eine neue Kommandooption
einzubinden die festlegt, wie die Daten bei einem
Tracedump (vor)verarbeitet werden.  Ich stelle mir
hier folgendes vor:
  -o [i][mv]
wobei:
  i -> invertieren (siehe oben)
  m -> Werte in mV als ganze Zahlen,
  v -> Werte in V mit 3 Nachkommastellen

Niklas

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Niklas,

* Bei den unkonvertierten Werten wäre ich generell für Invertierung, 
d.h. hohe Werte oben.

* Die Ausgabe würde ich auf die genutzte Speichertiefe beschränken und 
die Kanalanzahl steht ja sowieso schon als Parameter "number of 
channels" im Header. Unter "Values" würde ich immer die originale 
Gerätekanalnummer nennen, damit man ggf. immer die Hardwarezuordnung 
hat.

* Bei der Skalierung kann ich mir vorstellen, dass ganzzahlige mV mit 
dem neuen Frontend knapp sind.

* Bei der Ausgabe von Float gebe ich zu bedenken, dass die Dateien dann 
zumindest unter Windows nicht mehr austauschbar sind, wenn auf den 
Rechnern verschiedene Dezimaltrennzeichen eingestellt sind. Ich würde 
das vermeiden.

* Beim unkonvertierten Tracedump würde ich im Header die 
Skalierungsparameter für jeden Kanal in Form von zwei Werte A und B 
(jeweils Integer) angeben, so dass gilt

  Y = ( X + B ) * A / N    mit z.B. N = 1 / uV

Evtl. ist auch Y = ( X * A + B) / N  günstiger.

Dann hätte man keine Floats und die Umrechnung wäre elementar.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Niklas,

ich sehe schon da geht was. Verstehe ich das richtig, dass Du auch 
gleich die DSO-Seite mit abfackelst?

Dann brauche ich da nichts zu machen und nur die fertigen Sourcen von 
Dir einzupflegen?

Den Invert-Bug habe ich übrigens schon behoben. Morgen habe ich tagsüber 
etwas Zeit, da werde ich mal die bisher aufgelaufenen Punkte abarbeiten.

Ich sag ja, nach der Winterpause geht es wieder richtig los!

Gruß Hayo

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie steht es denn um die Ansteurung der Huckepack Platine?

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

> * Die Ausgabe würde ich auf die genutzte Speichertiefe beschränken und
> die Kanalanzahl steht ja sowieso schon als Parameter "number of
> channels" im Header.

Allerdings wird dieser erst am Ende uebertragen (Hayo hat das so
gemacht damit die OS und aeltere Versionen weiter funktionieren),
aber das koennen wir ja gleich auch aendern.

> Unter "Values" würde ich immer die originale Gerätekanalnummer
> nennen, damit man ggf. immer die Hardwarezuordnung hat.

Da stimme ich zu.

> * Bei der Skalierung kann ich mir vorstellen, dass ganzzahlige mV mit
> dem neuen Frontend knapp sind.

Sollten wir bei -o dazu noch u fuer uV anbieten?

> * Bei der Ausgabe von Float gebe ich zu bedenken, dass die Dateien
> zumindest unter Windows nicht mehr austauschbar sind, wenn auf den
> Rechnern verschiedene Dezimaltrennzeichen eingestellt sind. Ich würde
> das vermeiden.

Mhm, das ist wirklich unschoen.  Gerade geschaut: ist bei OpenOffice
unabhaengig von Plattform auch so.  (Beim Oeffnen der CSV ist im 
Konfigurationsdialog auch gleich die Sprache auswaehlbar, mit 
entsprechend spezifisch gesetztem Default.)

> * Beim unkonvertierten Tracedump würde ich im Header die
> Skalierungsparameter für jeden Kanal in Form von zwei Werte A und B
> (jeweils Integer) angeben, so dass gilt
>   Y = ( X + B ) * A / N    mit z.B. N = 1 / uV
> Evtl. ist auch Y = ( X * A + B) / N  günstiger.
> Dann hätte man keine Floats und die Umrechnung wäre elementar.

Mhm.  Ich waere fuer die erste Variante, da man mit -B dann
den unskalierten Nullpunkt haette.  Fuer einfache Analysen und
Zeichnung reicht dieser Wert zusammen mit den unkonv. Werten aus.

Niklas

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Nachschlag zu den übertragenen Kanälen,

grundsätzlich kann und sollte die Datenmenge anhand der schon jetzt 
übertragenen Parameter Timebase und channel_x_active eingeschränkt 
werden.

Ab Zeitbasis 10µs bis 500ms werden ja nur noch 4K pro Kanal abgetastet 
und wenn man noch die aktiven Kanäle abfragt sollte das die 
Geschwindigkeit im Schnitt doch deutlich erhöhen.

Ich bin gespannt auf die Neuerungen...

Hayo

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

> ich sehe schon da geht was. Verstehe ich das richtig, dass Du auch
> gleich die DSO-Seite mit abfackelst?
> Dann brauche ich da nichts zu machen und nur die fertigen Sourcen von
> Dir einzupflegen?

Ja.  Ich gebe Dir dann fuer die Firmware ein Diff.

> grundsätzlich kann und sollte die Datenmenge anhand der schon jetzt
> übertragenen Parameter Timebase und channel_x_active eingeschränkt
> werden.

Ja.  Kann man sich natuerlich auch drueber streiten ob das Programm
die Grenze fuer 4kSa vs. 16kSa kennen muss oder nur die Timebases
an sich...

Wie gesagt, bislang wird der Header erst am Ende uebertragen, daher
der erste Schnellschuss.

Niklas

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas O. schrieb:

> Wie gesagt, bislang wird der Header erst am Ende uebertragen, daher
> der erste Schnellschuss.

Ja das hatte ich wegen der Abwärtskompatibilität so gemacht. Dadurch 
verträgt sich das auch mit alten Versionen die nur die Werte übertragen.

Den Zopf können wir aber auch abschneiden...

Hayo

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Den Zopf können wir aber auch abschneiden...

Wer etwas dagegen hat, möge jetzt sprechen oder für immer schweigen

Gruß Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon mal vorab - ich habe heute eine ganze Menge geschafft (viele 
kleine Baustellen). Wenn dann noch die Erweiterungen von Niklas dazu 
kommen kann ich nur sagen es gibt wieder viel auszuprobieren :-)

Wenn Niklas das zeitlich hinbekommt könnte das neue Release evtl. 
Sonntag fertig werden.

Gruß Hayo

Autor: Niklas O. (nevm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

anbei die neue v0.95 vom W2000A Screenshot Program mit dem
voellig ueberarbeitetem Tracedump.  Dazu das Diff gegen
die Original Firmware v2.13.  Dieses enthaelt auch die
Aenderungen aus
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"

Zum Ausprobieren dann noch ein Kompilat zum Einladen ins RAM.

Notizen:
- Leider konnte ich die Windows-EXE auch bei diesem Release
  nicht mit dem Scope testen.
- Zum Einbau der Ausgabe der A und B Skalierungswerte, wie
  Rainer sie im letzten Punkt von 
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
  vorgeschlagen hat, bin ich nicht mehr gekommen.
- Mit dem Parameter -p und den darin gueltigen Flags
  v (Volt), m (mV), u (uV)
  sowie q ("quiet", keine Ausgabe des Headers)
  koennen die Daten bei der Ausgabe entsprechend
  vorverarbeitet werden.
  Bsp.:
     ./w2000a-screenshot -d -t ascii -p mq
  schreibt eine trace-0000.asc mit mV-Skalierung
  ohne Header.
- Da -p v mit ganzzahligen Werten wenig Sinn ergibt
  werden bei diesem Modus Stellen nach Komma (Punkt)
  ausgegeben.  (Siehe auch Rainers Hinweise bzgl.
  Float und CSV.)

Niklas

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Niklas,

unter Win klappt mit der 0.94 / 2.14 Ram anscheinend bei der Übertragung 
irgendetwas noch nicht. Wenn ich bei 1ms/div einen Kanal aktiv habe, und 
Save to CSV oder ASCII im QP-Menü drücke, bekomme ich zu sehen:

* Found Data Start Marker after 10s
  - Receiving trace data...
    4100 bytes..._

Der Cursor bleibt hinter "bytes..." stehen und es wird eine leere 
Ausgangsdatei angelegt. Bei vier aktiven Kanälen läuft der Zähler 
entsprechend bis 16400 bytes und dann passiert nichts weiter.
Der Screenshot in eine PPM-Datei ist ok.

Gruß
Rainer

P.S. In der Hilfe (-h) habe ich die Optionen für die Skalierung noch 
vermißt

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

> unter Win klappt mit der 0.94 / 2.14 Ram anscheinend bei der Übertragung
> irgendetwas noch nicht. Wenn ich bei 1ms/div einen Kanal aktiv habe, und
> Save to CSV oder ASCII im QP-Menü drücke, bekomme ich zu sehen:
> * Found Data Start Marker after 10s
>   - Receiving trace data...
>     4100 bytes..._

Kann es sein, dass Du tatsaechlich, wie Du schreibst,
versehentlich die v0.94 benutzt statt der neuen v0.95?
Die Ausgabe waere bei der neuen Version auch anders.

> P.S. In der Hilfe (-h) habe ich die Optionen für die Skalierung noch
> vermißt.

Die sollte unter Misc erklaert sein.

Starte mal bitte die .exe mit -v.

Niklas

P.S.: Ich frage mich gerade ob wir nicht auf DSO-Seite fuer
Screenshot und Tracedump eine Header-Version ausgeben sollten.
Wenn die Version neuer ist als das Programm kennt, verweigert
es den Dienst. Im Moment prueft das Programm nur ob die
Firmwareversion den Mindesanforderungen genuegt und nicht
neuer als 10 Versionen ist.

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Niklas,

Gutes Argument. Kaum macht man alles richtig - schon geht es.
Ich hatte irgendwie die alte Version ausgepackt. Nun ist auch die Hilfe 
vollständig. Anscheinend ist es schon ein bisschen spät. Sorry.

Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle 
am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d 
0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)?

Eine Ausgabe der Versionsnummer ist vielleicht eine gute Idee.

Gruß
Rainer

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

> Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle
> am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d
> 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)?

Mhm, wo mache ich das denn?

Meinst Du vllt. die printf() in Schleifen mit \r (0x0d) vorne?
Das dient dazu, dass ich dieselbe Zeile in der Ausgabe mehrfach
schreiben kann, z.B. um eine Statusanzeige hochzuzaehlen.

Niklas

Update:  Ich glaube Du meintest Hayo.

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurt Bohnen schrieb:
> Wie steht es denn um die Ansteurung der Huckepack Platine?

Ist wohl untergegangen.

Autor: Rainer W. (rawi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Niklas O. schrieb:
>> Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle
>> am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d
>> 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)?
>
> Mhm, wo mache ich das denn?

Die unüblichen <lf><cr>s war mir direkt in den Daten auf der 
Schnittstelle bei den Versionstexten aufgefallen. Da hast du wohl Recht, 
ist wohl Hayo's Baustelle. (siehe Anhang)

Zum Datenformat habe ich noch folgende Anmerkungen:
1) Díe Kanalnamen (CHx) würde ich als Parameter (z.B. channel_name) in 
den Header nehmen, damit unter /[Data]/ reine Zahlen stehen

2) Bei channel_delays würde ich channel_delays_ns angeben, auch 
damit hinten reine Zahlen stehen (Wer weiß wozu?)

3) Bei channel_vzero_levels ist es vielleicht intuitiver, wenn man das 
Vorzeichen ändert, weil man "+" irgendwie doch mit "nach oben 
verschoben" assoziiert. Wenn man die Daten in einer Tabellenkalkulation 
skaliert, spielt das sowieso keine Rolle ob "+" oder "-".

Dann bin ich gespannt, wie das mit den fertigen Skalierungsfaktoren 
wird.

Insgesamt - superschnell und großer Fortschritt auf der Baustelle.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rainer schrieb:

> Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle
> am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d
> 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)?

Nein, hat keinen Grund, ich mache das frei von der Leber weg, da dort 
auch keine Kompatibilitätsprobleme zu befürchten sind.

Ob ich erst den Wagenrücklauf mache und dann die neue Zeile oder 
umgekehrt bleibt unterm Strich gleich.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurt Bohnen schrieb:
> Kurt Bohnen schrieb:
>> Wie steht es denn um die Ansteurung der Huckepack Platine?
>
> Ist wohl untergegangen.

Ja sorry die Frage hatte ich übersehen. Da ich noch keine Zeit hatte die 
Platine bei mir einzubauen ist das noch in Warteposition. Als Erstes 
wollte ich auch mal den 16 Bit DAC einbauen um zu prüfen ob das richtig 
funktioniert. Bei branadic ist ja nicht so richtig klar geworden ob das 
ok ist.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Niklas

Super wie schnell Du vorankommst und was die Screenshot-Schnittstelle 
inzwischen alles kann. Ich freue mich schon auf das nächste FW-Release.

Noch eine Bitte, kannst Du mir zusätzlich zum Diff auch noch die Sourcen 
zukommen lassen? Dann kann ich mir das im Kontext vorher ansehen.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Niklas

Diff ist eingebaut und getestet - läuft gut!

Gruß Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich verfolge dieses Projekt seit längerer Zeit als stiller Leser.
Daher ein Dankeschön an alle die Ihre Freizeit für dieses  Projekt 
opfern.

Ich hätte eine Frage an die Experten.
Ich bin gerade dabei meine Lautsprecherboxen zu verbessern und müsste 
daher
Impedanz Messungen durchführen(über den gesamten Frequenzgang).
Ich möchte die Auswertung und Darstellung mit LabView machen.
Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten.
Gibt es eine Möglichkeit diesen Datentransfer durchzuführen?
Kann man vielleicht im w2000a_schreenshot Programm (v. Niklas) eine 
Funktion hinzufügen die, die selektierten Messdaten von der Funktion 
„Qick Meas“ übernimmt. Und über die Datenschnittstelle an den PC 
weitergibt.

Welec W2012A

Gruß
August

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

> Zum Datenformat habe ich noch folgende Anmerkungen:
> 1) Díe Kanalnamen (CHx) würde ich als Parameter (z.B. channel_name) in
> den Header nehmen, damit unter /[Data]/ reine Zahlen stehen

Beim naechsten Release, bei diesem hatte ich das vergessen.

> 2) Bei channel_delays würde ich channel_delays_ns angeben, auch
> damit hinten reine Zahlen stehen (Wer weiß wozu?)

Ja.

> 3) Bei channel_vzero_levels ist es vielleicht intuitiver, wenn man das
> Vorzeichen ändert, weil man "+" irgendwie doch mit "nach oben
> verschoben" assoziiert. [..] Dann bin ich gespannt, wie das mit
> fertigen Skalierungsfaktoren

Der channel_vzero_levels und channel_scale_factors Kram faellt eh
komplett weg sobald ich die Skalierungswerte A und B eingebaut habe,
von daher keine Anpassung mehr daran.

Niklas

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Niklas
ich hatte vermutet, dass die channel_vzero_levels und 
channel_scale_factors schon die Anfangsstrukturen für die neuen 
Skalierungsfaktoren sind. Aber dann ist ja alles auf gutem Wege.

@August
Die Idee mit der Meßdatenübertragung an den PC finde ich sehr gut.
Eine Sache die ich mir vorstellen kann, wäre ein Kommando, dass man vom 
PC an das DSO schickt und dann kommen die aktiven Quick Measure Werte 
zurück. Wäre das LabView-tauglich?

Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer 
Fernsteuerung des gesamten W2000A vom PC aus aus?

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo August,

> [..] Impedanz Messungen durchführen(über den gesamten Frequenzgang).
> Ich möchte die Auswertung und Darstellung mit LabView machen.
> Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten.
> Gibt es eine Möglichkeit diesen Datentransfer durchzuführen?
> Kann man vielleicht im w2000a_schreenshot Programm (v. Niklas) eine
> Funktion hinzufügen die, die selektierten Messdaten von der Funktion
> „Qick Meas“ übernimmt. Und über die Datenschnittstelle an den PC
> weitergibt.

(1) Zur "Quick Measure"-Datenuebertragung:

Ja, das ist eine gute Idee, schaue ich mir an.  Welches Format
waere da interessant?  Aehnlich wie es bei den Tracedaten
ablaeuft?  Also z.B.:

<code>
[Measurements]
frequency_str=<tab>2.5MHz
frequency_num=<tab>2500000
[..]
</code>

Das Ganze dann zusaetzlich zu einem Trace?  Optional?

(2) Zu LabView und kontinuierliche Messdaten:

Ich selbst habe leider keine Ahnung von LabView.  Ich weiss nicht,
ob sich hier jemand aus dem Forum vllt. schon einmal daran gemacht
hat, einen LabView-Treiber zu implementieren, um das DSO darueber
zu steuern.

Bzgl. der kontinuierlichen Uebertragung der Daten ist zu sagen das
dies zwar bei "Quick Measure" noch gut funktionieren wuerde,
es aber unmoeglich wird bei den Traces, aufgrund (a) der begrenzten
Speichertiefe des Oszis (16kSa/Kanal) (b) der Schnitstelle und nicht
zuletzt (c) wegen des langsamen Softcores.  Ich glaube auch nicht
dass das bei USB grossartig besser wird.

Ob es bei 4 Traces alle 6s noch sinnvoll ist diese "kontinuierlich"
zu uebertragen weiss ich nicht.

Niklas

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer
> Fernsteuerung des gesamten W2000A vom PC aus aus?

Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es 
eine einfache Implementierung, die auf Tastatureingaben eines Terminals 
reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von 
Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung 
hat auch schon jemand für sein Projekt benutzt (Kurt Du?).


> Ich möchte die Auswertung und Darstellung mit LabView machen.
> Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten.
> Gibt es eine Möglichkeit diesen Datentransfer durchzuführen?

Ist auch machbar und war auch mal für USB von WELEC implementiert - 
leider so schlecht dass man es rausnehmen mußte. Nur wie Niklas schon 
sagte wird die Wiederholrate extrem langsam wenn zu viele Daten 
übertragen werden.

Eine Lösung wäre vielleicht wenn nur die 600 Werte des aktuellen Screens 
übertragen würden.

Gruß Hayo

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

>> Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer
>> Fernsteuerung des gesamten W2000A vom PC aus aus?
Das funzte mal mit der originalen Soft von Wittig, allerdings nur mit 
der FW 1.4, hatte aber nur funktioniert, wenn sie dazu Lust hatte, dann 
trampelte die Software manchmal auf der Stelle und es regte sich nichts 
mehr!

> Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es
> eine einfache Implementierung, die auf Tastatureingaben eines Terminals
> reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von
> Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung
> hat auch schon jemand für sein Projekt benutzt (Kurt Du?).
...wo liegt die denn rum???

Gruß Michael

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Niklas

Es gibt noch zwei Werte, die evtl. für die Parameterübergabe interessant 
wären:

- die Pretriggerposition im Speicher (Memory Index 0....16383 / 
0....4095)
  Format ist Integer.

- der Pretriggerwert als float. Während dieser vorher nur lokal 
berechnet wurde habe ich Ihn jetzt global deklariert, so dass er 
jederzeit zur Verfügung steht.

Ich habe die Variablen mal auskommentiert in die CSV-Routine eingetragen 
falls das von Interesse sein sollte.

Hayo

Autor: August (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Niklas

Ich habe eher an eine einfache Übertragung wie bei Digital-Multimeter 
mit RS232 Schnittstelle gedacht.
Die im „Quick Measure“ angezeigten Messwerte ( max 3) könnten  zum 
Beispiel mit dem Voltcraft Protokoll übertragen werden. Ist zwar nur für 
einen Messwert, könnte man aber erweitern.
[[http://blog.dest-unreach.be/2009/05/01/voltcraft-v...]]

Ich werde mich in den nächsten Tagen umschauen welche Protokolle wir 
verwenden könnten.
Der LabView Dateneingang kann an das jeweilige Protokoll angepasst 
werden.

Gruß
August

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

Bewertung
0 lesenswert
nicht lesenswert
Es ist soweit,

wie versprochen die neue Version bei der sich einiges getan hat.

Die Highlights sind:

- Natürlich die neue Screenshot-Version von Niklas mit neuer
  CSV-Übertragung
- neue double push Funktionalität bei Edge-Button, Pulswidth-Button und
  Main-Button ebenfalls von Niklas
- invert Bug ist gefixt
- neuer stabil arbeitender manueller Trigger
- neues Trigger-Submenü mit diversen Einstellmöglichkeiten, zu finden im
  Mode/Coupling Menü. Da sollte für jeden Geschmack was zu finden sein.

Weitere Details entnehmt bitte dem changelog und der Datei
Special Functions.txt



@eProfi

Die Schrittweite der Pre Trigger Einstellung habe ich nicht auf die 
letzte Stelle des Zeitwertes bezogen, sondern auf die Zeitauflösung pro 
Pixel, da mir das sinniger erschien.


Gruß Hayo

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Eine Fernsteuerung gibt es bereits. Zum einen gibt es
> eine einfache Implementierung, die auf Tastatureingaben eines Terminals
> reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von
> Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung
> hat auch schon jemand für sein Projekt benutzt (Kurt Du?).

Die Remotesteuerung wurde seinerzeit von Bruno im FFT-Screener (Matlab) 
verwendet. Leider wurde an dieser Baustelle nicht weitergearbeitet und 
ich komme derzeit nicht dazu mich damit zu beschäftigen, zumal ich eh 
nur auf Arbeit daran werkeln könnte, da der FFT-Screener nicht 
kompatibel zu Octave ist.

branadic

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

Hayo W. schrieb:
>> ... Und wie sieht das eigentlich mit einer
>> Fernsteuerung des gesamten W2000A vom PC aus aus?
>
> Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es
> eine einfache Implementierung, die auf Tastatureingaben eines Terminals
> reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von
> Falk, die recht umfangreiche Möglichkeiten bietet.

Mit "Tastatureingaben..." meinst du das Remote Control Protokoll, was im 
Moment als "suggestion" unter 
http://sourceforge.net/apps/trac/welecw2000a/wiki/... 
beschrieben ist? Dast ist ja noch arg rudimentär und Zukunftsmusik.

Das von Falk außeinandergedröselte USB Protokoll bietet da ja schon 
einiges mehr. Gibt's da Quellcodebeispiele, wie man das unter Win vom PC 
aus nutzen kann?
http://sourceforge.net/apps/trac/welecw2000a/wiki/...

"Set timebase" über Terminal habe ich gerade probiert (mit BT.2.13 FW).
Da tut sich auch etwas, aber außer Debugausgaben kommt nichts weiter 
zurück. Dabei bin ich auf folgende offene Baustelle gestoßen: Die 
Umschaltung ist etwas "eigenwillig", d.h. die Kommandowirkung hängt von 
der vorher eingestellten Zeitbasis ab.
Wenn man z.B. <stx>ET<0x18>... schickt, schaltet das DSO auf 
unterschiedliche Bereiche um, je nachdem wo es vorher stand. (z.B. 
5us/div -> 5s/div, 20s/div -> 1s/div, 100ns/div -> 500ms/div). Außerdem 
kommt man nicht in die ganz langsamen Bereiche, weil Parameter über 
<0x1F> nicht angenommen werden.

Aber ich vermute mal, dass die Baustelle z.Z eher brach liegt, oder?

Schönen Sonntag
Rainer

Edit: Danke für die neue Wochenend-Edition

Autor: gyppe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ciao, sul sito (a proposito ho cambiato indirizzo: www.cheap-hack.com), 
un utente mi ha chiesto se Hayo e voi altri accettate donazioni per 
supportare il progetto, magari tramite paypal o simili, non sono sicuro 
così chiedo qui.


Hello, on the site (recently changed the address: www.cheap-hack.com), a 
user asked me if you Hayo and other, accepted donations to support the 
project, perhaps through paypal or similar, I'm not sure so I ask here.

By, Gyppe.

Autor: gyppe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gyppe schrieb:
> Ciao, sul sito (a proposito ho cambiato indirizzo: www.cheap-hack.com),
> un utente mi ha chiesto se Hayo e voi altri accettate donazioni per
> supportare il progetto, magari tramite paypal o simili, non sono sicuro
> così chiedo qui.
>
>
> Hello, on the site (recently changed the address: www.cheap-hack.com), a
> user asked me if you Hayo and other, accepted donations to support the
> project, perhaps through paypal or similar, I'm not sure so I ask here.
>
> Bie, Gyppe.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich vergaß noch anzumerken, dass ich aufgrund der umfangreichen 
Änderungen gezwungen war die Flasheinstellungen zurückzusetzen. Also 
nicht vergessen das Gerät neu zu kalibrieren und die 
Hardwareeinstellungen neu zu machen.



Please notice that I had to reset the flash. So calibration and hardware 
adjustment is recommended.


@gyppe

- no donation, it is just for fun!

Hayo

Autor: gyppe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sapevo avresti risposto così, ma ho comunque chiesto per correttezza. 
Complimenti sei davvero una persona da ammirare, grazie! :)

Autor: Paolo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
This new firmware version was so good that no one have yet posted!!! 
I've try it to my welec and that's incredible...Thanks at all the 
staff!!
Paolo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thanks for Your kind response Paolo

Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
Leider habe ich noch einige Bugs entdeckt.

Z.B. arbeitete der manuelle Trigger immer noch nicht so richtig unter 
allen Umständen. Jetzt sollte er es aber tun.

Daher noch mal ein Update in dem nur einige Fixes sind aber sonst nix 
Neues.

Hayo

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Ich hab seit ein paar Monaten eure Firmware(s) auf meinem Welec-Oszi und 
möchte mich bei allen Entwicklern hier, vor allem Hayo, mal herzlich 
dafür bedanken, dass ihr in eurer Freizeit unentgeltlich die Arbeit 
macht, die die Fa. Wittig leider nicht macht! Die originale Software mit 
der Wittig die Geräte immer noch ausliefert ist eigentlich eine 
Frechheit!

Inzwischen nehme ich aber doch immer öfters mal das Welec anstatt meines 
20 Jahre alten Hameg's, das ich eigentlich mit dem Wittig ablösen 
wollte...

Vielen Dank!

Gruß, Michael

Autor: Paolo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
New 2.15 version tested. On the welcome screen appear to be a "beta" 
version...
Anyway all the functions that i've can tested are ok. Very good job with 
the filters!!
Thanks again, Hayo and all!!
What's the next step?

Excuse me for the question, but i don't understand German language and 
google translate make a bad job:
What are the benefits on ADC/DAC substitutions that is described on some 
previous messages?

Ciao, Paolo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paolo schrieb:
> New 2.15 version tested. On the welcome screen appear to be a "beta"
> version...

don't worry, I just forgot to delete the "beta"

> What's the next step?

Several little improvements at math-functions and FFT. Hardwaresupport 
for the new input stage of branadic.

> Excuse me for the question, but i don't understand German language and
> google translate make a bad job:
> What are the benefits on ADC/DAC substitutions that is described on some
> previous messages?

the 16 Bit DAC has a finer division at zerolevel adjustment. This is 
only relevant to the 2/0.2/0.02 and 1/0.1/0.01 ranges. It is not really 
necessary but nice to have.

I got the LT2602 as free sample from Linear Technology. They are very 
small and You need to have some experience in soldering SMD parts if You 
want to replace them.

Kind regards
Hayo

Autor: gyppe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Several little improvements at math-functions and FFT. Hardwaresupport
>for the new input stage of branadic.

Great! :)

Autor: Rainer W. (rawi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

die neue Auto-Pre-Trigger Funktion finde ich ausgesprochen praktisch. 
Beim Messen in der Einstellung "Left Edge" hat sich aber gezeigt, dass 
es vielleicht günstiger wäre, das "Left" nicht ganz wörtlich zu nehmen, 
sondern den Trigger auf den ersten Grid Raster zu legen 
(Left_Edge_1_12.png).

Meistens interessiert doch ein bisschen, was vorne los ist ;-)

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Rainer,

gleich vorweg - ich sehe mal zu dass ich das noch als extra Menüpunkt 
mit einbaue.

Zum "Left Edge":

Das ist ja den alten Analog-Oszis nachempfunden. Man stellt ja 
normalerweise die Zeitbasis so ein, dass nach dem Triggerdurchgang etwas 
mehr als eine Periode auf dem Schirm zu sehen ist. Dann hat man nämlich 
auch den am Anfang fehlenden Teil der nächsten steigenden Flanke locker 
mit auf dem Screen.

Dazu kommt, dass viele Signale auch nicht so steil ansteigende Flanken 
haben, so dass auch vom Triggerlevel an die ganze Flanke zu sehen ist.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Etwas Anderes,

ich mache mir gerade Gedanken über die Ansteuerung der Addon Platine. 
Hat schon jemand das Teil eingebaut und kann mir gegebenenfalls 
Testergebnisse liefern?

Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
So ich hab mal wieder was zum ausprobieren für Euch. Ich habe etwas 
rumgespielt nachdem ich für Rainer den neuen Menüeintrag eingebaut 
hatte.

Dabei sind wieder die Spikes aufgetaucht und ich konnte feststellen dass 
die Spikes durch das Verstellen der Timebase verursacht werden.

Einstellung:

- Triggersource Kanal 4
- Combi oder Norm Trigger
- Timebase 50ns
- Signal auf Kanal 4


Alles ist gut. Dann Zeitbasis auf 50µs verstellt und wieder zurück auf 
50ns siehe Bild Test01.

Dann Zeitbasis auf 5µs verstellt und dann zurück auf 50ns - siehe 
Test02.

Dann wieder verstellt und so weiter Test03...Test05.

Wenn man das Gerät ausschaltet und wieder einschaltet ist alles wieder 
gut.

Ist das bei Euch auch so?

Gruß Hayo

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, hatte ich letzte Woche und gerade dann, wo ich es nicht brauchen 
konnte!
Allerdings sporadisch, manchmal auf Kanal 1 dann mal auf Kanal 2 
(W2022), wie es gerade Lust hat!
Gemessenes Signal war 57 kHz Rechteck an einem LM2576 Adj. Dachte schon, 
jetzt ist er hinuber!!
 Die Grundlinie über das Display scheuchen, brachte auch keine 
Besserung.
An der Warmlaufphase scheint es aber nicht zu liegen, da das DSO schon 
über eine Std. lief. Nach neuem hochfahren, war wieder alles hübsch...

Gruß Michael

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha,

ich bekomme das nur auf Kanal 3 + 4 hin.

Gruß Hayo

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehe gerade, du hast 16V Sägezahn!?! Ich hatte bei der Restripplemessung 
dieselbe Einstellung wie du 2V/DIV, 50nS und Combitrigger "AC", ob das 
bei "DC" auch der Fall ist?
Wenn du das provozieren kannst, dann prüf' das doch mal...

Gruß Michael

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich melde mich mal kurz.

Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen
uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff.
Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h
gebraucht (Wegspeichern der in RenderText() berechneten Werte
fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der
Dimensionierung).

Die Ausgabe sieht dann so aus (echte Werte):
meas-000.txt
[measurements]
str=;dX =   5.4 us;1/dX = 185 kHz;dY 1 =  29 mV
desc=;dX = ;1/dX = ;dY 1 = 
dimension=;u;k;m
unit=;s;Hz;V
value_bd=;5;185;29
value_ad=;4;0;0
value_float=;5.4;185.0;29.0

Konkrete Vorschlaege/Anregungen gerne willkommen.

Wir sollten dann vllt. noch aus den Softbuttons "Save to BMP",
"Save to PPM", "Save to CSV" usw. einfach "Screenshot",
"Trace" und "Measurements" machen, wobei dann das Format
ueber ein Untermenue konfigurierbar wird.

@August:
Wenn Du moechtest kann ich Dir kompilierte TomCat.flash/.ram
geben damit Du das Ganze schon nutzen kannst.

Bezueglich meiner Spikes auf Kanal 3+4 beim Nulldurchgang
auf dem DSO:

Ich hab' Sonntag auch noch das Geraet aufgeschraubt und mal,
wie Hayo vorschlug, auf die ADCs gedrueckt ob sich da was
aendert.  Negativ.  Da das ganze Board ziemlich warm war
hab' ich einen starken 80mm Luefter (~6 Watt) rausgekramt
und bei offenen Geraet direkt gegen die Platine blasen
lassen.  Das verminderte die Anzahl Spikes jedoch nur gering.
Nochmal komplett Front abnehmen, um auf die andere Seite
der Platine zu schauen, will ich erstmal nicht, zu wenig Zeit.

Was Hayo zuletzt bei sich auf Kanal 3+4 mittels Saegezahn
reproduzieren kann, kann ich mangels schnellem Signalgenerator
nicht pruefen.  Bei mir treten die Stoerungen aber wie gesagt
auch erst bei 50ns sehr haeufig auf.

Niklas

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas O. schrieb:
> Hallo,
>
> ich melde mich mal kurz.
>
> Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen
> uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff.
> Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h
> gebraucht (Wegspeichern der in RenderText() berechneten Werte
> fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der
> Dimensionierung).

Währe es nicht einfacher den Float-Wert global zu deklarieren und dann 
per Multiplakation als Integer zu übertragen?


> Wir sollten dann vllt. noch aus den Softbuttons "Save to BMP",
> "Save to PPM", "Save to CSV" usw. einfach "Screenshot",
> "Trace" und "Measurements" machen, wobei dann das Format
> ueber ein Untermenue konfigurierbar wird.

Das wäre eine Möglichkeit, ich mach mir mal ein paar Gedanken dazu

> @August:
> Wenn Du moechtest kann ich Dir kompilierte TomCat.flash/.ram
> geben damit Du das Ganze schon nutzen kannst.
>
>
> Ich hab' Sonntag auch noch das Geraet aufgeschraubt und mal,
> wie Hayo vorschlug, auf die ADCs gedrueckt ob sich da was
> aendert.  Negativ.  Da das ganze Board ziemlich warm war
> hab' ich einen starken 80mm Luefter (~6 Watt) rausgekramt
> und bei offenen Geraet direkt gegen die Platine blasen
> lassen.  Das verminderte die Anzahl Spikes jedoch nur gering.
> Nochmal komplett Front abnehmen, um auf die andere Seite
> der Platine zu schauen, will ich erstmal nicht, zu wenig Zeit.

Ich habe bei meinem W2022A einen 80iger Lüfter eingebaut der bei 9V so 
gut wie keine Geräusche macht (drei andere Lüfter die ich ausprobiert 
hatte waren etwas nervig). Das ist wirklich angenehm und es wird 
wirklich ordentlich warme Luft aus dem Gehäuse gedrückt.

Der Wackler könnte natürlich durchaus auch auf der anderen Platinenseite 
liegen. Ausprobieren lohnt sich allemal.

Beim Abhebeln der teilweise festsitzenden Knöpfe gehe ich immer so vor:

von oben in den Spalt zwischen Knopf und Frontplatte linsen während man 
den Knopf dreht. Irgendwann kommt die abgeflachte Seite der Achse 
vorbei...

Dann mit einem dünnen Schraubendreher dazwischengehen und mit der 
flachen Seite des Schraubendrehers den Rand an der Achse als 
Abstützpunkt beim Hebeln benutzen. Dadurch entlastet man den Rest des 
Drehgebers.


> Was Hayo zuletzt bei sich auf Kanal 3+4 mittels Saegezahn
> reproduzieren kann, kann ich mangels schnellem Signalgenerator
> nicht pruefen.  Bei mir treten die Stoerungen aber wie gesagt
> auch erst bei 50ns sehr haeufig auf.

Es tritt nicht nur bei 50ns auf, aber bei 50ns und kleiner werden alle 
vier ADC dargestellt und dadurch auch alle Störungen, während bei
den TB > 50ns immer nur 1 oder 2 ADC zur Anzeige kommen.

Da "verschwinden" die Spikes teilweise scheinbar.


Gruß Hayo

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

>> Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen
>> uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff.
>> Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h
>> gebraucht (Wegspeichern der in RenderText() berechneten Werte
>> fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der
>> Dimensionierung).
>
> Währe es nicht einfacher den Float-Wert global zu deklarieren und dann
> per Multiplakation als Integer zu übertragen?

Ginge auch, dann wuerden jedoch die Dimensionierung wegfallen.
Es sieht im Moment so aus:
void FloatStr::RenderText(void)
Am Ende:
        // copy values to protected variables for readout via Read_Int(B/A)Dot()
        Value_BDot = intbd;
        Value_ADot = intad;

> [..]
> Ich habe bei meinem W2022A einen 80iger Lüfter eingebaut der bei 9V so
> gut wie keine Geräusche macht (drei andere Lüfter die ich ausprobiert
> hatte waren etwas nervig). Das ist wirklich angenehm und es wird
> wirklich ordentlich warme Luft aus dem Gehäuse gedrückt.

Ja.  Rainer hat mir oben auch schon einen leisen Luefter bei Reichelt
vorgeschlagen den er bei sich verbaut hat.  Das Problem mit dem 80er,
den ich Sonntag benutzt habe:  Der zieht 0,47A.  (Abgesehen davon
dass er hoellisch laut ist.)
Der Original war iirc. weit unter 0,1A.  Bei der naechsten Pollin-
oder Reichelt Bestellung bestelle ich einen entsprechenden Luefter
mit.

> Beim Abhebeln der teilweise festsitzenden Knöpfe gehe ich immer so vor:

Beim letzten Mal, Anloeten der zwei Trigger-LEDs, Osrams in SMD,
hab' ich da schon viel Freude mit gehabt...  (sind btw. hell
genug dass die ohne Modifikationen durch den Silkscreen
durchscheinen.)

Wo wir bei den Drehgebern sind:

Bei Yokogawa hab' ich eine nette Vereinfachung bzgl. des
Verschiebens der Traces gesehen:
Wenn man die Drehencoder schnell dreht springen die Traces
von Gridline zu Gridline, bei langsamen Drehen wie gewohnt
Pixelweise.  Vmtl. haben das die anderen hochwertigen
Scopes aber auch.

Ich hab' das ganze auch schon mal kurz angetestet,
sieht dann im Code so aus:
void UserIF::ON_Zero_Channel_1(void)
[..]
   if (Rotary_Direction == 0)      //clockwise rotary direction
[..]
        else    //Main mode TY
        {
                if (rotbuf > 8) { // rotbuf -> Anzahl Schritte
                        int a, b, c;
                        // a positiv machen
                        a = Virtual_ZeroLevelCH1 + 4096;
                        // naechstgelegene Gridlinie,
                        // vllt. hier noch anders runden
                        b = a/50;
                        // zur naechsten Gridlinie springen
                        c = (b+1)*50;
                        // Zurueckskalieren und Wert setzen
                        Virtual_ZeroLevelCH1 = c - 4096;
                } else {

Analog dasselbe fuer die andere Drehrichtung.  Der ganze
bestehende Code hierzu liesze sich btw. deutlich verkuerzen.

...Und funktioniert soweit.  Ist etwas "wackelig", was aber
an dem miserablen Response des Scopes liegt, woran wir
aber wohl ohne das neue FPGA Design nichts aendern koennen.

Ansonsten muss ich wohl eh nochmal an die Front dran, da
beim W2024A fuers JTAG eine Loetbruecke fehlt und ich sonst
nicht das neue Design ausprobieren kann.

Niklas

Autor: Roberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo

zu den Spikes: (hatte ich schonmal geschrieben)
Kannst Du die Frequenz von deinem Generator auch ändern?
Bei mir änderten sich die Spikes auch mit der Frequenz bei gleicher 
Zeiteinstelleung am DSO
l.G. Roberto

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Niklas

> Ginge auch, dann wuerden jedoch die Dimensionierung wegfallen.
> Es sieht im Moment so aus:void FloatStr::RenderText(void)
> Am Ende:
>  // copy values to protected variables for readout via Read_Int(B/A)Dot()
>      Value_BDot = intbd;

Verstehe, Du benutzt die Instanzmethode readout() um Dir den Wert zu 
besorgen, das scheint mir ganz elegant zu sein. Wenn Du mit Deinen 
Änderungen soweit bist kann ich das ja mit einbauen.


> Wenn man die Drehencoder schnell dreht springen die Traces
> von Gridline zu Gridline, bei langsamen Drehen wie gewohnt
> Pixelweise.

Hört sich interessant an, werde ich mal übernehmen und testen.


@Roberto

> Bei mir änderten sich die Spikes auch mit der Frequenz bei gleicher
> Zeiteinstelleung am DSO

Das muß ich mal testen, hört sich ja merkwürdig an.

Gruß Hayo

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es gibt einen 80er Lüfter von Papst glaube der macht nur 9 dB, habe 2 
davon in meiner PC Front die sind nur hörbar wenn  man den Kopf an die 
Front des PCs steckt. Man muss allerdings auch sagen das der nicht ganz 
so viel Durchsatz hat wie andere 80er Lüfter.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
By the way...

> was aber
> an dem miserablen Response des Scopes liegt, woran wir
> aber wohl ohne das neue FPGA Design nichts aendern koennen.

Ich habe mal die USTB-Timerwerte nachgerechnet und habe die akute 
Vermutung, dass unsere Büchse nicht wie bisher angenommen mit 33MHz 
läuft, sondern nur mit 25MHz.

Das würde natürlich auch Einiges erklären...

Hayo

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also auf ans Übertakten ;-) ist da ein externer Taktgeber drauf oder 
taktet der FPGA intern?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte auf dem Board einen 25MHz Quartz gesehen. Die Frage ist aber, 
ob dann das Timing mit den ADCs noch stimmt.

Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Niklas

Ich habe Deine Idee mal aufgegriffen und etwas umgestrickt. Das sieht 
dann so aus und funktioniert ganz gut:


else  // main mode
{
   if (rotbuf > 10)
   {
      int div, cmp;
      div = Virtual_ZeroLevelCH1/50;  // in which div we are?

      if(Virtual_ZeroLevelCH1 > 0)  // positive
      {
     cmp = div * 50;
     if (cmp == Virtual_ZeroLevelCH1){div--;} // zero level was on grid 
division before
       }
       else                 // negative
       { div--; }    // next grid division

      Virtual_ZeroLevelCH1 = (div)*50;    // set zerolevel to next grid 
division
  }


Hayo

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> also auf ans Übertakten ;-) ist da ein externer Taktgeber drauf oder
> taktet der FPGA intern?

...den Vorschlag hatte ich letztes Jahr schon mal gemacht! Im Datenblatt 
müsste ja stehen, was der Prozessor maximal so abhaben kann.

Gruß Michael

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normal ist der für 33MHz ausgelegt (im NIOS I Design). Deshalb bin ich 
ja auch erstmal davon ausgegangen dass es so ist. Nur haben mich die 
Timerwerte bei den USTB etwas irritiert, da die iterativ ermittelten 
Werte nicht zu den vorher berechneten Werten passten. Die jetzt 
verwendeten Werte passen zu einer Taktfrequenz von 25MHz und einem Timer 
der mit halber Taktfrequenz läuft.

Man könnte ja mal den 25MHz Quarz-Oszillator gegen einen 33iger tauschen 
und dann mal gucken ob es funktioniert (alle Timerwerte müßte man 
natürlich anpassen).

Evtl. könnte es Problem mit den ADCs geben. Irgend einen Grund muß es ja 
geben, dass die auf einen Teil der Performance verzichtet haben (man 
läßt sich ja auch nicht freiwillig ein Bein in Beton eingießen oder?).

Gruß Hayo

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

Bewertung
0 lesenswert
nicht lesenswert
nun ja, vielleicht wollten die "Welec-Designer", zur Sicherheit unter 
dem Limit bleiben, damit das Teil nicht abschmiert?!?
Ein höherer Takt zieht mehr Leistung und somit auch mehr 
Wärmeentwicklung, also muß auch mehr Kühlung her, dürfte ja kein Problem 
sein
Den Mega8-16PU, habe ich mal mit 33MHz takten lassen, der wurde nicht 
mal warm.

Ich lege mal 2 Auszüge des Altera EPCS16 bei, schau mal rein.
Da steht nur was von der Write Clock Frequency...

Gruß Michael

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh, habe ich hier das falsche Datenblatt erwischt???

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Man könnte ja mal den 25MHz Quarz-Oszillator gegen einen 33iger tauschen

Bei dem jetzt schon extrem kritischen FPGA-Timing? Nach dem Tausch wird 
garnichts mehr funktionieren!
Eine weitere Frage ist, was die DCM(PLL) macht, wenn sie plötzlich 
übertaktet wird.

Mfg,
Kurt, der noch lebt, aber krank war und sich nur langsam erhohlt.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bei dem jetzt schon extrem kritischen FPGA-Timing? Nach dem Tausch wird
> garnichts mehr funktionieren!

Das vermute ich auch, aber es wäre vielleicht einen Versuch wert. Ich 
denke kaputt gehen wird wohl nichts, aber es wird wohl nicht sauber 
laufen.


> Kurt, der noch lebt, aber krank war und sich nur langsam erhohlt.

Gute Besserung!

Hayo

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielleicht sollte man das neue FPGA-Design gleich auf die höhere 
Taktrate ausrichten 33 MHz sind immerhin ein Zuwachs über 30%

Autor: Michael H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im neuen Design arbeitet kein NIOS mehr, daher erübrigt sich die Frage 
der Taktung desselben...

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der Leon braucht keinen externen Takt mehr?

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

Bewertung
0 lesenswert
nicht lesenswert
Eure Meinung ist gefragt.

Ich habe die Idee von Niklas mit den Rasterschritten beim Verstellen des 
Zerolevels mal für Kanal 1 und 3 eingebaut.

Bei Kanal 2 + 4 ist noch alles beim Alten. Ich bin etwas unschlüssig ob 
das besser ist als das Alte oder nicht. Wie seht Ihr das?

-> Die Triggermenüerweiterung für Rainer ist auch schon drin zum 
Probieren.

Gruß Hayo

Autor: alex008 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Um das mit dem Takt noch mal abzuklären: Der CycloneII FPGA hat 4 PLLs. 
Jede PLL besitzt eigene Takteingänge und einen Taktausgang!. Damit muss 
man den Quarz zwangsweise an allen vier PLL-Takteingängen anhängen.
Es sind neben den vier Takteingängen für die PLLs noch andere Takte 
vorhanden. Sollte das NOIS I Taktnetzwerk sauber mit der 
Signalerfassungsnetzwerk kommunizieren können und einen eigenen 
Takteingang haben (beim LEON3 mache ich das beabsichtigt nicht), dann 
könnte man die Taktgeschwindigkeit erhöhen.
Für die vier zeitversetzten Taktsignale der ADCs ist das nicht 
empfehlenswert, da dadurch die gleichmäßige Abstastung noch mehr 
zerstört wird!

MfG
Alexander

Autor: Thomas O. (kosmos)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
habe gerade das Prellverhalten eines Jalousinenschalters getestet und da 
sind mir wieder einige Bugs aufgefallen. Und zwar erhalte ich im Single 
Trigger Modus auf Kanal 1 (Kanal 2 nicht getestet) bei einer 
eingestellten Horizontalauflösung von 1V/Div und einer Abtastrate von 1 
mSek/Div keine Auslösung bei einer fallenden Flanke, das Signal ist 5V 
DC das wie gesagt über einen Taster geleitet wird. Bei 2mSek/Div löst 
der Trigger auch häufig nicht aus. Bei den andere Abtastraten geht es 
einwandfrei, bis auf den Umstand das am Ende der Aufzeichnung die ca. 
letze 5 Stellen im Display immer ein Spike 5V vorhanden ist.  Ich 
vermute das die Zeichenroutine hier etwas verhaut und sich oder 
irgendwie ein Überlauf der Adressen stattfindet und wieder Daten aus dem 
vorderem Speicherbereich gezeichnet werden. Beim laden des gespeicherten 
Traces ist dieser Spike plötzlich weg. Gespeichert wird also der 
richtige Bereich, beim Betrachten direkt nach dem Auslösen hingegen 
passt der Speicherbereich nicht 100%tig

Oszi: W2022
Firmwareversion: 1.2.BF.2.7

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man in die Screenshot BF1.6 einen Schalter einbauen um den Sound 
erst damit zu aktivieren oder eine Screenshot.cfg um dort die 
Einstellung dauerhaft vorzunehmen?

Beispiel 1:
scrennshot.exe /s = startet die screenshot.exe Datei mit Soundausgabe
Beispiel 2:
scrennshot.cfg Datei wo Screenshot.exe erst nachschaut was gewünscht 
wird bevor etwas piepst oder nicht
Sound=0 oder 1

Die Familie schläft gerade und nach jeder Dateiübertragung piepst der PC 
Lautsprecher und da hat man ja leider keinen Einfluss auf die 
Lautstärke, wenn ich nicht umbedingt einen Poti einbauen will.

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

> Kann man in die Screenshot BF1.6 einen Schalter einbauen um den Sound
> erst damit zu aktivieren oder eine Screenshot.cfg um dort die
> Einstellung dauerhaft vorzunehmen?

Die BF-Version wurde wieder mit der OS vereint.  Die neuen
Versionen haben einen entsprechenden Schalter, dieser lautet
"-a" (Alarm).  Nur wenn "-a" gesetzt ist bimmelt es.

Eine Konfigurationsdatei wird ohnehin in Zukunft kommen.  Bis
dahin kannst Du die Optionen weiter in die .bat eintragen.
Die ist jetzt auch so gebaut dass man sie von anderen
Verzeichnissen aufrufen kann und ihr zusaetzliche Parameter
uebergeben kann.

Aktuelle Screenshot-Programme sind wie gewohnt auch in den
Firmware-Releases.

Niklas

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal Thomas,

> [Triggerverhalten]
> Oszi: W2022
> Firmwareversion: 1.2.BF.2.7

Probier' mal die .15 oder .16 aus, am Trigger hat Hayo
in der letzten Zeit geschraubt.

Niklas

Autor: Michael H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich habe gerade die neue Variante der Zerolevel Einstellung getestet und 
muss sagen: finde ich klasse. In der Regel setze zumindest ich die 
Kanäle ohnehin auf einen geraden Spannungswert, sprich ich verschiebe 
die Kanäle manuell kästchenweise, weil man sich dann mit dem Ablesen 
leichter tut. Das geht mit der neuen Variante wesentlich einfacher ohne 
dass man die Möglichkeit verliert, beliebige Spannungen zu setzen - ich 
bin also sehr für die Einführung auf allen Kanälen!
Das einzige was dabei stört sind mal wieder die unsäglichen 
Bedienelemente, irgendwann werde ich mir da mal neue suchen müssen.

Gruß
Michael

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Gute Besserung!
Danke!

http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum
Unter Hardware/aktuellste Daten habe ich mal den aktuellen Schaltplan 
und ein Bild vom Layout hochgeladen. Layout und Schaltplan sind fast 
fertig und brauchen nur noch kleine Schönheitskorrekturen.

Mfg,
Kurt

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Allzu viele Rückmeldungen sind ja nicht zu Niklas Idee gekommken. Ich 
habe das aber jetzt trotzdem mal für alle Kanäle eingebaut mit dem 
Zusatz, dass ab einer bestimmten Menge Drehimpulse nicht nur ein Raster 
weiter gesprungen wird, sondern zwei. Dann kann man auch etwas schneller 
über den Screen hoppeln.

Ansonsten mache ich gerade eine Komplettrenovierung bei der 
Autoscalefunktion und im Timebasecontroller.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas O. schrieb:

> Oszi: W2022
> Firmwareversion: 1.2.BF.2.7

Hi Thomas,

danke für die Rückmeldung. Aber wie Niklas schon sagte bitte immer die 
aktuellste freigegebene Version bei Firmware und Screenshot verwenden.

Gruß Hayo

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Allzu viele Rückmeldungen sind ja nicht zu Niklas Idee gekommken.

Hallo Hayo,

die großen Sprünge beim Offset sind bestimmt nicht verkehrt. Ich war da 
zunächst etwas unschlüssig, da man sowieso bei großen Wegen immer 
umgreifen mußte. Aber in der alten Version passierte es auch oft, dass 
sich beim schnellen Drehen mit der Position fast gar nichts tat 
(Unterabtastung der Geber?) und das ist jetzt in der 1.6 wesentlich 
besser.

Gruß
Rainer

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo,

noch ein anderes Thema: Triggerlevel

Läßt es sich ohne großen Aufwand hinbekommen, dass bei Umschaltung der 
Y-Verstärkung der Triggerlevel (in mV) konstant bleibt?
Im Moment muß man bei Änderung vom Y-Gain immer den Triggerlevel 
ebenfalls nachstellen, wenn der Bezug von Signalhöhe zu Triggerlevel 
gleich bleiben soll. Ich finde das eher unpraktisch.

Und hast du das vollständig disablete Kanal-Soft-Menü nach Abschaltung 
eines Kanals noch auf deiner ToDo Liste, wo du gerade beim Renovieren 
bist?

Die neue Auto-Pre-Triggereinstellung "First Grid" ist sehr praktisch.

Schönen Sonntag

Rainer

Autor: Thomas O. (kosmos)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ok habe die aktuelle 2.16 beta drauf und da gibt es die von mir 
beschriebenen Probleme nicht mehr. Mir ist aber etwas aufgefallen das 
schon mal gefixt wurde. Wenn man die Zeitbasis streckt sollte das Signal 
nach rechts gestreckt werden so das die erste Flanke an der gleichen 
Stelle bleibt. Ist das jetzt evtl. im Menü irgendwo einzuschalten, wurde 
das wieder absichtlich entfernt oder wurde es vergessen?

Das mit Triggerpunkt finde ich genial so kann jeder das ganze so 
einstellen wie er es braucht. Triggerpunkt auf erstem DIV oder in der 
Mitte.... Genauso die Einstellung wie man die Singleshot Taste nutzen 
will, einfach spitze wenn man die Einstellungen so individualisieren 
kann.

Hier nochmal 2 Screenshots des von mir beschriebenen Verhaltens, dass 
der Signalbeginn ungewollte nach rechts rutscht wenn man etwas rein 
zoomen möchte.

Wäre es möglich die Dateiübertragung auf den Rechner irgendwie 
anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen? 
Da beim Upload das Oszi nicht reagiert.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas O. schrieb:

> Hier nochmal 2 Screenshots des von mir beschriebenen Verhaltens, dass
> der Signalbeginn ungewollte nach rechts rutscht wenn man etwas rein
> zoomen möchte.

Muß ich mir mal ansehen, im Stop-Modus hatte ich das nicht getestet.

> Wäre es möglich die Dateiübertragung auf den Rechner irgendwie
> anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen?
> Da beim Upload das Oszi nicht reagiert.

Beim Screenshot geht es (wahrscheinlich) leider nicht, es sei denn Du 
möchtest die Anzeige dann auch auf dem Screenshot haben :-)

Ich hatte auch schon drüber nachgedacht. Ich wollte nochmal probieren 
die Textausgabe in die Layer-Zwischenspeicher zu schreiben, evtl. wird 
es dann nicht mit übertragen. Ich check das nochmal.

Gruß Hayo

Autor: Niklas O. (nevm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

>> (Thomas:)
>> Wäre es möglich die Dateiübertragung auf den Rechner irgendwie
>> anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen?
>> Da beim Upload das Oszi nicht reagiert.
>
>(Hayo:)
> Beim Screenshot geht es (wahrscheinlich) leider nicht, es sei denn Du
> möchtest die Anzeige dann auch auf dem Screenshot haben :-)
>
> Ich hatte auch schon drüber nachgedacht. Ich wollte nochmal probieren
> die Textausgabe in die Layer-Zwischenspeicher zu schreiben, evtl. wird
> es dann nicht mit übertragen. Ich check das nochmal.

Es gibt doch noch die unbenutzten Memory-Planes.  Diese muessten
wir doch dafuer verwenden koennen?

Falls dies nicht geht koennten wir, da wir Zeilenweise abarbeiten,
nach ein paar Zeilen ganz oben eine entsprechende Mitteilung mit
Fortschrittsbalken einblenden.  Erstere Option waere offensichtlich
viel eleganter.

Beim kurzen Nachschauen fielen mir gerade die Konstanten Color[7][3]
und clYellow, clCyan usw. und clCHI bis clCursor in tc_vars.(h/cpp)
auf.  Ich haette vermutet dass die dazu dienen die Planes einzufaerben,
stellt sich aber heraus, dass die nirgendwo verwendet werden.
Koennen also weg.

Niklas

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas O. schrieb:
> Wäre es möglich die Dateiübertragung auf den Rechner irgendwie
> anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen?
> Da beim Upload das Oszi nicht reagiert.

IMO reicht es, wenn z.B. die LED über dem "Universal"-Regler blinkt. Ich 
halte es für übertrieben, dafür große Texte im Display einzublenden. 
Sooo lange dauert es nun auch nicht.

Man könnte natürlich in der Zwischenzeit auf dem Screen in einer 
weiteren Zeichenebene TETRIS spielen. ;-)

Autor: Rainer W. (rawi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Niklas

Wo du da wieder am forschen bist, läßt sich vielleich auch herausfinden, 
warum die "Disabled"-Ebene nicht mit den Screenshots übertragen wird.

Gruß
Rainer

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas O. schrieb:
> Es gibt doch noch die unbenutzten Memory-Planes.  Diese muessten
> wir doch dafuer verwenden koennen?

Ich dachte da an die Buffer_Planes. Die werden irgendwann vor der 
Screenausgabe mit den Hauptplanes verodert.

>> Beim kurzen Nachschauen fielen mir gerade die Konstanten Color[7][3]
> und clYellow, clCyan usw. und clCHI bis clCursor in tc_vars.(h/cpp)
> auf.  Ich haette vermutet dass die dazu dienen die Planes einzufaerben,
> stellt sich aber heraus, dass die nirgendwo verwendet werden.
> Koennen also weg.

Ist erledigt

Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleiner Zwischenstand aus dem Hackerkämmerlein,

ich bin gerade beim Autoscale. Dass das bislang so einigermaßen 
funktionierte ist eher Zufall. Das ist ein einziges Rumprobieren was der 
Kerl da veranstaltet hat. Nichts mit Hand und Fuß - also wie gehabt.

Ich bin dran...

Hayo