Hier ist die Fortsetzung von:
Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)"

Und noch die Hardware Diskussion:
Beitrag "Wittig(welec) DSO W20xxA Hardware"

> 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

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

Na klar!

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

Hayo

OK, danke.

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

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

Danke für den Tip

Hayo

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

Ok, Problem ist behoben.

Hayo

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

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

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

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

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

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

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

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

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

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

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

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

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.

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?

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

@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

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

> 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

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

Gruß Hayo

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

@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

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

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

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

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

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

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

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.

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

Gruß Hayo

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.

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

@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

@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

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

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

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

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

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

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

Hallo Hayo,
der LTC2612 ist im roten Kringel.

Mfg,
Kurt

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

Danke.

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

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

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

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.

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

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

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

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

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

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.

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

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

Ich prüf das mal und sag dann Bescheid.

Hayo

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

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

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

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

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

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

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

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

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

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

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

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

Hallo Branadic,

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

Gruß Hayo

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

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

Warte mal,

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

Moment...

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

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

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

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.

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.

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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.

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

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

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

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

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.

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

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

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

Hallo Hayo,

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

Ja.

Niklas

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

Hallo Rainer,

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

Gruß Hayo

@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

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

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

Super!

Das ging ja schnell!

Hayo

@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

@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

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

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

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

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

@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

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

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

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

@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

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.

Nanu,

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

Gruß Hayo

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

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

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

Wie steht es denn um die Ansteurung der Huckepack Platine?

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

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

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

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

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

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

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

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

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.

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.

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

Ist wohl untergegangen.

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

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

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

@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

@Niklas

Diff ist eingebaut und getestet - läuft gut!

Gruß Hayo

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

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

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

> 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

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

@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