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


von Ulrich P. (uprinz)


Lesenswert?

Hayo W. schrieb:
>> Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da
>> die OVs der Eingangsstufe dann frei laufen.
>
> Da gebe ich Dir recht.
>
>> Gibt es keine Option, die
>> Stufe auf GND zu schalten? Das wäre schon mal ein Anfang.
>
> Mir ist keine bekannt, aber wenn es da andere Erkenntnisse gibt macht
> mich schlau. Ich wollte mich erstmal an vorhandener Hardware
> orientieren, damit alle was davon haben.

Wenn ich mir den Schaltplan unter
http://welecw2000a.sourceforge.net/docs/pcb/Analog_+Inputs_updated2.png
ansehe, dan gibt es dort wohl mehrere Möglichkeiten. Leider sind in der 
letzten Version die IC-Nummern raus gefallen.
Der MAX4704 kann das Signal aus der Vorstufe über NO2 auf GND schalten. 
Damit wäre die mittlere Stufe in die Kalibration einbezogen.
Er kann mit NO1 auch gegen einen Pin D8 vom FPGA geschaltet werden, was 
das für einen Sinn hat weiß ich nicht, aber wenn der Pin ein Ausgang 
ist, kann man damit zumindest einen Bezug zu Digital-Masse und Digital 
Vcc herstellen. Allerdings scheint da 0V anzuliegen...

Die Vorstufe rund um die OPAs müsste über K1 und K2 ebenfalls zu 
beruhigen sein, hier liegt leider ein 110K Widerstand im Weg zur Masse. 
Immer noch besser, als zu floaten.

>
>> Optimaler wäre
>> es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten
>> zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs
>> kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige
>> brauchbare Referenz aller Kanäle gemeinsam?
>
> Nicht das ich wüßte. Allerdings hab ich die Hardwareseite noch nicht so
> intensiv unter die Lupe genommen.

Ich auch gerade erst, aber weil ich halt nur mal so mitspiele, habe ich 
auch keine Hektik :) Muss ja keinen Code ändern, weil hunderte Leute 
nach jeder kleinen Verbesserung lechzen :)

> Unter anderem gab es auch eine Korrektur der ADC-Kennlinie, die hatte
> ich beim WELEC auch schon probeweise eingebaut (Y = beta*X + alpha) aber
> wegen der massiven Performanceeinbrüche bei der Graphikausgabe wieder
> ausgebaut.
>
Ich kenne die Software, wie gesagt, nicht. Ich spiele daher also nur mal 
mit Gedanken. Wenn man die Werte als Byte einliest, aber in einem Word 
oder Longint speichert und das gleich als 2. oder drittes Byte.
Dann baut man sich eine Kalibriertabelle, ebenfalls mit korrekt 
verschobenen Faktoren und multipliziert dann nur ein einziges Mal und 
das als int und nicht float. Klar, die Tabelle müsste dann natürlich für 
die geraden und ungeraden Faktoren abgelegt werden, also mind. 2mal. Am 
besten sogar für jeden Messbereich und jeden Kanal. Das braucht etwas 
Platz, spart aber Zeit.

Gruß, Ulrich

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

@Guido

Ich bin mir relativ sicher, dass die 0.32 noch anständig läuft. Hier 
sicherheitshalber die Flashdatei wenn Du das probieren möchtest.


@Ulrich

> weil ich halt nur mal so mitspiele, habe ich
> auch keine Hektik :) Muss ja keinen Code ändern, weil hunderte Leute
> nach jeder kleinen Verbesserung lechzen :)

Ich bin zum Glück seelisch stabil ;-) - sonst wär ich auch als 
EDV-Fachmann völlig im verkehrten Beruf - Kunden können echt grausam 
sein...

> Dann baut man sich eine Kalibriertabelle, ebenfalls mit korrekt
> verschobenen Faktoren und multipliziert dann nur ein einziges Mal und
> das als int und nicht float. Klar, die Tabelle müsste dann natürlich für
> die geraden und ungeraden Faktoren abgelegt werden, also mind. 2mal. Am
> besten sogar für jeden Messbereich und jeden Kanal. Das braucht etwas
> Platz, spart aber Zeit.

1. Platz ist rar. Brauche schon eine Menge für die trigonometrischen 
Tabellen die ich bei der FFT einsetze.

2. Bei 8 Bit ist der Benefit des Abgleichs kombiniert mit der 
Ablesegenauigkeit nicht so berauschend. Den Fehler kann man also wohl 
verschmerzen.

3. Diese Tabellen müßten ja für jedes Gerät separat ermittelt und 
gespeichert werden - was für ein Aufwand an Abgleichroutinen.

Ich denke die Anderen werden mir Recht geben dass es momentan andere 
Baustellen gibt die mehr an nutzbarem Erfolg bringen wenn wir sie in den 
Griff kriegen.

Nichts desto trotz immer her mit konstruktiven Vorschlägen, dann kann 
man Für und Wider hier ausdiskutieren bevor ich (oder andere Berufene) 
da was einbauen.

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

@Ulrich- mit dem Problem des "Eingangstest" (Power on self Test) hab ich 
mich auch schon beschäftigt... der FPGA1 PIN D8 scheint allerdings als 
Input geschalten zu sein...(Wir- im VHDL Projekt- hatten schon mal 
angedacht einen definierten Spannungsverlauf über diesen Pin auszugeben 
und das Ergebnis an den ADC's mit dem abgespeicherten Sollzustand zu 
vergleichen)

Über die jetzige Fkt. der dortigen Beschaltung gibt's meines Wissens 
noch keine tieferen Erkenntnisse.

Evtl. könnte man auch über den DAC eine definierten Spannungsverlauf 
ausgeben- da müsste man einmal sehen wie schnell der ist...

Also ich verbinde meinen BNC- Eingang für die Kalibrierung immer mit 
GND- speziell da mein OPA gern schwingt.

Nehm doch bitte den Schaltplan in der Google Groups, der ist immer auf 
dem neusten Stand (und wesentl. ausführlicher). Derzeit in Version 1.32
http://groups.google.com/group/welec-dso

Gruß, brunowe

von Ulrich P. (uprinz)


Lesenswert?

Hi Bruno,

Ok, dann beziehe ich mich auf diesen Schaltplan, für den aber vorerst 
das gleiche gilt. Mir ist die Funktion aller OVs darin noch nicht ganz 
klar, aber das wird schon. In der Diskussion dieser drei Threads war die 
Rede davon, dass der ADC Single-Ended angesprochen wird. Die Schaltung 
ist aber eher differential ausgelegt. Aber ich bin halt nicht der 
analoge Crack, bei mir fängt die Signalaufbereitung normalerweise auch 
erst im DAC/ADC an.
Daher spinn ich jetzt mal was herum. Wenn der DAC eingesetzt wird, um 
den negativen Bereich in den Positiven zu verschieben, dann ist keine 
saubere 0-Linien Berechnung zu machen, weil die Verzerrungen und die 
Offsetfehler der OVs hoch skaliert werden. Nutzt man den ADC als 
Differential und den DAC nur zum Offsetabgleich und Gain, dann würde man 
doch viel genauere Messwerte gerade bei kleinen Signalen erhalten? 
Beschimpft mich nicht, erklärt es mir, ich lern gerne noch was dazu.

Gruß, Ulrich

von Guido (Gast)


Lesenswert?

@ Ulrich: Der ADC wird differentiell angesteuert. Der DAC verschiebt
direkt den Offset des OPA-Eingangsverstärkers. Er könnte damit direkt
für Testsignale verwendet werden. Aber alles zu seiner Zeit. Solange
die Offseteinstellung noch hakt macht es wenig Sinn daran rumzuspielen.

@ Hayo. Jo, die 0.32 läuft noch. Ich gehe mal das diff durch.

Gruß, Guido

von Ulrich P. (uprinz)


Lesenswert?

Ist schon ok, ich klemm mich mal wieder raus und schau mal, ob ich eine 
UserCalib vom Agilent aufzeichnen kann.

Gruß, Ulrich

von Blue F. (blueflash)


Lesenswert?

@Guido

ja da bin ich auch gerade dabei. Ich muß Dir Recht geben, die 
Hardwareroutinen geben keinen Hinweis. Ich hab danach mal die 
Displayroutinen gescannt, aber auch nichts direktes gefunden außer einem 
Verdächtigen in der DrawSignals(), den ich jetzt mal per 
Terminaldebugging etwas unter die Lupe nehme - Upload läuft noch...

Hayo

von Guido (Gast)


Lesenswert?

@ Hayo: mit dem diff bin ich durch, da ist mir nichts
gravierendes aufgefallen. Ich bin schon am überlegen,
ob es nicht eine Race-Condition ist, aber das sieht
eigentlich auch sauber aus. Ich hab mal "Signal_Loaded"
rausgeworfen, wird eh nicht benutzt aber wohl auch keine
Besserung bringen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Tja bei mir sieht es ähnlich aus. Der Diff-Vergleich bringt nur 
unspektakuläres. Hab jetzt mal ein paar Debuggingausgaben eingebaut.

Folgende Details:

Timebase < 18 und >28 - ADC wird gestartet, ADC meldet per ISR Data 
available, Daten werden vom ADC abgeholt, Zeichenroutine gibt Signal 
aus, ADC wird gestartet....usw.


Timebase >= 18 und <= 28 - ADC wird gestartet, keine Rückmeldung vom 
ADC, es werden keine Daten abgeholt (wegen der fehlenden Rückmeldung), 
Zeichenroutine gibt das alte Signal aus das immer noch im Buffer steht, 
ADC wird gestartet... usw.


Also ich kann mir da im Moment keinen Reim drauf machen. Werd mal als 
nächstes die PIO-Register checken. Schaff ich aber heute und morgen 
nicht.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

heute blicke ich auch nicht mehr viel. Aber suche doch mal
in hardware nach "Start_Record", das wird selbst im
Timerinterrupt aufgerufen. Es macht mich halt misstrauisch,
dass der Fehler vom Timing abhängt.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:
> Es macht mich halt misstrauisch,
> dass der Fehler vom Timing abhängt.

Ich habe da einen weiteren Verdächtigen ausgemacht. Vielleicht schaffe 
ich es nach der Arbeit noch schnell eine neue Testversion upzuloaden 
bevor ich wieder los muß.

Gruß Hayo

von egberto (Gast)


Lesenswert?

Ich habe die 0.56er Sourcen jetzt compiliert bekommen, meine 
TomCat.flash ist allerdings 1307517 Byte groß, die von Hayo 1307650 
Byte.

Habe ich was falsch gemacht (die in der Anleitung beschriebenen 
"offical" Sourcen hatten kein Makefile, ich habe die "improved" genommen 
und dort das src Verzeichnis durch das von Hayo ersetzt)???

Viele Grüße,

egberto

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ich habe bei mir das loader file etwas geändert, das wird dann mit dem 
Flashfile zusammengemerged. Hier noch mal alle wichtigen Ordner ohne den 
src Ordner.

Das sollte es sein. Wenn nach dem Upload alles im Oszi läuft wie es soll 
kann es nicht so verkehrt sein.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Noch eine Frage: hattest Du überhaupt das Loader-File? Wenn nicht 
funktioniert es nicht, da ist der Bootloader drin, der das Programm 
nachher in den RAM-Speicher lädt. Deshalb muß das Loader-File mit dem 
Tomcat.Flash kombiniert werden. Sieht man auch wenn man mit dem 
Texteditor ins Flashfile geht. Das ist im Makefile schon alles 
eingebaut.

Gruß Hayo

von egberto (Gast)


Lesenswert?

Hallo Hayo,

loader ist dabei gewesen(801 Bytes).

Mit deinen Build-Dateien bekomme nach "make clean all" nun auch deine 
Dateigröße.

Viele Grüße,

egberto

von Blue F. (blueflash)


Lesenswert?

@egberto

prima, dann kannst Du ja auch gleich mit einsteigen...


@Guido
Der nächste Verdächtige scheidet auch aus. Hab mal alle UI_requests 
rausgenommen, geht aber trotzdem nicht - die Suche geht weiter. Hab 
schon die nächste Idee, komme aber erst morgen oder übermorgen dazu.

Gruß Hayo

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

es ist mir gelungen den Fehler einzugrenzen und einen
Workaround zu implementieren. Der wird uns hoffentlich
helfen den Fehler zu finden. Näheres findest du im zip
als freeze.txt.

@ all: Im zip ist auch ein Tomcat.flash, das außer dem
Workaround Hayos letzter Beta entspricht. Vielleicht hat
jemand Lust zum Testen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Guido

das Löschen der availability Abfrage bringt uns aber nicht näher an den 
Fehler. Das Problem ist ja, dass der ADC gestartet wir, aber aus 
irgendeinem Grund keinen Ready-Interupt mehr auslöst. Da muß ich wohl 
die Register prüfen, allerdings hatte ich da eigentlich nichts geändert. 
Zur Eingrenzung werde ich auch noch mal versuchen die 0.32er 
Display-Routine mit der 0.33er Hardware-Rotine zu kombinieren und 
umgekehrt. Dadurch läßt sich vielleicht der Fehler weiter eingrenzen.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

die Availability-Prüfung habe ich längst wieder drin. Du musst
da keine weiteren Tests machen. Das Problem ist einfach, dass
der ADC in der Grafik gestoppt wird, so dass sein Interrupt
nicht ausgelöst wird. Ich vermute, dass das in Copy-Planes
erfolgt. Das können wir noch weiter untersuchen, im Moment
arbeitet das Welec mit dem Workaround aber wie gewünscht.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Oh, sorry - da fehlte wohl ein Zeilenumbruch in Deiner Datei. Ich hab 
nur den ersten Teil gelesen. Hab eben nochmal die Zeilen umgebrochen und 
den Rest gelesen. Ok, das ist schon mal ein Hinweis dem man nachgehen 
kann. Die Copy und Transfer Planes Routinen sind leider spärlich 
kommentiert, so dass die Suche etwas schwierig ist. Evtl. könnte man 
nach StopRecord() suchen, denn damit kann man den ADC-Lauf abbrechen.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

muß heißen

Stop_Record()

Hayo

von Blue F. (blueflash)


Lesenswert?

Hab ich mal gecheckt, Stop_Record() scheidet aus.

Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

ich werde später erst mal versuchen den Workaround auf die
schuldige Funktion zu begrenzen (im Moment sind es ja noch
3). Wenn da irgendwo in dem Assemblerteil ein Bit getoggled
wird, könnte die Suche lang werden. :-(

Es könnte aber auch Absicht dahinterstecken, weil sonst ein
Konflikt beim Zugriff aufs RAM entsteht.

Wir werden es rausfinden, Guido

von Blue F. (blueflash)


Lesenswert?

Ok,

ich glaube ich hab es. Durch Deinen Workaround bin ich da auf einen 
Gedanken gekommen. Es gab in der 032 eine Variable - DrawSignals_Needed 
- die hab ich in der 033 rausgenommen (zumindest in der Graphikroutine) 
weil mir die Funktion redundant erschien.

Wenn ich jetzt so darüber nachdenke sollte diese Variable wohl 
verhindern, dass die Gaphikroutine zu früh aufgerufen wird und damit 
natürlich auch das nächste Start_Record(). Denn in Start_Record() wird 
erstmal der alte Aufruf gestoppt und dann wieder ein Neuer gestartet. 
Das erklärt narürlich, warum dann bei langen Wandlerlaufzeiten keine 
neuen Daten mehr gelesen werden. Ich werde das mal morgen reparieren und 
schicke dann die nächste Beta raus. Da sieht man wieder, zu zweit sieht 
man einfach mehr als ein Einzelner.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Ich hab auch schon einen viel eleganteren Lösungsansatz.

In der Routine Start_Record() braucht man nämlich nur das Flag - 
adc_started - abzufragen und bei gesetztem Flag die Routine zu verlassen 
und schon sollte die Welt wieder in Ordnung sein und da die 
Graphikroutine trotzdem noch durchlaufen wird, reagiert sie auch auf 
User-Eingaben.

Das halte ich auch für nachlässig programmiert (von WELEC), denn es 
macht ja keinen Sinn den ADC aufzurufen wenn er noch läuft.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

das haben die sicher so gemacht, damit bei Änderung der
Einstellungen nur Start_Record aufgerufen wird. Sonst muss
man einen Messzyklus abwarten, bis die Signalanzeige
aktualisiert wird (das ist mir eh noch ein Dorn im Auge, jedes
andere Oszi kann das besser), oder erst Stop_Record und dann
noch Start_Record aufrufen.

So, TransferPlanes (allein) ist unschuldig. Werde gleich noch
mal flashen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Bin gerade zuhause angekommen, schnell mal Linux gestartet und die 
Änderungen programmiert und den Updater angeworfen - Upload läuft. Bin 
gespannt was rauskommt.

Gruß Hayo

von Guido (Gast)


Lesenswert?

> Bin gespannt was rauskommt.

Wird schon klappen, ist sehr beruhigend, dass es nur das
Start_Record ist. Braucht man nicht im Assemblercode zu
wühlen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Jo ich habs!!!!!!!!!!!!

Details erzähl ich später. Muß jetzt los.

Hayo

von sunny (Gast)


Lesenswert?

ich hab mal eine frage an die firmware coder. ich spiele gerade etwas 
mit dem schaltverhalten des switch U3 und den softwareskalierungen rum. 
wenn ich die ändere passt der offsetmarker nicht mehr zur nulllinie. 
gibt es für die markerposition auch korrekturfaktoren?

gruß sunny

von Guido (Gast)


Lesenswert?

Hallo sunny,

das klingt ziemlich unsinnig. Die Nulllinie sollte ja da sein,
wo man sie mittels Marker hinsetzt. Die Kalibrierung des Offsets
stimmt aber nur für die in der Firmware vorgesehenen
Einstellungen der Verstärkung.

Gruß, Guido

von sunny (Gast)


Lesenswert?

der sinn, das schaltverhalten des U3 zu ändern (zu invertieren), besteht 
darin die auflösung in den 1er und 2er messbereichen zu verbessern.
im original verstärkt der opa656 im 5er bereich mit 1,25 und in den 1er 
und 2er bereichen mit 1. das hat zur folge, dass in den 1er und 2er 
bereichen die aussteuerung des adc recht gering ist und eine 
softwareskalierung >3 notwendig ist, um den screen zu füllen. betreibt 
man den opa 656 jedoch genau umgekehrt, so dass er im 5er bereich mit 1 
und in den 1er und 2er bereichen mit 1,25 verstärkt, reduziert sich die 
nötige softwareskalierung auf einen faktor von etwa 2. das vermindert 
das sichtbare rauschen und verbessert die darstellungsqualität.
problem ist dass die ausgangsspannungen des offset dac nicht mehr zu den 
verstärkungen des opa656 passen. der offsetmarker erreicht das obere 
ende des screens ca 1,5div vor der nullinie.

die werte in dem float Volt_Correct_float array in der tc_vars.cpp 
müssten doch das sein was ich suche. richtig?

von Guido (Gast)


Lesenswert?

Hallo sunny,

das hängt jetzt davon ab, welche Firmware du benutzt. In der neuesten
Beta hat Hayo die Umrechnung auf Int umgewandelt, so dass die
Tabelle obsolet ist.

Eigentlich sollte U3 immer geöffnet sein (meine Meinung). In den
5er Bereichen bringt das eine bessere Auflösung (Umrechnungsfaktor
auf die Grafik dann 2), in den 1er und 2er Bereichen ist die 1,25
fache Verstärkung sowieso nötig. Da müssen wir mal einheitlich
was festlegen. Dazu sind dann 3 Offsetwerte nötig, was bisher
schon vorgesehen ist.

Gruß, Guido

von sunny (Gast)


Lesenswert?

ich nutz die .56
in der funktion ON_Zero_Channel_x wird das array noch genutzt. ich weiß 
nicht wann hayo das geändert hat.

ich hab den u3 im 5er bereich schlißen lassen, weil dann die 
softskalierung in allen 3 bereichen gleich ist. du hast allerdings 
recht. es macht eigendlich keinen sinn ihn im 5er bereich zu schließen. 
damit verschenkt man nur aussteuerbarkeit. man könnte wirklich mal 
versuchen ihn ständig ausgeschaltet zu lassen.

von Guido (Gast)


Lesenswert?

Tja sunny,

da gibt es schon noch Unstimmigkeiten. Dein Hinweis ist
da schon hilfreich, damit das nach und nach geändert
werden kann.

Mal was anderes: Du hast ja rausgefunden wie U21 und U23
angesteuert werden (hab ich auch schon ;-)). Findest du
ev. wie und wo U24 angesteuert wird? Das wäre für den
Offsetabgleich super, dann könnte man mit dem MAX4704
hierfür die Eingänge auf GND legen.

Gruß, Guido

von egberto (Gast)


Lesenswert?

Dafür, U3 rauszuschmeißen spricht auch die Simulation von Bruno im 
Hardwarethread -> man würde gleich 2 Fliegen mit einer Klappe 
erschlagen.

Mal sehen, was bei Brunos Lötaktion so raus kommt.

Viele Grüße,

egberto

von Blue F. (blueflash)


Lesenswert?

@sunny

Die Marker repräsentieren nur die Nulllinie (Grid-Zerolevel), diese wird 
nur als direkter gridproportionaler Integerwert im Zerolevel geführt. 
Die FW unterscheidet den Grid-Zerolevel (0 - 400) und den virtuellen 
Zerolevel (-8192 bis +8192) der den Aussteuerbereich des DAC 
repräsentiert. Man kann den Zerolevel also bis in den Virtuellen Bereich 
verstellen, nur das der Grid-Zerolevel dann auf 0 oder 400 stehen 
bleibt.

Die Werte im float Volt_Correct_float array sind für die Skalierung des 
DAC-Offsets (Zerolevels) verantwortlich, für die Signalskalierung haben 
sie keine Auswirkungen. Die Mitte (Gridmitte) des DAC-Offsets liegt bei 
8192. Hinzuaddiert wird der virtuelle Zerolevel skaliert durch diesen 
Faktor und korrigiert durch die DAC-Korrektur, die ja bei SearchZero() 
ermittelt wird.

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok hier nun einige Details.

Nachdem ich gestern mit Guidos Hilfe auf den (eigentlich sekundären) 
Fehler gestoßen bin, hab ich erstmal einiges Ausprobiert und analysiert.
Ausglöst wurde der Fehler durch eine Variable die ich gelöscht hatte, 
die aber eigentlich von hinten durch die Brust ins Auge die 
Start/Stop-Logik steuern sollte (in der Graphikroutine!).

Ich hatte ja gestern die Idee in der Start_Record() den erneuten Aufruf 
zu unterbinden. Vom Gedanken her auch korrekt, aber es läuft nicht, da 
die Start/Stop-Logik des ADC so krude implementiert ist, dass es immer 
wieder zu Hängern kommt. Also gleich wieder Nägel mit Köpfen gemacht und 
die Logik vernünftig implementiert. Die Startsequenz hab ich also aus 
der Graphikroutine rausgenommen - wo sie auch wirklich nichts zu suchen 
hat -  und in den ADC-Handler verfrachtet - wo sie auch hingehört. 
Zusätzlich hab ich noch eine Start/Stop-Sequenz in den 
TimebaseWheel-handler eingebaut. Auf die komische Steuervariable die ich 
ja ohnehin schon an diversen Stellen gelöscht hatte, kann man jetzt ganz 
verzichten. Außerdem wird jetzt die Graphikroutine unabhängig vom 
Abtastprozess des ADC durchlaufen was eine bessere Reaktion auf 
Usereingaben bewirkt.

Zusätzlich bin ich bei der Gelegenheit auf eine weitere Baustelle 
gestoßen, die auch die aktuelle FW 1.4 betrifft.
Und zwar laufen Zeitbasen > 20S im 50ns Modus, man kann also mit der 
Zeitbasis 200s ein Signal mit einer Frequenz von z.B. 5 MHz sauber 
darstellen.

Wie das mit dem Timebaseregister zusammenhängt kann man in der 
aktualisierten Fassung meiner Programming Maps sehen die in der 
Timebasetabelle die aktuellen Einstellungen zeigt (siehe Anhang).

Ursprünglich war wohl für Zeitbasen im Sekundenbereich der sogenannte 
Rollmode vorgesehen, der nicht eine Zeitlinie nach der anderen 
darstellt, sondern mit einem Zeitfenster durch die Zeitlinie fährt. Man 
kann sich das so vorstellen wie die Anzeige auf einem Herzschlagmonitor.

Der Programmierer hat jedoch alle Stellen zum Rollmode in der FW 
auskommentiert. War wohl noch unausgegoren. Ich werde das auch nicht 
wieder aktivieren sondern lieber gleich richtig machen. Dauert aber 
natürlich etwas.

Die aktuelle FW ohne Freeze-Bug gibt es heute abend.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

da bin ich aber mal gespannt. Ich hatte mir auch Gedanken gemacht
und war zu dem Ergebnis gekommen, dass Start_ADC in Display_Signals
schon seinen Grund hat. Wenn der ADC schon wieder sampled, während
die Daten verarbeitet werden, gibt es keinen zusammenhängenden
Kurvenzug mehr. Auch bei der Triggerung könnte das zu Problemen
führen. Soweit ich das bisher verstehe, haben wir ja keine echte
Hardware-Triggerung, es wird nur das aktuelle Sample entsprechend
durchsucht.

Die Zeitbasisprobleme kann man wohl nur in der Firmware erkennen,
wer kommt schon auf die Idee über eine Stunde zu warten, bis das
Sampling abgeschlossen ist.

Rollmode, das ist der Begriff, der mir gestern gefehlt hat. Den
müssen wir noch implementieren (hab schon eine Idee) sonst sind
die langsamen Bereiche next to useless.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> Die Zeitbasisprobleme kann man wohl nur in der Firmware erkennen,
> wer kommt schon auf die Idee über eine Stunde zu warten, bis das
> Sampling abgeschlossen ist.

Nein, schließ mal ein 5MHz Signal an und gehe auf 100s oder 200s, das 
sieht genauso aus wie im 50ns Bereich. Bin drauf gekommen weil mich die 
hohe Wiederholrate stutzig gemacht hat. Bei 10s und 20s geht es noch 
(hab ich einfach ausgesessen).

> Rollmode, das ist der Begriff, der mir gestern gefehlt hat. Den
> müssen wir noch implementieren (hab schon eine Idee) sonst sind
> die langsamen Bereiche next to useless.

So ist es. Der rein physikalisch Vorgang ist eigentlich ganz einfach. 
Man sampled immer nur ein kurzes Stück und scheibt es auf der einen 
Seite in den Signalbuffer rein. Hinten läßt man das alte einfach 
"rausfallen". Dann gibt man das Siganl aus. Dann Sampled man erneut und 
schiebt dann wieder nach. Das sieht dann so aus, als würde das Signal 
(ein Impuls z.B.) von links nach rechts über den Bildschirm wandern. 
Dadurch hat man dann bei Sampleraten um 1Sa/s auch keine ewigen 
Wartezeiten bevor man was sieht.

Ideen hab ich auch schon, aber ich muß mal meine Prioritätenliste 
sortieren und sehen was mir wichtig erscheint.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> Ich hatte mir auch Gedanken gemacht
> und war zu dem Ergebnis gekommen, dass Start_ADC in Display_Signals
> schon seinen Grund hat. Wenn der ADC schon wieder sampled, während
> die Daten verarbeitet werden, gibt es keinen zusammenhängenden
> Kurvenzug mehr.

Nein, kein Problem, der ADC-Handler wartet ja mit dem Auslesen des
nächsten Samples bis die Graphikroutine fertig ist - es sei denn es
kommt ein UI-Interrupt.

> Auch bei der Triggerung könnte das zu Problemen
> führen. Soweit ich das bisher verstehe, haben wir ja keine echte
> Hardware-Triggerung, es wird nur das aktuelle Sample entsprechend
> durchsucht.

Der Trigger verschiebt im Prinzip nur den angezeigten Ausschnitt aus dem
Signalbuffer. Ich habe die Variable die den Startpunkt des Fensters
markiert irgendwann mal umbenannt in MemWinStart falls Du mal im Coding
suchen willst.

Gruß Hayo

von sunny (Gast)


Lesenswert?

hi

@guido
>Findest du ev. wie und wo U24 angesteuert wird?
ja, ich denke schon.
der U24 hängt hardwaremäßig hinter dem U22 welcher für die ansteuerung 
des CH2 zuständig ist. du machst also

SwitchesCH2 &=0x00FF;
SwitchesCH2 |= 0x**00; // ** sind die daten die an U24 erscheinen sollen
SetSwitches(2, -1);

ich denke so müsste das gehen.

@hayo
die signalskalierung hatte ich schon gefunden.  mir ging es hier um die 
skalierung der dac ausgangsspannung in bezug auf die markerposition. ich 
hatte das etwas blöd beschrieben. auf jeden fall danke für die 
erklärung. ich werd mein glück noch mal versuchen.

gruß sunny

von Guido (Gast)


Lesenswert?

Hallo sunny,

danke, damit werde ich mal spielen.

Gruß, Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok hier wie angekündigt die neue 0.59 beta.

Hab noch schnell einige Sachen geprüft, aber soweit scheint alles stabil 
zu laufen (außer den bekannten Bugs). Wer mitgelesen hat der weiß schon, 
dass der Freeze-Bug endlich gefunden und beseitigt ist. Der DAC-Abgleich 
ist noch in Arbeit und funktioniert nur wenn man die Zerolevel vorher 
auf Gridmitte gestellt hat.

Der neu gefundene Fehler in der Zeitbasis, der auch in der originalen FW 
steckt kann nur durch die Implementierung des Rollmode beseitigt werden 
- Fertigstellungstermin noch unklar.

Wie immer alles andere in der readme. Ich hab auch noch die How To für 
die Linux und CDK Installation mit reingepackt.

Gruß Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

ich hab die neue FW mal aufgespielt und auch den ADC-Abgleich 
durchgeführt, soweit so gut.

Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch 
nicht richtig funktioniert? Kanal 1 und 2 werden ziemlich gut auf Null 
gebracht, bei Kanal 3 und 4 liegen die Signale unterhalb der Nulllinie.
Oder hängt das noch mit dem DAC-Abgelich zusammen?

Ansonsten sieht die FW bei mir momentan stabil aus, werd mal noch ein 
wenig herumprobieren.

Gruß, branadic (W2014A)

von egberto (Gast)


Lesenswert?

Hallo Hayo,

ich hatte das ja bei meinen Compilierversuchen schon angedeutet - die in 
deiner Anleitung angegebenen Sourcen stehen da nicht mehr, und die als 
"improved" zu findenden haben einen anderen loader als du.
Könntest du nicht diese build.zip in jede weitere Beta einschließen? 
Dann hat man ein Makefile und auch deinen loader. So könnte sich eine 
breitere "Masse" damit auseinandersetzen.

Leider geht z.Z. mein Hausumbau vor, aber deine "Programming_Maps" 
empfinde ich als sehr hilfreich zum Verständnis - bitte mehr in dieser 
Art bzw. umfangreiche Kommentare in den Sources.

Viele Grüße,

egberto

von Johannes S. (demofreak)


Lesenswert?

branadic schrieb:
> Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch
> nicht richtig funktioniert? Kanal 1 und 2 werden ziemlich gut auf Null
> gebracht, bei Kanal 3 und 4 liegen die Signale unterhalb der Nulllinie.

Bei mir ganz genauso.

/Hannes

von branadic (Gast)


Lesenswert?

Hallo Hayo,

ich weiß nicht inwiefern dir das jetzt noch hilft, aber bei mir spuckt 
der automatische ADC-Abgleich folgende Werte aus:

CH1 ADC1 Voltage offset = 3
CH1 ADC2 Voltage offset = 0
CH1 ADC3 Voltage offset = 1
CH1 ADC4 Voltage offset = 0

CH2 ADC1 Voltage offset = 0
CH2 ADC2 Voltage offset = 0
CH2 ADC3 Voltage offset = 0
CH2 ADC4 Voltage offset = 0

CH1 Zero Sign Offs 1    = 113
CH1 Zero Sign Offs 2    = 134
CH1 Zero Sign Offs 3    = 91

CH2 Zero Sign Offs 1    = 115
CH2 Zero Sign Offs 2    = 140
CH2 Zero Sign Offs 3    = 104

Man merkt auch den Geschwindigkeitszuwachs durch deine Aufräumarbeiten 
:)
Wirklich schon schön anzuschauen.

Gruß, branadic

von Stefan (Gast)


Lesenswert?

Hallo Hayo,

habe mich mal durch das Assembler-Listing durchgelesen, das du im 
anderen Thread veröffentlich hast. Ich antworte einfach mal hier, weil 
es ja zur Software gehört. Ich hoffe, dass stört keinen.

Alles habe ich noch nicht 100% verstanden, aber den Größtenteil. Es 
langt auf alle Fälle um zu erkennen, warum das Averaging so ganz komisch 
funktioniert. Der Durchschnitt wird nicht mit den benachtbarten 
Messwerten gebildet, sondern mit den Messwerten die noch im Speicher vom 
letzten Aufruf stehen. Wenn der Trigger etwas ungenau funktioniert, 
werden dadurch verschiedenste Werte gemittelt.

Mehr dazu dann Morgen, wenn ich es ganz verstanden habe.

Gruß,Stefan

von Blue F. (blueflash)


Lesenswert?

Stefan schrieb:

> habe mich mal durch das Assembler-Listing durchgelesen, das du im
> anderen Thread veröffentlich hast. Ich antworte einfach mal hier, weil
> es ja zur Software gehört. Ich hoffe, dass stört keinen.

Das ist hier schon ganz richtig, hatte nur das Thema von Bruno im 
Hardwarethread aufgegriffen, von daher überschneiden sich auch einige 
Themen in den Threads was ja nicht schlimm ist.

> Alles habe ich noch nicht 100% verstanden, aber den Größtenteil. Es
> langt auf alle Fälle um zu erkennen, warum das Averaging so ganz komisch
> funktioniert. Der Durchschnitt wird nicht mit den benachtbarten
> Messwerten gebildet, sondern mit den Messwerten die noch im Speicher vom
> letzten Aufruf stehen. Wenn der Trigger etwas ungenau funktioniert,
> werden dadurch verschiedenste Werte gemittelt.

Das wäre allerding etwas merkwürdig. Wundern täte es mich allerdings 
nicht, nach dem was ich bislang schon alles im Coding gefunden habe.
Aber schön, dass Du Dich da reinkniest, ich gebe zu ich hatte keine 
Lust, Assembler ist immer so mühsam.

Da gut optimiertes C-Coding auch nicht langsamer ist war ich schon am 
überlegen ob man das nicht in C umschreibt.

Gruß Hayo

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

@ egberto: deine Probleme kann ich nachvollziehen, probier mal mit
dem angehängten loader.flash aus dem "Offical_Build", bei mir geht das.

@ Stefan: Probier mal, es sieht wirklich nicht so schlimm aus. Freue
mich auf Rückmeldungen! Wie du das mit dem Trigger meinst, verstehe ich
nicht. Der Mittelwert sollte ja schon aus aufeinanderfolgenden Messungen
berechnet werden.

Gruß, Guido

von Günter J. (gjung)


Angehängte Dateien:

Lesenswert?

Hallo,

erstmal vorallem Danke an Hayo und Bruno für die bisherige hervorragende
Arbeit.

Ich habe mich mal mit der Idee beschäftigt das Flash für die
Entwicklungsarbeit zu umgehen und die Firmware direkt ins RAM zu laden.
Das geht gut in dem man anstatt dem Loader einfach ein "r0" an den
Anfang schreibt um den Relocate zu umgehen.

Das angehängte Makefile erzeugt zusätzlich zum TomCat.flash ein
TomCat.ram welches man ohne lange Wartezeit sehr schnell ins RAM
laden kann.
Durch den S8 Record am Ende wird die Firmware dann auch gleich 
gestartet.
Dieser "S8" Record ist vermutlich auch der Grund für den Timeout
wenn man das Flash beschreibt, da der GERMS Monitor dann die
Firmware starten will, aber ein einer falschen Stelle.
Im Flash File sollte man diesen Record entfernen (mach ich mich als
nächstes drüber).

Mit gtkTerm kann ich das Ram File in knapp 3 Minuten zuverlässig laden, 
damit spart man viel Zeit beim Testen, und das Flash wird auch nicht so
oft neu beschrieben was der Haltbarkeit des selben zu gute kommt.

Gruß,
Günter

von Kurt B. (kurt)


Lesenswert?

Könnte man eigentlich die Bootzeit verkürzen indem man den 
Startbildschirm rausnimmt, der 5 Sekunden angezeigt wird?
Man kann ihn ja immer noch über Utility/About Oscilloscope anzeigen.

Außerdem: Nach dem verstellen der Zeitbasis, wenn der Scrollbalken 
ausgeblendet wurde, bleibt die Anzeige kurz stehen. Ist das normal?

von Blue F. (blueflash)


Lesenswert?

branadic schrieb:

> Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch
> nicht richtig funktioniert?

Ich hab die Search Zero Funktion bis auf ein paar kleine Reparaturen 
wieder auf original gesetzt weil ich die Feinkorrektur in Calibrate DAC 
machen will.

> Ansonsten sieht die FW bei mir momentan stabil aus, werd mal noch ein
> wenig herumprobieren.

Einen kleinen Bug hab ich eben noch gefunden und auch schon beseitigt, 
nach Calibrate Zero läuft das Signal nicht wieder los. Man muß erst am 
Timebase-Knopf drehen bevor es weitergeht.

Dass Dein einer Kanal bei 0000 liegt ist schon Glücksache, das Glück 
haben nicht Viele (ich denke da z.B. an Bruno). Bei mir liegen auch alle 
Offsets zwischen 0 und 3.

@Egberto

Ich hab das nicht mit ins Package reingetan, weil sonst der Umfang zu 
sehr anschwillt und das Limit irgendwann erreicht ist. Ich kann aber mal 
ein aktuelles Build auf Google Groups ablegen und die Links dahin 
aktualisieren (mach ich morgen).

Gruß Hayo

von Michael W. (slackman)


Lesenswert?

Hi,
gerade habe ich mal die Firmware auf allen Kanälen durchgetestet und es 
sah recht gut aus (interner Rechteckgenerator).

Später dann (30 Minuten) habe ich diese Tests nochmal duchgeführt und 
gemerkt, dass die Kurven nur bei eingehendem Signal gezeichnet werden. 
Sobald der Triger weg ist, bleiben die Kurven stehen - böse Sache. Wenn 
ich den getriggerten Eingang auf Null gelegt habe, steht immer noch die 
'alte' Kurve. Sobald das Signal wieder am getriggerten Eingang liegt, 
wird das Bild wieder gemalt. Ist aber auch möglich, dass ich irgendwo 
zwischendurch was verdreht habe (Level, protrigger)...

Allerdings habe ich die Tests immer nur mit einem geschalteten Eingang 
durchgeführt. Wie es sich mit 2+ Signalen verhält, weiss ich nicht.

Im großen Ganzen ist der Rauschteppich aber merklich kleiner geworden - 
Danke dafür.

Michel

von Blue F. (blueflash)


Lesenswert?

Ok, danke für die Info,

ich schau es mir mal an.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Michel

Konnte ich nicht nachvollziehen. Kriegst Du das nochmal hin? Wenn ja 
dann die genauen Einstellungen posten (evtl. Bild).

Gruß Hayo

von Michael W. (slackman)


Angehängte Dateien:

Lesenswert?

Sorry,
hab an den EInstellungen gespielt...
Wenn ich von 'Edge' auf 'Pulse Width' gehe. Ein Redraw findet statt 
(Marker rechts und links zucken, nur die Kurven werden nicht neu 
gezeichnet. Allerdings denke ich mal, dass die Einstellungen nicht so 
ganz passen: Delta T 115us bei 1kHz Signal... ?

Bild ist nur mit 'nem Handy aufgenommen, sorry dafür. Hatte keinen Bock 
die Kamera zu suchen.

Michel

von Blue F. (blueflash)


Lesenswert?

@Michel

Ok Problem erkannt. Allerdings habe ich festgestellt, dass es nicht an 
meinen Änderungen liegt, denn die original FW 1.4 hat genau das gleiche 
Problem.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Hab noch mal ezwas rumgetestet, sobald die Triggereinstellungen zur 
Pulsweite passen läuft er weiter. Mir fehlt jetzt etwas die Erfahrung 
mit anderen DSOs, insofern weiß ich nicht ob dies als Fehler anzusehen 
ist, oder ob es gewollt ist. Kann hier jemand weiterhelfen?

Gruß Hayo

von Michael W. (slackman)


Lesenswert?

Da ich in den letzten Jahren nur Hochsprachen gemacht habe, traue ich 
mir eine solche hardwarenahe Programmierung nicht zu, würde aber gerne 
helfen...

@Hayo:
vielleicht sollte ich mich mit dem USB beschäftigen? Die serielle 
Schnittstelle geht mir auf den Zwirn. Vielleicht auch den Updater 
(Option: In's RAM oder Flashen...)

Gibt es einen Teil im Code, der den USB behandelt? Ich bin leider 
FPGA-mäßig nicht so fit (s.o.), ist die serielle Schnittstelle direkt in 
den FPGA integriert? Die Aktivierung über die Funktionstasten läßt ja 
sowas vermuten...

Kann ich die Entwicklung auch unter Windows machen oder ist es unter 
Linux einfacher?

Werde mal auf Google Groups nach den entsprechenden Quellen fahnden...

Michel

von Crazor (Gast)


Lesenswert?

Oszi-seitig hängt am USB ein Cypress FX1. Das ist ein USB-fähiger 
8051er. Der FX1 ist außer per JTAG nur per einer weiteren UART mit dem 
FPGA verbunden. Das heißt du gewinnst nicht viel.

Für die Anwender ist der FX1 nur ein teurer USB<->RS232 Wandler, aber 
für die FPGA-Bastler kann man auf den FX1 auch eine nette Firmware 
laden, die das Oszi dann zum Rechner hin wie einen Altera ByteBlaster 
aussehen lässt. Somit kann man direkt ohne das Gerät zu öffnen neue 
Configs in den FPGA übertragen.

Beide UARTs (die für den seriellen und die für den USB-Anschluss) werden 
im FPGA realisiert und sehen von der Software her deshalb vermutlich 
auch beim NIOS aus wie normale serielle Schnittstellen. Außerdem denke 
ich dass auch an der USB-UART bei 115200 Baud schluss ist. Aber das ist 
jetzt Spekulation.

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

Danke Crazor, gute Erklärung.
Was ich mich in diesem Zusammenhang schon öfter gefragt habe:
Warum muss ich beim Welec-Updater den Germs-Monitor zum Upload starten, 
beim original W2000-updater von Welec nicht? Offensichtlich gibt es 
einen grundsätzlichen Unterschied zwischen den beiden Update- 
Verfahren?!
Hat Jemand tiefere Erkenntnisse diesbezüglich?

@werner: Für einen Updater per USB wäre ich seeeehr dankbar!
Mit diesen USB-seriell ist das echt ne Qual.

Gruß, brunowe

von Michael W. (slackman)


Lesenswert?

... ich hab' mal'n Bischen rumgesucht...

Leider bringt er es laut irgendeinem Schema auf Google Groups nur auf 
57k zum FPGA, laut Datenblatt kann der Cypress bis zu 230k. Wie die 
Anbindung an den FPGA funktioniert, muss ich erst rauskriegen.

Bleibt mir die Firmware wohl nicht erspart...
@Hayo
Ist es vielleicht möglich mir zwei weiteren Funktionstasten das Scope an 
dem USB lauschen zu lassen?

Was macht eigentlich die Firmware für den Cypress im Originalzustand? 
Nur Sampledaten ausgeben?

Michel

von Blue F. (blueflash)


Lesenswert?

Hi, das sind jetzt aber viel Fragen,

- erstmal kann jemand bei der Sache mit dem stehenden Signal 
weiterhelfen und mal kundtun ob das so sein muß oder nicht?

- es gibt USB-Routinen in der FW. Wenn jemand die Windows oder 
Linux-Seite übernimmt, könnte ich die Verarbeitung auf der DSO-Seite 
übernehmen.

- Der GERMS-Monitor ist normalerweise Bestandteil aller Developmentkits 
(hatte ich auf meinem DSP56000 Board auch) und ist wegen Minimalcodings 
nur auf RS232 ausgelegt. Die Schnittstelle ist eigentlich nicht für den 
Normalbetrieb gedacht, aber freundlicherweise hat WELEC sie gewollt oder 
evtl. sogar ungewollt zur Verfügung gestellt.

- Zur aktuellen Beta die bei mir gerade heranwächst: Der DAC-Abgleich 
wird langsam rund. Ich mache gerade noch ein paar Tests, ich denke 
morgen müßte ich soweit sein.

Gruß Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

also ich kann nur von meinem täglichen Arbeitsgerät berichten:

Ist die Triggerquelle weg, dann wird die Anzeige auch weiterhin mit den 
digitalisierten Werten aktualisiert, allerdings aufgrund des fehlenden 
Triggers wandert das Signal wahllos durch den Bildschirm.
So kenn ich das jedenfalls und das macht auch irgendwo Sinn. 
Zugegebenermaßen arbeite ich mit einem DPO, nicht mit einem DSO.

Vielleicht weiß jemand anderes etwas anderes zu berichten.

Gruß, branadic

von branadic (Gast)


Lesenswert?

Hallo Hayo,

mir ist noch eine Sache aufgefallen.
Angenommen ich habe eine Zeitbasis von 5ms, lasse mir ein Signal 
anzeigen und stoppe dann, dann sollte ich theoretisch bis 5ns herunter 
den Zeitbereich verstellen können und somit im aktuellen Ausschnitt 
näher an das Signal heran zoomen können. So kenn ich das zumindest von 
dem Tek mit dem ich arbeite.
Tatsächlich kann ich aber nur bis 1ms/div verstellen. Klar kann ich das 
Signal nur im Rahmen der aktuellen Samplerate auflösen, dennoch sollte 
das funktionieren.
Das dies notwendig sein kann weiß ich aus meiner aktuellen Arbeit. Mit 
einem einfachen Triggerereignis hätte mir da nicht geholfen, aber das 
Reinzoomen.

Man muss immer davon ausgehen, dass man am Anfang nicht weiß wonach man 
in einem Signal sucht. Erst wenn man weiß wonach man sucht (dazu sollte 
man das Ereignis mal wenigstens kurz über den Bildschirm gerauscht haben 
sehen) kann man den Trigger auf ein entsprechend Ereignis einstellen.
Daher auch mein oberer Beitrag nach Sinn oder Unsinn der 
Bildschirm-aktualisierung bei fehlendem Triggerereignis.

Beste Grüße, branadic

von Guido (Gast)


Lesenswert?

Hallo alle,

da ja Einiges aufgelaufen ist, mal ein paar Anmerkungen.

@ branadic: Das eigentliche Problem ist ja, dass afaik es keine
Triggerung gibt. Es wird gesampled und anschließend das Sample
nach einem passenden Event durchsucht. Das mit dem Zoomen im
Stop-Modus schaue ich mal an. Ich fürchte nur, dass es mal wieder
kein Bug sondern ein Feature ist, weil es sonst garnicht geht (Hayo
kann da nix für).

@ Hayo: Mach dir keine Gedanken um den Quatsch mit PW-Triggerung. Das
ist was für Logicanalyzer und im Source wohl noch drin wie andere
LA-Fragmente.

@ Michael Werner: Ob USB oder RS232 spielt eigentlich keine große
Rolle. Ein USB-Zugang wäre halt für die Leute wertvoll, die keine
RS232-Schnittstelle mehr haben. Einfach wird das aber nicht, da
sich das Welec als HID anmeldet und damit ein entsprechender Treiber
benötigt wird. Eine verbesserte Version des Welec-Updaters wäre
schon schön. Die enorme Flashdauer hierin wird wohl hauptsächlich
durch den Einsatz einer Klasse für RS232 hervorgerufen, die sowohl
für Linux als auch Windows nutzbar ist. Uhhnd, blos nix gegen den
GERMS-Monitor, der hilft sogar, wenn man fast alles kaputt geflasht
hat.

Gruß, Guido

von Karl (Gast)


Lesenswert?

Zum Trigger: Agilent bietet die 2 Einstellungen "Normal" und "Auto". 
Erstere zeichnet nur neu, wenn auch ein Trigger-Ereignis stattgefunden 
hat, letztere triggert immer mal wieder (0.3 s?) und zeichnet auch, was 
dann gemessen wurde. Beide sind nützlich.

Ein Oszi ohne Pulsweitentriggerung kommt mir nicht mehr ins Haus. Das 
ist mitnichten etwas für einen LA!

von Blue F. (blueflash)


Lesenswert?

@Karl

das heißt also das WELEC läuft im "Normal" Modus, und es fehlt 
eigentlich nur der "Auto" Modus.

Es ist also kein Bug sondern ein fehlendes Feature - korrekt?

Hayo

von michaelk (Gast)


Lesenswert?

So, ich kann nun auch compilieren. Wenn es also eine Kleinigkeit gibt, 
die sich für den Einstieg eignet könnte ich mich daran versuchen. Werde 
in der nächsten Zeit mal versuchen mich in den Code einzuarbeiten...

Uum Reinzoomen:
in der Uni arbeite ich mit einem Agilent. Dort kann man im Menü auf 
"High Resolution" umstellen. Dann samplet das Osiz höher und man kann 
ohne Probleme reinzoomen. Das ist schon sehr praktisch.
Ob man sonst eine Beschränkung in der Zeitbasis hat, kann ich aber 
gerade nicht sagen.

Hat schon jemand das Makefile von Günter ausprobiert? Wenn das 
funktioniert wäre es ja super zum Testen. Werde mal heute Nachmittag 
probieren ob es bei mir klappt.

MfG, Michael

von Blue F. (blueflash)


Lesenswert?

michaelk schrieb:
> So, ich kann nun auch compilieren. Wenn es also eine Kleinigkeit gibt,
> die sich für den Einstieg eignet könnte ich mich daran versuchen. Werde
> in der nächsten Zeit mal versuchen mich in den Code einzuarbeiten...

Die Datenübertragung via USB für die PC-Software ist von mir weder 
getestet noch komme ich dazu hier was zu bauen (evtl. Erweiterungen). 
Hier wäre also Unterstützung notwendig.

Mein letzter Stand war, dass die FW1.2 einen Fehler in der 
Datenübertragung hat, und die Open Source FW basiert ja auf einer frühen 
Version der 1.2 FW (anscheinend aber nicht auf der offiziellen FW1.2).

> Uum Reinzoomen:
> in der Uni arbeite ich mit einem Agilent. Dort kann man im Menü auf
> "High Resolution" umstellen. Dann samplet das Osiz höher und man kann
> ohne Probleme reinzoomen. Das ist schon sehr praktisch.

Solche Sachen müssen erstmal auf die Wunschliste, es macht keinen Sinn 
damit anzufangen solange so viele unerledigte Baustellen offen sind. 
Deshalb bin ich mit der FFT ja auch noch nicht weiter, da ich einsehen 
mußte, das es einfach keinen Sinn macht. So langsam kommt aber Struktur 
in die Sache und ich denke wir können bald anfangen die Wunschliste 
abzuarbeiten.

> Hat schon jemand das Makefile von Günter ausprobiert? Wenn das
> funktioniert wäre es ja super zum Testen. Werde mal heute Nachmittag
> probieren ob es bei mir klappt.

Ich werde heute ein komplettes Build zur neuen 0.62 beta zur Verfügung 
stellen

Hayo

von Kurt B. (kurt)


Lesenswert?

Was meint ihr zum weglassen des Startbildschirms?

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen schrieb:
> Was meint ihr zum weglassen des Startbildschirms?

Meinst Du den ganzen Startbildschirm mit Versionsanzeige etc. oder nur 
das Logo? Ich finde das immer ganz nützlich. Außerdem braucht die Kiste 
die Zeit ohnehin um sich zu initialisieren.

Ich kann aber gerne mal eine logofreie Version machen wenn das der 
konsenz ist.

Hayo

von Kurt B. (kurt)


Lesenswert?

Ich meine den ganzen Bildschirm. Aber wenn während der Anzeige noch 
weiter initialisiert wird, macht es keinen Sinn.

von Blue F. (blueflash)


Lesenswert?

@Kurt

ja und es wird auch noch etwas länger dauern wenn ich die FFT 
implementiere, da ich die Zeit der Sartsequenz nutzen werde um die 
trigonometrischen Tabellen anzulegen (zumindest solange die nicht im 
Flash untergebracht sind). Diese Funktion ist zur Zeit nur deaktiviert 
weil ich mit dem Rest der FFT noch nich´t so weit bin.

@all

Zur Zeit bin ich beim Feintuning der DAC-Calibration Routine. Dabei bin 
ich auf einige Ungereimtheiten (mal wieder) beim Setzen der ADC-Register 
der Kanäle 3 + 4 gestoßen. Evtl. könnten hieraus einige der für Kanal 3 
+ 4 gemeldeten Effekte resultieren. Ich werde der Sache mal nachgehen.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo,

nochmal zur Triggerung: mein Tek TDS210 verhält sich da exakt
genauso wie die Beta 0.59. Von Fehler kann also wohl keine Rede
sein, eher von Wunschliste.

Wenn sich jemand an der Firmware was vorknöpft, bitte hier
melden, damit nichr mehrere Leute am selben Problem arbeiten. Das
gibt sonst nur Frust und Probleme gibt es ja genug für alle.

Gruß, guido

von Michael W. (slackman)


Lesenswert?

@ Guido:
kannst Du mir mal einen Tipp geben, wie Du die Entwicklungsumgebung auf 
Ubuntu eingerichtet hast? Das, was im Forum stand, war ein wenig kurz 
und unsortiert. Ich bin gerade dabei 'Mint' bei mir einzurichten, 
gefällt mir besser als normales Ubuntu.

@Hayo:
kann ich Dein komplettes Build so übernehmen oder muss ich Anpassungen 
machen? Sind Deine letzten FWs (oder die letzte) komplett oder muss ich 
die alten Source dazubauen?

Besten Dank im Voraus
Michel

von Guido (Gast)


Lesenswert?

@ Michael W: Ich habe garnichts eingerichtet (wenn ich mich recht
erinnere). Nur das ndk4nios nach /usr/local kopiert (ausgepackt).
Im Makefile musste ich noch /usr/include in die Include-Liste
aufnehmen. Zum Kompilieren muss ich einmal/Tag den Pfad erweitern,
mit meiner Einrichtung mit:
"export PATH=$PATH:/usr/local/ndk4nios/bin".

Dann läuft make im "Official Build" durch. Für neue Betas mache ich
erst make clean und überschreibe dann das src-Verzeichnis im
Official Buil mit Hayos neuem src.

von michaelk (Gast)


Lesenswert?

@ Michael W.:
die Einrichtung auf Ubuntu ist eigentlich sehr einfach. Du lädst dir die 
deb-Pakete von der Google-Groups-Seite runter und installierst sie 
(entweder per Doppelklick oder im Terminal mit dpkg -i ...). Danach 
musst du noch den Installationspfad (z.B. /opt/cdk4nios) in die 
PATH-Variable eintragen (z.B. export PATH=$PATH:/opt/cdk4nios/bin). Dann 
brauchst du noch unix2dos. Das kannst du über die Paketverwaltung 
installieren (tofrodos). Danach solltest du im Terminal per make-befehl 
compilieren können.

von Michael W. (slackman)


Lesenswert?

Hi,
danke erstmal, nach dem zweiten Versuch habe ich Mint dann auch 
draufbekommen (Installerscript ist wohl buggy). Nachdem mir das Script 
den Windows Boot zerschossen hat, muss ich erstmal sehen, wie ich den 
wieder hinbekomme - shit, ist mir ewig nicht mehr passiert (hab seit 
Slackware 4.x in regelmäßigen Abständen mit diversen Linuxen gespielt). 
Ärgerlich, wahrscheinlich muss ich Alles platt machen und wieder neu 
installieren (Win & Linux) :-(.
WinXP Boot macht Bluescreen...

Michel

von Guido (Gast)


Lesenswert?

>wahrscheinlich muss ich Alles platt machen und wieder neu
>installieren (Win & Linux) :-(.

Blos nicht! Eine Reparatur müsste doch einfach sein, erstmal
mit der Windows-CD. Weitere Möglichkeiten könnte ich noch
suchen.

Guido

von Blue F. (blueflash)


Lesenswert?

Das komplette Build welches ich heute auf Google Groups zur Verfügung 
stelle muß man einfach nur in ein beliebiges Homeverzeichnis kopieren. 
Nach einem "make clean" und anschließendem "make all" (man muß natürlich 
ins Buildverzeichnis wechseln) sollte alles durchlaufen.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So hier kommt sie die 0.62 beta.

Highlight: Die DAC-Kalibrierung funktioniert jetzt richtig gut. Ich habe 
eine How to für den Abgleich beigelegt.

Zusätzlich habe ich Registerwerte für den Kanal 3 + 4 verändert. Bei mir 
konnte ich keine Auswirkungen beobachten. Wer was feststellt bitte mit 
detailierter Beschreibung posten.

Die Beschreibnungen für die Linuxinstallation habe ich mit neuen Links 
versehen u.a. zum aktuellen Build 0.62. Die Sources und das komplette 
Build sind auf Google Groups verfügbar.

http://groups.google.com/group/welec-dso/files -> 
BlueFlash_Build_0_62.zip

Gruß Hayo

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Bruno,

ich habe gerade deine neue FW aufgespielt und wie beschrieben den 
Abgleich durchgeführt, für alle Kanäle in allen Spannungsbereichen.
Die Linien liegen sauber um Null und schauen recht glatt aus.

Danach habe ich mal das 1kHz-Testsignal hergenommen und mir auf den 
einzelnen Kanälen angeschaut.
Trotz DC-Coupling wird das Signal auf allen Kanälen wie AC-Coupling 
dargestellt.
Auf Kanal 2 stimmt auch irgendwas nicht. Hier wird das Signal um Faktor 
8 größer als auf den anderen Kanälen wiedergegeben. Hab alle Kanäle auf 
10:1 eingestellt. Kanal 1  3  4 sind auf Einstellung 500mV/div, Kanal 
zwei auf 2V/div.
Auf Kanal drei zeigen sich mit dem Testsignal am Tastkopf größere 
Störungen/ Ausbrecher, nimmt man das Signal wieder weg schaut die Linie 
glatt wie zuvor aus.

Soweit gerade die ersten Dinge, die mir aufgefallen sind.

Ich hoffe es ist detailiert genug beschrieben. Ich bitte das Photo zu 
entschuldigen, aber ich denke man kann das von mir beschriebene erahnen.

Beste Grüße, branadic

von branadic (Gast)


Lesenswert?

Mist aber auch, scheine auch schon irgendwie durch den Wind zu sein. Das 
passiert, wenn man mit dem Kopf gleichzeitig bei verschiedenen Dingen 
ist. Streiche Bruno und schreibe Hayo. Asche auf mein Haupt!

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

branadic schrieb:

> ich habe gerade deine neue FW aufgespielt und wie beschrieben den
> Abgleich durchgeführt, für alle Kanäle in allen Spannungsbereichen.
> Die Linien liegen sauber um Null und schauen recht glatt aus.

Wie bei mir auf beiden Geräten. Ich hatte allerdings das Gefühl das die 
Nulllinien auch noch eine leichte thermische Drift haben. Wenn das Gerät 
kalt ist liegt der Nullpunkt ganz leicht verschoben zum warmen Gerät.

> Danach habe ich mal das 1kHz-Testsignal hergenommen und mir auf den
> einzelnen Kanälen angeschaut.
> Trotz DC-Coupling wird das Signal auf allen Kanälen wie AC-Coupling
> dargestellt.

Ich hab mal mit dem Signalgenerator getestet, die AC/DC-Kopplung 
arbeitet korrekt.

> Auf Kanal 2 stimmt auch irgendwas nicht. Hier wird das Signal um Faktor
> 8 größer als auf den anderen Kanälen wiedergegeben. Hab alle Kanäle auf
> 10:1 eingestellt. Kanal 1  3  4 sind auf Einstellung 500mV/div, Kanal
> zwei auf 2V/div.

Du mußt Dich da irgendwie beim Messen verhauen haben. Hast Du Tastköpfe 
verwendet? Wenn ja, sind die alle auf 1:1 eingestellt?
Hab mit dem Signalgenerator an 50 Ohm Abschluß mit 1KHz mit Deinen 
Einstellungen getestet - alles ok.

> Auf Kanal drei zeigen sich mit dem Testsignal am Tastkopf größere
> Störungen/ Ausbrecher, nimmt man das Signal wieder weg schaut die Linie
> glatt wie zuvor aus.

Nicht meine Schuld, bzw. nicht die der FW. Das sind Störungen bzw. 
Schwingungen die zusätzlich eingekoppelt werden.

> Soweit gerade die ersten Dinge, die mir aufgefallen sind.

Danke für die schnelle Rückmeldung

> Ich hoffe es ist detailiert genug beschrieben. Ich bitte das Photo zu
> entschuldigen, aber ich denke man kann das von mir beschriebene erahnen.

Das Foto ist allerdings harter Toback. So sieht mein Gesichtsfeld nach 
einer durchzechten Nacht aus ;-)

Gruß Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

nein ich habe mich nicht verhauen. Ich habe die Tastköpfe verwendet und 
alle auf 10:1 eingestellt, hatte ich ja auch geschrieben.
Und wie gesagt, AC/DC-Coupling funktioniert bei mir mit der neuen FW 
nicht mehr korrekt.

Das Kanal drei Störungen zeigt wollt ich auch nicht auf die FW schieben, 
wollt es nur erwähnt haben.

Wegen dem Photo, so sieht das halt aus, wenn man das Telefon als Kamera 
verwendet.

Gruß, branadic (der die FW jetzt noch mal erneut aufspielt)

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So sieht das bei mir aus.

Hayo

von Michael W. (slackman)


Lesenswert?

Help compile...

Ich bekomme immer
michael@michael-laptop ~/W20xx_Firmware/src $ make all
# 2009.05.17.19:07:48 --- (Note: to make for Nios 16, try "make clean 
all M=16")
make: *** Keine Regel vorhanden, um das Target »obj/TomCat.cpp.o«,
  benötigt von »obj/TomCat.out«, zu erstellen.  Schluss.
-----

what's wrong?

Michel

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Und so die AC/DC Kopplung.

Das Signal hat einen DC-Offset von ungefähr halber Sigalamplitude wie 
man sehen kann.

Oben auf Kanal 1 DC-gekoppelt unten auf Kanal 2 AC-gekoppelt. alles wie 
gehabt bei 1 KHz an 50 Ohm

Hayo

von Johannes S. (demofreak)


Lesenswert?

Ich hab bisher nur die DAC-Kalibrierung getestet, und das klappt am 2024 
nunmehr einwandfrei. Alle Kanäle liegen genau auf der Höhe des 
Nullmarkers. Super Sache. :)

Jetzt stört an sich "nur" noch das utopische Rauschen. Solange man in 
den 5er Bereichen messen kann, geht es auch so, aber leider hab ich 
zufällig gerade eine Standardanwendung, wo es eben nicht klappt.

/Hannes

von Blue F. (blueflash)


Lesenswert?

Michael W. schrieb:
> Help compile...
>
> Ich bekomme immer
> michael@michael-laptop ~/W20xx_Firmware/src $ make all
> # 2009.05.17.19:07:48 --- (Note: to make for Nios 16, try "make clean
> all M=16")
> make: *** Keine Regel vorhanden, um das Target »obj/TomCat.cpp.o«,
>   benötigt von »obj/TomCat.out«, zu erstellen.  Schluss.

Wenn ich das richtig sehe hast Du die Anleitung nicht richtig gelesen.
Du machst Dein make all im Sourceordner, richtig? Du must dazu aber im
Buildordner sein, damit der Compiler alles findet. Steht auch in der
Anleitung.

Versuchs nochmal so.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Hannes

Tja den Rest Rauschen kann man nur Reduzieren, wenn man die 
Eingangsteilung verändert, und zwar so, dass der Fullscalebereich des 
ADC besser genutzt wird. In den 2er und 1er Bereichen werden nur 128 Bit 
genutzt. Dadurch muß das Signal so aufgezoomt werden, dass das Rauschen 
natürlich richtig heftig wird.

Hayo

von Blue F. (blueflash)


Lesenswert?

Was mir gerade so durch den Kopf geht -

Man könnte natürlich die vorhandenen Bereich umskalieren.

Der 1er Bereich wäre dann ein 2er Bereich und der 2er ein 4er. Damit 
sollte das Rauschen dann minimal sein. Die Schrittweite beim Umschalten 
wäre dann allerdings nicht mehr normgerecht.

Hayo

von Johannes S. (demofreak)


Lesenswert?

Hm, das ist mir ansatzweise klar, und ich warte ja schon sehnsüchtig, 
dass ihr euch im Zusammenspiel zwischen Hardware- und Firmwarefraktion 
eine ganz tolle neuartige Methode einfallen lasst. :-D

/Hannes

von branadic (Gast)


Lesenswert?

Hallo Hayo,

ich hab die FW erneut aufgespielt, es ändert sich nichts.
Der Faktor auf Kanal 2 hat sich als Faktor 10 herausgestellt. Ich messe 
direkt mit dem Tastkopf an der Probe-Buchse. Ich lass das Gerät jetzt 
mal eine Weile laufen und mache nachher ein paar Messungen mit dem 
DDS-10.
Die deutlich größeren Störungen auf Kanal 3 waren in den vorherigen 
FW-Versionen nicht so extrem. Werd noch mal ein wenig herumspielen.

AC/DC-Coupling macht bei mir keinen Unterschied, keine Ahnung was da los 
ist.

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

branadic schrieb:

> Der Faktor auf Kanal 2 hat sich als Faktor 10 herausgestellt. Ich messe
> direkt mit dem Tastkopf an der Probe-Buchse.

> Die deutlich größeren Störungen auf Kanal 3 waren in den vorherigen
> FW-Versionen nicht so extrem. Werd noch mal ein wenig herumspielen.
>
> AC/DC-Coupling macht bei mir keinen Unterschied, keine Ahnung was da los
> ist.


Bei allen drei Punkten spielen Dir garantiert die Tastköpfe einen 
Streich. Deshalb mache ich meine Testmessungen auch immer an 50 OHm, 
denn da gilt:

What You see it what You mess (oder so ähnlich).

Hayo

von Blue F. (blueflash)


Lesenswert?

Ich kann übrigens gerne mal eine umskalierte Fassung raushauen, wenn Ihr 
mal sehen wollt wie das aussieht. Müßt Ihr nur sagen...

Hayo

von Jürgen (Gast)


Lesenswert?

Hallo zusammen!

@Hajo

Irgend etwas stimmt wohl doch nicht mit Deiner Erklärung?
Laut Stromlaufplan und laut meiner Messung mit Multimeter sollte das 
1kHz Referenzsignal doch etwa symmetrisch um die Masse liegen. Ergo 
sollte es keinen Unterschied zwischen AC- und DC-Kopplung geben!

Oder?

Gruß Jürgen

von Guido (Gast)


Lesenswert?

Hallo Hayo,

die Spannungsbereiche lassen sich ja noch leicht etwas verbessern,
wenn man die Verstärkungen 1.25/2.5/5 wählt. Hatte ich mal eine
Firmware mit gebaut, bin aber nicht zum Testen gekommen und
sonst hatte wohl auch keiner Lust.
Damit hätten wir 200/160/160 Werte. Hätte mich interessiert, warum
Wittig das geändert hat.

Ein 4er Bereich neben dem 5er ist halt suboptimal.

Gruß, Guido

von Guido (Gast)


Lesenswert?

P.S.: @ Hayo: Kannst du den verdammten Testgenerator in der
Betaphase nicht einfach disablen? Es gäbe dann weniger
Messfehler ;-).

Guido

von Kurt B. (kurt)


Lesenswert?

Ja, das Testsignal ist AC! 800mVSS. Bei mir ohne Offset.

von Blue F. (blueflash)


Lesenswert?

Jürgen schrieb:

> Irgend etwas stimmt wohl doch nicht mit Deiner Erklärung?
> Laut Stromlaufplan und laut meiner Messung mit Multimeter sollte das
> 1kHz Referenzsignal doch etwa symmetrisch um die Masse liegen. Ergo
> sollte es keinen Unterschied zwischen AC- und DC-Kopplung geben!

Meine Tests sind alle mit einem externen Signalgenerator durchgeführt an 
50 Ohm. Wenn ich im DC-Betrieb einen Offset draufgebe wird dieser auch 
korrekt dargestellt. Bei AC-Kopplung geht das Signal kurz mit dem Offset 
mit und geht dann aber wieder auf Mitte.

So soll es doch auch sein oder?

Was das Testsignal angeht, ich hab es mit dem Tastkopf gemessen - wie Du 
schon sagst, da es keinen DC-Offset hat sieht es in beiden 
Kopplungsarten gleich aus.

Hayo

von Michael W. (slackman)


Lesenswert?

Hi Hayo,
das Build fehlte, besten Dank. Bei Google groups war es aber nicht oder? 
Nur Dein neues war da. Nun bekomme ich:
...
# 2009.05.17.20:12:57 --- Converting TomCat to S-Record
cat loader.flash > TomCat.flash
cat TomCat.srec >> TomCat.flash
unix2dos TomCat.flash
# 2009.05.17.20:12:57 --- Making TomCat.nm
# 2009.05.17.20:12:57 --- Making TomCat.objdump
Segmentation fault
make: *** [obj/TomCat.objdump] Fehler 139
michael@michael-laptop ~/Build $
....
'n Tipp?

Danke
Michel

von Jürgen (Gast)


Lesenswert?

Hayo schrieb:

> Meine Tests sind alle mit einem externen Signalgenerator durchgeführt an
> 50 Ohm. Wenn ich im DC-Betrieb einen Offset draufgebe wird dieser auch
> korrekt dargestellt. Bei AC-Kopplung geht das Signal kurz mit dem Offset
> mit und geht dann aber wieder auf Mitte.

Ach so, na dann passt ja alles!

Vielleicht hat Guido ja Recht mit disablen des Testgenerators ;-)

Jedenfalls ist die Bildwiederholrate in der 0.62-er super!

Jürgen

von branadic (Gast)


Lesenswert?

So, ich habe jetzt noch mal die FW neu aufgespielt, alle Leitungen 
gegengeprüft, da war tatsächlich der Wurm drin und alles kalibriert.

AC/DC funktioniert jetzt auch bei mir, hab jetzt mein DDS10 dran und 
einen Rechteck angeschaltet.

Das Terminalprogrammt spuckt nach der Kalibrierung und dem Abspeichern 
der Werte auf allen ADC's einen Offset von 0 aus.
Die DAC-Korrekturwerte liegen bei mir zwischen 82 und 133.

Was aber als Behauptung stehen bleibt ist, dass Kanal 3 bei mir schon 
mal in einer der vorherigen Versionen schöner aussah.
Die Störungen sind bei einem Rechtecksignal noch recht klein, schalte 
ich aber auf Sinus um machen sich die Störungen um so mehr bemerkbar.
Aber etwas ähnliches hatten wir ja schon einmal als Thema. Bei Kanal 3 
schein Welec irgendwas versaut zu haben.

In der x-y-Darstellung scheint der Offset von Kanal 1 und 3 invertiert 
zu sein. Dreh ich nach links wandert das Signal nach rechts. Muss ich 
hier nur umdenken oder sollte das nicht anders sein? Ich meine mich 
daran erinnern zu können, dass das beim Tek anders ist.

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

Michael W. schrieb:
> Hi Hayo,
> das Build fehlte, besten Dank. Bei Google groups war es aber nicht oder?
> Nur Dein neues war da. Nun bekomme ich:

Wie schon oben geschrieben:

http://groups.google.com/group/welec-dso/files

-> BlueFlash_Build_0_62.zip


> make: *** [obj/TomCat.objdump] Fehler 139

Den 139 er Fehler bekomme ich momentan auch. Weiß aber nicht woran es 
liegt. Betrifft aber anscheinend nicht die erzeugte Firmware, denn die 
läuft trotzdem problemlos. So wie es aussieht ist es nur der Objektdump 
der davon betroffen ist.

Hayo

von Michael W. (slackman)


Lesenswert?

@Hayo:

ich hatte Deinen Build bei Google Groups schon gefunden nur das 
Originale nicht. Und die paar Dateien in den Firmwareupdates kamen mir 
für ein Build immer sehr wenig vor.

Denn kann's jetz ja für mich auch losgehen :-)

Kann man die Source für den Updater irgendwo laden? Ich finde nur 
'Exen'...

Michel

von sunny (Gast)


Angehängte Dateien:

Lesenswert?

ich hab hier auch so eine fw bei der in allen bereichen die 1,25 
vorverstärkung aktiv ist. es ist die .59 von hayo. falls jemand sich mal 
den unterschid ansehen will.

@hayo
ist denn die änderung für adc fullscale nicht ziemlich umständlich? es 
müssten ja eine menge änderungen gemacht werden. ein interessanter test 
währe es sicherlich.

von Bruno W. (brunowe) Benutzerseite


Lesenswert?


von Blue F. (blueflash)


Lesenswert?

sunny schrieb:

> ist denn die änderung für adc fullscale nicht ziemlich umständlich? es
> müssten ja eine menge änderungen gemacht werden. ein interessanter test
> währe es sicherlich.

Ist schon in Arbeit, kommt nachher, muß erstmal uploaden und testen.
War selbst mal neugierig...

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hier die umskalierte 0.62 experimental. Sehr eindrucksvolle 
Demonstration dessen was ich an Theorie hier schon zum Besten gegeben 
habe.

Besonders interessant für diejenigen, die wie ich zwei Geräte haben und 
daher direkt den originalen 200mV Bereich mit dem umskalierten 200mV 
Bereich vergleichen können.

Wenn jetzt der Eingangsteiler für die 4er und für die 2er Bereiche um 
Faktor 2 angepasst würde (Widerstände ändern) dann hätten wir auch 
wieder unsere 2er und 1er Bereiche aber mit dem reduzierten Rauschen.

Wenn ich mir das so ansehe bin ich echt am Überlegen ob ich mir da ein 
paar andere Widerstände reinlöte.

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Kleiner Vergleich für alle!

Hier die originale Skalierung...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...und im Vergleich die umskalierte Fassung.

Alles mit dem gleichen Signal.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...und hier zum direkten Vergleich der originale 100mV Bereich der ja 
der umskalierte 200mV Bereich ist

Hayo

von Odic X. (odic)


Lesenswert?

Guten Abend zusammen,

vorab erstmal meine volle Hochachtung an alle, die hier Zeit und Nerven 
investieren, um nicht nur sich sondern auch der Allgemeinheit etwas 
Gutes zu tun.

Da ich momentan selbst auf der Suche nach einem günstigen DSO bin, 
verfolge ich die Entwicklungen um die Wittig- Oszis seit etwa einer 
Woche. Mit den ständigen Verbesserungen werden die Geräte zunehmend 
interessanter für mich. Leider habe ich aber bis dato noch kein 
vollständiges Bild im Kopf, was die Geräte denn nun können und was 
nicht. Gibt es denn irgendwo eine Übersicht die darstellt, was

- fehlerfreie Funktionen
- eingeschränkt benutzbare Funktionen
- fehlende / nicht nutzbare features

an diesem Gerät (gemessen an normalen Eigenschaften eines DSO in der 
Leistungsklasse) sind?
Falls es so etwas nicht gibt: lässt sich sagen, was die gravierendsten 
Vor- und Nachteile, beispielsweise im Vergleich mit einem TDS210 o.ä. 
sind?

Das würde mir eine Kaufentscheidung deutlich erleichtern....

Viele Grüße und macht weiter so,

odic

von Guido (Gast)


Lesenswert?

Hallo Hayo,

mal langsam zum Mitdenken. Du hast jetzt die Verstärkung des OPA
auf 1 geschaltet (keine Umschaltung mehr) und damit insgesamt die
Verstärkungen 1-2-4. Richtig? Damit wird Auflösung verschenkt.
Oder hast du 1,25-2.5-5 mit dem OPA immer auf Vu=1.25?

Welche Widerstände willst du denn umlöten? Da stehe ich völlig auf
dem Schlauch.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Odic

Es kommt auf Dein Einsatzgebiet drauf an. Für den Hobbybereich bei 
Frequenzen bis 25 MHz auf jeden Fall ein Schnäppchen. Bei höheren 
Ansprüchen nur nach Verbesserungen an Hard und Software. An beidem sind 
wir dran - allerdings ohne Garantien. Für professionelle Zwecke lieber 
ein Tek oder Agilent.

Hayo

von Guido (Gast)


Lesenswert?

Hallo odic,

ganz klar: wenn du ein Oszi für die tägliche Arbeit suchst, lass
die Finger von dem Welec. Wenn du für rel. wenig Geld ein tolles
Spielzeug mit Zukunft willst, bist du damit bestens bedient. Afaik
gibt es am Welec keine fehlerfrei Funktion, viele sind aber schon
benutzbar.

Soweit erstmal, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> mal langsam zum Mitdenken. Du hast jetzt die Verstärkung des OPA
> auf 1 geschaltet (keine Umschaltung mehr) und damit insgesamt die
> Verstärkungen 1-2-4. Richtig?

Falsch. Ich hab an der Verstärkung nix geändert. Ich hab bloß die 
Skalierung für die Ausgabe geändert. Dadurch bleibt der 5er Bereich ein 
5er Bereich aber der 2er wird ein 4er und der 1er wird ein 2er Bereich.

Ergibt die Schritte 5V/4V/2V/0,5V/0,4V/0,2V usw

> Welche Widerstände willst du denn umlöten? Da stehe ich völlig auf
> dem Schlauch.

Wenn ich das richtig in Erinnerung habe gibt es ein Widerstandsnetzwerk 
welches eine Vorteilung vornimmt (korrigier mich wenn ich da falsch 
liege). Wenn man die Vorteilung für die beiden Bereiche um Faktor zwei 
ändert dann kann man mit der umskalierten FW wieder mit den normalen 
Bereichen arbeiten 5V/2V/1V/etc.

Hab ich das vernünftig erklärt oder war das eher konfuziös?

Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

ich fürchte heute wird das bei mir nix mehr. Wird aber langsam besser.
Ich glaube jetzt kann ich dir folgen (habe gerade 3 mal editiert).

Die Teiler sind aber nur für die Bereiche ab 100 mV/div zuständig,
Mit der Änderung fliegen die Grundbereiche 50-20-10 mV/div über
Board. Das ginge wieder nur mit mehr (Hardware-) Verstärkung.

Ich muss jetzt gleich noch einen (kurzen) Testberich schreiben.

Gruß, Guido

von Guido (Gast)


Lesenswert?

So jetzt sauber getrennt zur Beta 0.62:

@ Hayo: Super, die Kalibrierung von ADC und DAC funktioniert für
meine 2 Kanäle perfekt. Das ist wirklich ein Fortschritt, die
Testfunktionen können dann gelegentlich entfernt werden (damit
die Tasten frei werden ;-)).

Eine kleine Unstimmigkeit ist mir noch aufgefallen: Im Delayd-Mode
werden die Offset-Marken für beide Kanäle im unteren Fenster leicht
verschoben dargestell. Im oberen Fenster sind sie korrekt.

Nochmal Gruß, Guido

von Jürgen (Gast)


Lesenswert?

Hallo Hajo, hallo Guido,
100% Ack für Guido! Was soll wohin scaliert werden? Es kann alles 
angepasst werden. Wo haben wir definiert was 100% für die Anzeige sind? 
Bisher sind sicher nur 8Bit für 100% definiert :-) Sind 100% ADC jeweils 
8 Divs(mit entsprechendem Faktor) = 100% TFT in jedem (1,2,5-er)Bereich? 
Wollen wir uns an die üblichen Bereiche 1-2-5 halten?Alles weitere 
leitet sich daraus ab. Mit Sicherheit ergeben die kleinsten 
Softwarefaktoren auch das geringere Rauschen!
Dank Hajo`s bisheriger fantastischer Arbeit ist ein guter Stand 
erreicht, aber es gibt genug Baustellen, die abgearbeitet werden müssen: 
z.B. Triggerung allgemein, PW-Triggerung, USB-Comm... usw., somit die 
endgültige Scalierung wohl auch von den Ergebnissen an der HW-Seite 
abhängt! Die Scalierung sollte nach meiner Meinung jetzt nicht mehr die 
höchste Priorität haben.

Gruß Jürgen

von Odic X. (odic)


Lesenswert?

"keine fehlerfreie Funktion"... höre ich da einen gewissen Zynismus? ;-)

Danke für eure Antworten, ich muss aber doch nochmal nachhaken. Ich 
vermute, dass noch niemand eine vollständige Qualifizierung des Geräts 
durchgeführt hat. Daher frage ich gar nicht nach Punkten wie 
Messgenauigkeit, Temperaturverhalten o.ä.

Vielmehr interessieren mich ganz pragmatische Punkte, die für ein 
halbwegs vernünftiges Arbeiten mit dem Scope - selbst im Hobbybereich - 
erforderlich sind. Hiermit meine ich beispielsweise:

- Skalierung von Amplitude und Zeitachse (schrittweise / frei, auch nach 
der Triggerung)
- Verschieben der Signale in X- und Y-Richtung (auch nach der 
Triggerung)
- (funktionierende) Einstellmöglichkeiten für die Triggerung (Single, 
Normal, Auto, Triggerquelle, ...) und deren Zuverlässigkeit
- Möglichkeiten der Signalkopplung
- ...

Vielleicht könnte man - falls es so etwas noch nicht gibt - mal eine 
Liste von Oszi-Eigenschaften inkl. (subjektiver) Bewertung deren 
technischer Umsetzung im Wittig-Scope erstellen.

Ich habe zwar selbst kein Gerät, kann mich aber an der Erstellung der 
Kriterien gerne beteiligen...

odic

von sunny (Gast)


Lesenswert?

hi hayo,

die ergebnisse sehen ja ganz nett aus. mit der änderung der verstärkung 
des eingangsverstärkers ist das so eine sache. die verstärkungen für die 
1,2 und 5er bereiche werden nicht durch ein wiederstandsnetzwerk 
festgelegt.
es sind 3 volldifferenzial opv's verbaut welche intern fest auf eine 
verstärkung von 2 eingestellt sind. die umschaltung der verstärkungen 
erfolgt, indem 2 der 3 opv's etweder mit einem symetrischen (effektive 
verstärkung=2) oder mit einem asymetrischen eingangssignal (effektive 
verstärkung=1) betrieben werden. dafür wird jeweils ein eingang durch 
einen analogschalter etweder auf masse oder auf den ausgang des vorigen 
opv geschaltet.
man müsste diesen verstärkerteil also neu designen. daran arbeite ich 
zzt. komm nur im momment nicht so recht weiter. wer interesse hat, kann 
hier noch etwas mehr darüber lesen. 
http://d-amp.org/include.php?path=forum/showthread.php&threadid=586&postid=last

von Guido (Gast)


Lesenswert?

Hallo odic,

>"keine fehlerfreie Funktion"... höre ich da einen gewissen Zynismus? ;-)

nö, kein Zynismus, uns macht das ja Spaß. Es ist halt momentan wirklich
so, dass die von dir angesprochenen Eigenschaften (was verstehst du
unter: nach der Triggerung?) vorhanden sind, zum größten Teil aber nicht
das gewünschte Ergebnis bringen. Wie du dem Thread entnehmen kannst, 
wird
noch an der Darstellung der Messwerte auf dem Bildschirm gearbeitet, da
diese unbefriedigend ist. Die anderen Dinge (z.B. eine funktionierende
Triggerung) sind erstmal aufgeschoben, aber je mehr Leute sich an der
Entwicklung beteiligen, desto schneller geht es.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Sunny

Hm, schade, dann ist die Änderung der Vorteilung wohl doch etwas 
schwieriger. Wenn Du und Bruno da weiter kommen könnte es ja dennoch was 
werden. Ihr könnt ja auf jeden Fall die Anforderung im Hinterkopf 
behalten.


@Odic

Die Punkte die Du hier aufzählst sind eher als unkritisch einzustufen. 
Entweder sie sind schon benutzbar oder sie lassen sich rein 
Softwaretechnisch nachrüsten. Kritischer ist da die Reduzierung des 
Rauschens welches als eines der Hauptmankos von den meisten hier 
wargenommen wird.

Dennoch läßt sich mit dem Gerät auch jetzt schon eine Menge im 
Hobbybereich anstellen. Nicht zuletzt ist es eine schöne Spielwiese für 
Optimierungswütige!

Eine kleine Sammlung an Punkten findest Du in dem Beta-Paket in der 
readme Datei (bzw. liesmich) und im Header der tc_vars.cpp.

Hayo

von Kurt B. (kurt)


Lesenswert?

Wie steht es eigentlich um die QuickMeasure Funktionen? Währe schön, 
wenn die wieder funktionieren würden.

von Michael W. (slackman)


Lesenswert?

Hi,
bei mir leider nicht alles ok nach dem neuen Update...
Werde wohl nochmal flashen.
Probleme:
Kanal 1 und 4 triggern nicht, Kanal 2 nur auf fallend und Kanal 3 auf 
steigender Flanke. Da ist MEIN Build wohl doch nicht erfolgreich 
gelaufen. Werde ich Hayo's Kater nochmal flashen (müssen)... :-/

Michel

von Blue F. (blueflash)


Lesenswert?

@Kurt

Quick Measure und Cursorpositionen muß ich noch machen, das hatte ich 
erstmal aufgeschoben bis die Skalierungsfragen geklärt sind, sonst muß 
ich das evtl. doppelt machen.


@Michael

der Trigger funktioniert leider auch bei mir nur bedingt. Insbesondere 
Rechtecksignale scheint er nicht zu mögen, während es bei Sinus 
erheblich besser klappt. Auch das ist noch eine offene Baustelle die 
ebenfalls mit der Skalierung zusammenhängt und deshalb von mir 
aufgeschoben wurde. Dazu kommt, das mir die technische Umsetzung der 
Triggerung noch nich so ganz klar ist.

Vom Coding her habe ich den Eindruck, dass es eine kombinierte Harware- 
und Softwaretriggerung ist. Es werden für die Triggerung einige Register 
gesetzt deren Zweck ich erst ergründen muß und es wird das Signal 
Softwareseitig je nach Triggerung im Fensterausschnitt hin und her 
geschoben.

Vielleicht können die Jungs von der Hardwarefront hier etwas zur Klärung 
beitragen. Ich wüßte auch nicht, wie sonst der externe Trigger 
realisiert sein sollte wenn nicht hardwareseitig.

@all

Da jetzt doch einige Köche im Brei rühren hier zur Abstimmung ein kurze 
Roadmap die ich mir vorgenommen habe:

- Codeoptimierung an der Skalierung, wird nach außen nicht weiter
  sichtbar sein, wird aber den Code wartbarer bzw. erweiterbarer machen
  für den Fall dass wir die Verstärkung Hardwareseitig ändern.

- Rollmode/Shiftmode für die ganz langsamen Zeitbasen implementiern.
  Hierzu hab ich mir inzwischen einige Gedanken gemacht und das
  Konzept steht schon (in Rohfassung)

- Trigger und Cursor auf die neue Skalierung anpassen evtl. bei der
  Gelegenheit die Triggerung optimieren

- Mathfunktionen noch mal an die neue Integerskalierung anpassen.

- FFT implementiern. Hab ich teilweise schon implementiert, aber zur
  Zeit deaktiviert angesichts der drängenden Probleme an anderen 
Stellen.


Eine echte Hilfe wäre es wenn diejenigen, die neu einsteigen sich mit 
dem Coding vertraut machen indem sie nach Fehlern suchen oder 
grundsätzliche Funktionen erforschen wie z.B.:

- es wird nach meiner Vergrößerung des Grids immer noch der untere Rand
  des Signals abgeschnitten. Fehler liegt vermutlich irgendwo in
  CopyPlanes() und/oder TransferPlanes() an der Größe der übertragenen
  Bildschirmabschnitte.

- Im delayed mode hab ich leider noch eine Verschiebung drin zwischen
  oberem und unterem Fenster.

- Wie arbeitet die Triggerung im Detail?




Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

die ext. Triggerung wird wohl hauptsächlich in Hardware erledigt
(Schwelle über PWM, ..., Ausgang direkt auf den FPGA). Ich habe
den Eindruck, dass die interne Triggerung nur über Software
simuliert wird. Bei meinen 2 Kanälen geht es mit der 0.62, aber
halt nur, wenn das Signal den halben Bildschirm füllt.

Das abgeschnittene Signal kommt imho nicht von TransferPlanes,
da dort die Grenzen für alle Planes gleich sind und das Grid...
ja korrekt überttragen werden. Da muss man die ganze Kette ab
READADC_ALL untersuchen. Habe jetzt von Stefan nichts mehr
gehört, wenn er sich nicht mehr meldet, nehme ich mir das mal
vor.

Ev. sollte man die Roadmap als Artikel im Wiki anlegen, da kann
sich dann jeder mit Wünschen und Arbeitswillen melden. Das
kann doch bestimmt jemand besser als ich?

@ Kurt: Hat das QuickMeasure denn mal halbwegs vernünftig
funktioniert? Ich habe es nie ausprobiert. Es gibt da eine
Funktion CALCQMDATA, die ist mehr als 2400 Zeilen lang. Ich denke,
da muss man erstmal Struktur reinbringen.

Gruß, Guido

von Kurt B. (kurt)


Lesenswert?

Halbwegs vernüftig ja. Aber doch recht ungenau und nicht immer in sich 
schlüssig.

Man sollte wirklich mal eine Wiki Seite machen: Wer arbeitet aktuell 
woran, wer testet auf welchem Gerät, an welchen Problemen wird z.Zt. 
nicht gearbeitet und aus welchem Grund...

Mein W2024 ist seit Donnerstag unterwegs. Hoffentlich kommt es Heute. 
Dann kann ich die offizielle Firmware noch einigen Test unterziehen.

von Blue F. (blueflash)


Lesenswert?

@Guido

Ich bin mir da nicht sicher ob evtl. doch auch auf Hardwarebasis 
getriggert wird. Das gilt es aber auf jeden Fall zu klären bevor wir da 
am Coding rumschrauben

Wenn Du die Sache mit dem abgeschnittenen Signal fixen könntest wär das 
natürlich super. Mein Ansatz war, einfach mal die einzelnen Planes 
abzuschalten (in Transfer Planes auskommentieren) evtl. auch mehrere 
gleichzeitig und dann mal sehen von welcher Plane das Signal 
überschrieben wird. Das schränkt die Suche doch ungemein ein. 
Hauptverdächtige sind ohnehin die unteren Bereiche der UI-Planes evtl. 
auch die Marker-Plane.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Gibt es die offizielle FW1.4 eigentlich als Download auf Wittigs 
Homepage? ansonsten stelle ich sie gerne als Flashdump zur Verfügung.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Guido

Wenn ich mir das so überlege wäre es natürlich noch sinnvoller die 
Stellen auszukommentiern an denen ClearPlanes() aufgerufen wird.

Hayo

von Guido (Gast)


Lesenswert?

@ Hayo: Das ist aber eigentlich nur im UserInterface.

Guido

von branadic (Gast)


Lesenswert?

Hallo Hayo,

die aktuelle FW1.4 wurde nicht von Wittig/Welec auf der Homepage bereit 
gestellt.
Das mit dem Wiki (im Sourceforge) halte ich für eine gute Idee, zum 
jeder angemeldete User Änderungen vornehmen kann.

Vielleicht können wir da heute Abend was in Angriff nehmen.

Gruß, branadic

von Jürgen (Gast)


Lesenswert?

Hallo Hayo,

ein Backup der FW1.4 vom 2024A gab es hier:

Beitrag "Re: Wittig(welec) Oszilloskop firmware problem"

Gruß
Jürgen

von Guido (Gast)


Lesenswert?

Hallo,

Problem gelöst, es müssen in den Transfer-Routinen halt einfach
die zusätzlichen 16 Zeilen transferiert werden. Hierzu habe ich
einfach den Loop-Counter entsprechend erhöht.

@ Hayo: einfach in hardware_t vom Editor alle 7740 durch 8060
ersetzen lassen, das wars. Die Zahlen sind dezimal in Longwords,
falls jemand nachrechnen möchte.

Gruß, Guido

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Achso,

falls es sich jemand anschauen möchte.

Guido

von branadic (Gast)


Lesenswert?

Hallo Guido,

welche FW-Version hast du verwendet? Die letzte Beta von Hayo?

Gruß, branadic

von Guido (Gast)


Lesenswert?

Hallo branadic,

>welche FW-Version hast du verwendet? Die letzte Beta von Hayo?

jepp, wie immer (also die 0.62).

Gruß, Guido

von Stefan (Gast)


Lesenswert?

Hallo Guido,

>Das abgeschnittene Signal kommt imho nicht von TransferPlanes,
>da dort die Grenzen für alle Planes gleich sind und das Grid...
>ja korrekt überttragen werden. Da muss man die ganze Kette ab
>READADC_ALL untersuchen. Habe jetzt von Stefan nichts mehr
>gehört, wenn er sich nicht mehr meldet, nehme ich mir das mal
>vor.

Das WE war leider keine Zeit. Ein abgeschmierter Xp-Rechner in einer 
saublöden Hardwarekonfiguration hat den ganzen Sonntag gekostet...

In den ganzen READADC-Assembler-Funktionen steige ich einigermaßen 
durch. Wie ihr sicher erwartet habt, ist das nicht für schwache nerven, 
wenn ich euch jetzt ein paar Details erzähle. Das der Code überhaupt je 
funktionsfähig wurde, grenzt fast an ein Wunder.

@Hayo
Ich bin mir nicht sicher, wie weit du dich in den Assembler-Code 
eingearbeitet hast, weil da ein Fragezeichen im Code angefügt ist. Für 
das Verständnis erkläre ich mal einwenig den Ablauf der einzelnen 
Funktionen

Also: zuerst muss READADC_ALL2 aufgerufen werden. Die Funktion liest den 
genannten Kanal aus und speichert die gewünschte Anzahl Werte im 
Speicher an der Andresse DataArray1.

Danach muss PREPARE_READADC aufgerufen werden. Die Funktion speichert 
die Offsetwerte der vier ADC eines Kanals und die Anzahl der Samples in 
globale Register.

READADC_ALL liest die in READADC_ALL2 eingelesenen Daten wieder aus und 
sortiert um, verarbeitet sie weiter (invertieren, Offset-Abgleich, 
Averaging) und speichert sie wieder ab. Die which-Parameter wird (so 
sehe ich das) nicht abgefragt (ist also überflüssig).

Problematisch ist der Code an mehreren Stellen:
- Die Übergabe der einzelnen Funktionen erfolgt über globale Register 
(gibt davon insgesamt 7 Stück). Da zwischen den ASM-Blöcken noch C-Code 
liegt ist meineserachtens nicht sichergestellt, dass die Register auch 
noch richtig gesetzt sind. Vielleciht ist irgendwo noch ein 
Schutzmechanismus. So gut kenne ich mich damit aber nicht aus.
- In READADC_ALL2 kann man zwar einen anderen Adressbereich zum 
Zwischenspeichern als Parameter angeben. Davon ist ab schwer davon 
abzuraten genauso wie vor jeder Veränderung der Speicheraufteilung im 
RAM. In den ASM-Blöcken finden sich nämlich Hart-Codierte Adressen 
wieder. Alle Stellen zu finden, wo der Entwickler zu faul war, 
Konstanten oder Zeiger zu verwenden, dürfe ziemlich aufwendig werden ;-)

Das Invertieren und Averaging findet unter Einbeziehung des 
ZeroLevel-Wertes statt. Der Offset zum ZeroLevel wird allerdings erst 
nach dem Averaging und Invertieren subtrahiert. Das ist wohl nicht 
wirklich schlau ;-), da der Offset-Abgleich (zumindest beim Invertieren) 
in die falsche Richtung wirkt

Gruß,
Stefan

von branadic (Gast)


Lesenswert?

Hallo Firmware-Gemeinde,

ich war mal so frei im Sourceforge-Wiki eine Seite für die Firmware 
anzulegen. Ich war außerdem mal so frei Hayo's aufgeführte Roadmap 
gleich mit zu übernehmen.
Soviel ich weiß hat Hayo ja einen Souceforge-Account. Alle anderen 
FW-Entwickler würde ich bitten wollen, sofern nicht vorhanden, einen 
solchen Account anzulegen, damit ihr im Wiki aktualisieren könnt.

Somit hätten wir eine gemeinsame Plattform, wo auch die Firmware erfasst 
ist. Natürlich können wir die Seite um die bereits implementierten 
Funktionen erweitern.

Beste Grüße, branadic

von branadic (Gast)


Lesenswert?

So, weil es so viel Spaß macht zu posten, hier nun auch noch der Link:

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

So long, branadic :)

von Guido (Gast)


Lesenswert?

Hallo Stefan,

schön von dir zu hören ;-).

über die Inputregister würde ich mir nicht allzuviel Gedanken
machen, davon gibt es ja mehrere Sätze und ich unterstelle
einfach, dass der C-Compiler das im Griff hat.

Sowas mit der verdrehten Reihenfolge habe ich vermutet,
vielleicht kannst du das einfach mal umdrehen und probieren.
Wenn es dann doch wieder Probleme gibt, müssen wir da halt
tiefer einsteigen.

æ branadic: Bravo, mit direktem Link, damit sogar ich das finde.
Muss ich gleich verbookmarken. Ev. sind ja da die Ladezeiten
kürzer als heute im mikrocontroller.net.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Mann! Da ist (bzw. ißt) man nur kurz beim Griechen und schon geht hier 
die Post ab.

@Guido

Super, das hat mich schon die ganze Zeit genervt. Aber irgendwie hatte 
ich auch keine Lust danach zu suchen. Sehr cool! Werd das mal gleich 
einbauen.


@Stefan

Na das nenne ich eine echte Detailanalyse. Den groben Ablauf hatte ich 
mir schon so rausgelesen, zumindest reichte es aus die Funktionen in 
meinen Abgleichroutinen einzusetzen. Aber was da im Detail abging hatte 
ich noch nicht raus. Allerdings überrascht es mich irgendwie nicht, das 
die grundlegenden Hardwareroutinen genauso zusammengeschustert sind wie 
der Rest. D.h. wir müssen die ADC-Korrektur vor die Averaging und 
Invert-Routine verlegen. Fühlst Du Dich berufen da Hand anzulegen?


@Branadic

Prima, das ist eine gute Idee und ja, ich hab einen User für SFN. 
Allerdings gebe ich zu, dass  die etwas anstrengende Menüstruktur und 
Handhabung mich immer etwas abgeschreckt hat. Aber das ist natürlich ein 
Grund sich da nochmal ranzusetzen.


@all

Ich freue mich über die inzwischen so aktive Hilfe und Resonanz. Wie man 
sieht beschleunigt das den Prozess doch ungemein.
So werd mich mal schnell noch etwas ins Coding stürzen - Das Forum hab 
ich dabei natürlich im Blick...


Hayo

von egberto (Gast)


Lesenswert?

Pass aber auf wegen der vielen Ouzos ;-))

von branadic (Gast)


Lesenswert?

So Jungs,

ich hab noch ein wenig in der Menu-Struktur herumgefuscht. Von der 
Firmware-Page aus könnt ihr nun also in die Roadmap, in die History und 
in die Wish-List wechseln. Hat alles seine eigene Seite, damit es auch 
übersichtlich bleibt.

Ihr dürft euch jetzt an den Seiten verlustieren und erweitern.

Gruß, branadic

von Michael W. (slackman)


Lesenswert?

Hallo Hayo,

ich wollt' Dich nochmal gerne ärgern:
Gerade habe ich die 0.59 Firmware eingespielt, weil ich mir sicher war, 
dass flankengesteuertes Triggern auf allen Kanälen funktionierte - und:
jawoll! In der 0.59 funktionierte die Triggerung besser als in der 
Neuen.
Hier hast Du also irgendwas verändert, was nicht gut war.
(Obwohl mir der Abgleich wirklich gut gefällt, Triggerung ist mir fast 
noch wichtiger.)
Zusammenfassung:
0.59: flankengesteuertes Triggern auf allen vier Kanälen sowohl steigend 
als auch fallend: ok
0.62: Kanal 1 & 4: keine flankengesteuerte Triggerung möglich
Kanal 2: nur steigent; Kanal 3: nur fallend.

Jámas! alter Grieche ;-)

Michel

von Michael W. (slackman)


Lesenswert?

Ach ja: Testsignal war der interne Rechteck

Michel

von Robert (Razer) (Gast)


Lesenswert?

Hallo Hayo,

Habe gerade eben auch die 0.62 geflasht.
Auf Kanal 1 u. 4 funktioniert bei mir auch keine flankgengesteuerte 
Triggerung.

Auf Kanal 2 funktioniert nur die Triggerung auf die fallende und auf 
Kanal 3 nur eine Triggerung auf steigende Flanke.

lg Robert (W2024A)

von Blue F. (blueflash)


Lesenswert?

Hm...

dann muß ich nochmal sehen was ich da geändert habe. meines Wissens hab 
ich an der Triggerung nichts geändert. Allerdings hab ich ein Register 
für Kanal 3 + 4 anders gesetzt. Ich Schau mal - wir wollen ja auch keine 
Rückschritte machen.

Hab übrigens die Korrektur von Guido eingespielt, sieht gut aus so ohne 
abgeschnittenes Signal.

Bis morgen

Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

@Guido,
es werden noch einige Pixel nicht richtig gesetzt.

@Hayo,
Wenn man misst und auf Stop drückt kann man ja in das Signal rein oder 
raus zoomen. Dabei wird aber immer eine neu Messung gestart sodass die 
alten Werte verloren gehen. Allerdings nur beim Autotrigger. 
Normaltrigger und Singe Shot sind OK.

von Stefan (Gast)


Lesenswert?

@Stefan

>D.h. wir müssen die ADC-Korrektur vor die Averaging und
>Invert-Routine verlegen. Fühlst Du Dich berufen da Hand anzulegen?

Nach dem ich es jetzt geschafft habe, mit dem Makefile von Günter Jung 
und gtkTerm, das Programm direkt in den Ram den Oszilloskops zu laden, 
mach ich das doch glatt.

Ist echt praktisch, läuft nur ca 3min, auch unter Linux und über einen 
RS232-Wandler. Bei mir war es nur zusätzlich noch nötig, gtkTerm auf das 
"+" als Bestätigung vom Oszilloskop warten zu lassen und schon ging die 
Post ab.

von Blue F. (blueflash)


Lesenswert?

Stefan schrieb:

> Nach dem ich es jetzt geschafft habe, mit dem Makefile von Günter Jung
> und gtkTerm, das Programm direkt in den Ram den Oszilloskops zu laden,
> mach ich das doch glatt.
>
> Ist echt praktisch, läuft nur ca 3min, auch unter Linux und über einen
> RS232-Wandler. Bei mir war es nur zusätzlich noch nötig, gtkTerm auf das
> "+" als Bestätigung vom Oszilloskop warten zu lassen und schon ging die
> Post ab.

Ich bin nicht im Bilde! Wie geht das? Kannst Du mal eine detailierte 
Beschreibung geben, oder sagen wo es eine gibt? Das hört sich ja so an 
als wenn man die Entwicklungszyklen dramatisch verkürzen könnte.

Mach mich schlau!

Hayo

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen schrieb:
> @Guido,
> es werden noch einige Pixel nicht richtig gesetzt.

Ja hab ich schon gesehen, das ist aber anscheinend eine andere 
Baustelle, die den Gridlayer betrifft, denn die Signale sind soweit ich 
gesehen habe nicht davon betroffen. Ich vermute, das da irgendwo Pixel 
im Löschmodus gesetzt werden in der Gridroutine ("set" Parameter auf 
Null).

> @Hayo,
> Wenn man misst und auf Stop drückt kann man ja in das Signal rein oder
> raus zoomen. Dabei wird aber immer eine neu Messung gestart sodass die
> alten Werte verloren gehen. Allerdings nur beim Autotrigger.
> Normaltrigger und Singe Shot sind OK.

Muß ich mir heute abend mal ansehen.

Gruß Hayo

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

@Hayo

Funktioniert super! 3min pro Zyklus unter Linux. Allerdings verwende ich 
nicht mehr gtkTerm sondern ein eigenes Perl-Skript zum Upload.

Günter hat weiter oben ein neues Makefile gepostet 
(http://www.mikrocontroller.net/attachment/50963/Makefile.zip)

Das erzeugt eine TomCat.ram, die genau wie die ursprüngliche .flash 
aufgebaut ist, nur fehlen darin die Befehle, den Flash zu löschen und in 
den Flash zu schreiben. (So sehe ich das) Deshalb wird der Code direkt 
in den Ram geschrieben und mit dem letzten Befehl gestartet.

Ich habe mein provisorischen Perl-Skript angehängt. Bitte nicht schlagen 
für die Form. Ist nur zum testen, funktioniert aber schon einwandfrei. 
Bei Bedarf gibts auch eine schönere Form. Habe dafür aber jetzt keine 
Zeit

Damit das läuft musst du natürlich noch deine Schnittstelle im 
Perl-Skript auswählen und das Skript in den Build-Ordner legen.

Wenn Perl das Modul nicht findet musst du das hier installieren:
http://search.cpan.org/CPAN/authors/id/C/CO/COOK/Device-SerialPort-1.04.tar.gz

mit (als root)
perl Makefile.pl
make
make Install

Heute Abend habe ich wieder mehr Zeit.

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

@Robert + Michel

Ok Jungs Ihr hattet Recht. Ich hab tatsächlich was am Trigger geändert 
in der 0.60 die ja nicht als beta rausgegangen ist. Das läßt sich 
schnell wieder fixen. Allerding ist das genau die Stelle an der noch 
optimiert werden muß um den Trigger besser zu machen. Ich werde das 
erstmal wieder auf den alten Stand bringen und dann weiter sehen.

Danke!

Hayo

von Stefan (Gast)


Lesenswert?

Kleine Ergänzung:
Das Perl-Skript erkennt eine fehlerhafte Übertraung und bricht dann ab. 
Da das bisher noch nie passiert ist, ist auch keine automatische 
Korrektur nötig. Nach dem letzten Befehl wartet das Skript auf eine 
Rückmeldung kommt natürlich nicht mehr, da der Oskar schon läuft. Also 
einfach abbrechen.

Stefan

von Blue F. (blueflash)


Lesenswert?

Ok danke,

bin schon echt neugierig und kann es kaum erwarten nach hause zu kommen.

Hab mir mal Günters Beitrag vom 16.5. rausgesucht. Der ist irgendwie an 
mir vorbeigegangen, dabei ist das ja eine wirklich interessante Sache. 
Gut dass wir nochmal drüber geredet haben...

Gruß Hayo

von sunny (Gast)


Lesenswert?

hallo stefan

dein script rennt ja durch wie schmitt's katze. super! lässt sich damit 
auch die .flash datei übertragen?

gruß sunny

von Stefan (Gast)


Lesenswert?

@sunny

Keine Ahnung, ob das schon geht. Getestet hab ich es nicht. Kommentare 
erkennt es jedenfalls nicht, die in der .flash drinnenstehen. Da müsste 
man noch anpacken. Viel ändern muss man wahrscheinlich nicht mehr.

Stefan

von sunny (Gast)


Angehängte Dateien:

Lesenswert?

ich hab's mal ein wenig abgeändert so dass man es auch für die .flash 
datei verwenden kann.

von Kurt B. (kurt)


Lesenswert?

@Hayo,
also bei mir habe auch die Signale fehlende Pixel auf beiden Kanälen. 
Siehe Screenshot.

von Stefan (Gast)


Lesenswert?

@sunny

Wie schnell läufts mit der .flash?

Gruß,
Stefan

von Guido (Gast)


Lesenswert?

Hallo,

Kurt Bohnen schrieb:
> @Guido,
> es werden noch einige Pixel nicht richtig gesetzt.

super, ich dachte schon in hätte ein Hardwareproblem. :-)
Sehe ich aber nur mit Lupe. Die vertikalen Gridlinien
sind bei mir auch nicht ganz durchgezogen, da werde ich mal
suchen. Die fehlenden Pixel sind bei mir im letzten Drittel
des Schirms wieder da, wird nicht so leicht zu finden sein.

@ Stefan: hast recht, das Ramloaden ist schon super, vor
allem aus dem gtkTerm heraus.

Gruß, Guido

von Günter J. (gjung)


Lesenswert?

@Stefan
> RS232-Wandler. Bei mir war es nur zusätzlich noch nötig, gtkTerm auf das
> "+" als Bestätigung vom Oszilloskop warten zu lassen und schon ging die
Hatte ich vergessen zu sagen, zusätzlich sollte man noch die CRLF
Anpassung einschalten
> Funktioniert super! 3min pro Zyklus unter Linux. Allerdings verwende ich
> nicht mehr gtkTerm sondern ein eigenes Perl-Skript zum Upload.
gtkterm hat den Vorteil, daß man danach auch gleich im Terminal für
die serielle Schnittstelle ist.

@sunny
> dein script rennt ja durch wie schmitt's katze. super! lässt sich damit
> auch die .flash datei übertragen?
das wird nicht zuverlässig funktionieren, da der GERM nach jeder
empfangenen Zeile ein '+' schickt, unabhängig davon ob der Teil zum
verarbeiten der Zeile fertig ist oder nicht. D.h. wenn der gerade mit
dem Schreiben eines Flash-Blocks beschäftigt ist, wird der Eingangs-FIFO
überschrieben, und dann hängt das ganze.
Ich denke man müsste nach jeweils 64k eine Pause von ein paar Sekunden
einlegen damit das ganze zuverlässig geht.

Ich wollte mich mal drüber machen das 'nr' Kommando aus dem SDK
(ist bei Linux nicht mit dabei) mit genau diesen Funtionen neu zu 
schreiben, leider bin ich im Moment beruflich etwas im Stress so daß
ich nicht allzu viel machen kann.

Gruß,
Günter

von Guido (Gast)


Lesenswert?

Hallo Kurt,

>also bei mir habe auch die Signale fehlende Pixel auf beiden Kanälen.
>Siehe Screenshot.

hast recht, ist bei mir auch so, sieht man nur mit einem
Rechteck. In der linken Hälfte fehlen die Pixel wohl in
jeder 2. Spalte, imd der rechten sehe ich sowas nicht.
Wird wirklich blöd zu suchen sein.

Gruß, Guido

von sunny (Gast)


Lesenswert?

@stefan
genau so schnell wie mit der .ram

@günter
ich hab es 4x durchlaufen lassen und keine probleme festgestellt. ich 
glaub auch das + wird erst gesendt wenn der letzte vorgang abgeshlossen 
ist. das sieht man gut am anfang wenn die speicherblöcke gelöscht 
werden. da dauert es immer einen kurzen moment bist die bestätigung 
kommt.

von Robert S. (razer) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

Ich habe gerade die Experimental Firmware (0.62) mit der umskalierten 
Anzeige geladen.

Auf Kanal habe ich jedoch in den neuen Skalierungen (4V, 2V, 400mV, 
200mV, 40mV, 20mV) extreme Ausreißer (siehe Screenshot). Wenn ich auf zB 
500mV umschalte sind sie weg. Nach einer Zeit legen sich diese 
Ausreißer.

von Günter J. (gjung)


Lesenswert?

@sunny
ich hatte genau die gegenteilige Erfahrung,
ist immer nach ca der Hälfte (ca 300k) stehen geblieben.
Bis dahin lief es immer genau so schnell wie ins RAM,
was mich zu der Vermutung bringt, das eben nicht bis zum
Ende des Schreibvorgangs gewartet wird bevor das '+' kommt.

Gruß,
Günter

von Blue F. (blueflash)


Lesenswert?

Welches GTKTerm benutzt Ihr?

Das französische oder das deutsche? Von der Beschreibung her würde ich 
ja auf das französische tippen in der Version 0.99.5, ist das korrekt?

Hayo

von sunny (Gast)


Lesenswert?

dann ist das vll. systemabhängig. ich missbrauche meinen satreciver für 
die linux geschichten. das ist ja ein relativ langsames system. 
möglicherweise bleibt dadurch genügend zeit für den schreibvorgang.
also sollte man vll. doch eine verzögerung einbauen. da ich bis gerade 
ebend noch nie was mit perl gemacht habe, wüsste ich allerdings nicht 
wie.

von Günter J. (gjung)


Lesenswert?

das letzte Mal das ich was in Perl gemacht habe ist leider 10 Jahre her.
Aber sowas wie ein 'usleep' gibt es sicher auch in Perl.
Gerade nachgeschaut, ist im Time::HiRes Modul: usleep ($microseconds);

Gruß,
Günter

von sunny (Gast)


Angehängte Dateien:

Lesenswert?

ich hab das mit den waitstates mal versucht. es werden jetzt 2000 zeilen 
am stück übertragen und dann 1 sek gewartet.

von Günter J. (gjung)


Lesenswert?

werd ich heute abend mal ausprobieren.

von Blue F. (blueflash)


Lesenswert?

Sagt mal einer was zu der verwendeten Version von GTKTerm? Es scheint da 
zwei unterschiedliche Programme mit dem gleichen Namen zu geben.

Hayo

von Günter J. (gjung)


Lesenswert?

so wie es aussieht gibt es wirklich zwei:
  GTKTerm -> sowas wie xterm
  gtkterm -> serielles Terminal
die unterscheiden sich nur in der Gros-/Kleinschreibung,
das war mir so auch nicht klar.

Gruß,
Günter

von Guido (Gast)


Lesenswert?

Hallo Hayo,

die Version 0.99.5 funktioniert bei mir prima. Ob die englisch
oder französisch ist weiß ich nicht.

Guido

von Günter J. (gjung)


Lesenswert?

wobei GTKTerm seit 2004 nicht mehr gepflegt wird.

von Guido (Gast)


Lesenswert?

So,

habe jetzt dreimal hintereinander eine .flash Datei mit
GtkTerm übertragen. Hat dreimal geklappt, die 0.62
dauert etwa 3,5 Minuten, ältere Versionen gehen etwas
schneller.

Möglicherweise bremst das Terminalprogramm ausreichend
(mal weitere Tests anwarten). Ich hatte beim
WelecUpdater unter Linux den Eindruck, dass er etwa 3 bis
4 mal länger braucht als unter Windows (beim Download)
und dass die Gtk-Ausgabe hierfür veranzwortlich war.

Guido

von Stefan (Gast)


Lesenswert?

Also bei mir geht es mit gtkterm nicht zuverlässig. Da überträgt er zwar 
und startet. Danach hängt sich die Software aber so gut wie immer auf. 
Deshalb das extra Skript, dass überprüft ob die Zeile wieder richtig 
zurück kommt.

Stefan

von Günter J. (gjung)


Lesenswert?

Es liegt dann offensichtlich an der Geschwindigkeit des jeweiligen 
Rechners.
D.h. zuverlässig wird es nur mit zusätzlichen Wartezeiten wie im perl 
Skript gehen.

von Guido (Gast)


Lesenswert?

Hallo Stefan,

sorry ich habe vergessen zu erwähnen, dass ich eine normale
ser. Schnittstelle verwende. Vllt. macht das den Unterschied.

Gruß, Guido

von Günter J. (gjung)


Lesenswert?

also normale RS232 oder USB-Adapter mach keinen Unterschied.
Hab' ich beides schon probiert.
Der unterschied zwischen einem einfachen USB-Adapter und einer
echten RS232 liegt hauptsächlich in der Ansteuerbarkeit der
Handshake-Leitungen.
Der GERMS benutzt aber keinerlei Handshake, weder Hardware RTS/CTS
noch Software XON/XOFF.

Gruß,
Günter

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

So,
nochmal für alle, die mit gtkterm Probleme haben, oder die lieber per 
Skript den Code laden wollen, eine verbesserte Version.

Alle 2000 Zeilen wird 1 Sekunde gewartet.

Gestartet wird über eine Kommandozeile mit den Parametern (die natürlich 
an die eigenen Bedürfnisse angepasst werden müssen.)

perl flashloader.pl /dev/ttyUSB0 TomCat.ram

von Blue F. (blueflash)


Lesenswert?

Also gtkterm krieg ich überhaupt nicht zum Laufen. Bei .configure meldet 
er etwas von missing TERMINAL_WIDGET.

Dann hab ich das mal mit Deinem ersten Script ausprobiert - wollte auch 
nicht so richtig. Nach etwas rumgezackere hab ich dann dieses paket 
installiert gekriegt mit irgendwelche Zusatzroutinen. Dann hab ich mal 
Dein letztes Script ausprobiert - mit /dev/ttyS0 (hab einen echten RS232 
Port) - und es läuft und zwar blitzschnell. Super, muß mir nur noch was 
überlegen damit ich nicht immer die ganze Kommandozeile eingeben muß.

Hast Du echt prima hingekriegt, und das man ins RAM laden kann ist auch 
echt klasse, danke nochmal an dieser Stelle an Günter.

Muß erstmal wieder los, bis nachher

Gruß Hayo

von Günter J. (gjung)


Lesenswert?

Hi,

also ich hab' das jetzt mal auch mit dem Laptop getestet.
Ich eindeutig ein Geschwindigkeits Thema.
Auf dem Laptop geht der Flashupdate sowohl mit echter RS232 als auch
mit USB-Adapter problemlos mit gtkterm, auf dem Arbeitsplatzrechner geht
nur das Perl-Skript zuverlässig.
Beim Laden ins RAM gibts kein Problem mit der Geschwindigkeit.

Gruß,
Günter

von Günter J. (gjung)


Lesenswert?

@Hayo,

Du hast doch OpenSuse?
Dann versuch doch mal
   http://rpm.pbone.net/index.php3/stat/4/idpl/11318475/com/gtkterm-0.99.5-7.1.i586.rpm.html
zu installieren, eventuell musst Du noch ein paar gtk libs 
nachinstallieren.

Gruß,
Günter

von Blue F. (blueflash)


Lesenswert?

@Günter

muß ich morgen mal machen, heute komme ich nur noch dazu die 0.63 zu 
pflegen, damit der Trigger wieder läuft etc..

Gruß Hayo

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

So,

ich hab gerade mal fix die flashloader.pl etwas aufgeräumt und mit einer 
Timeout-Behandlung versehen, weil das Ding sonst bis zum 
St.Nimmerleinstag wartet, wenn das DSO nicht reagiert.

/Hannes

EDIT: muss übrigens dem Autor des Scripts meinen tief empfundenen Dank 
aussprechen, das macht das Testen^WRumspielen wirklich viel einfacher. 
Hab grade nur mal so zum Spaß das Backup der Original-FW wieder 
eingespielt, welches zum Sichern damals ca. 4,5h benötigt hat. Dauer des 
Restore: ca. 7 Minuten. Ich LIEBE es. :D

von branadic (Gast)


Lesenswert?

Hallo Johannes,

könntest du vielleicht so gut sein und auf Sourceforge im Trac/Wiki 
einen entsprechenden Beitrag zum exakten Vorgehen unter Windows/Linux 
setzen, damit auch unsere internationalen Freunde etwas davon haben?
Wäre wirklich super und für die nächste Entwicklungszeit in einer 
Übersicht festgehalten.

Besten Dank, branadic

von Blue F. (blueflash)


Lesenswert?

Mal eine Frage als Perl-Unwissender. Kann man das Perlscript auch unter 
Windows verwenden? Denn für Windows gibt es Perl doch auch. Muß man 
evtl. noch was installieren?

Ich wollte das Script und eine Anleitung der nächsten Beta beilegen, 
genauso wie der TomCat.ram für Leute die streßfrei einfach nur mal 
testen wollen. Dafür wäre es natürlich nicht schlecht wenn man auch 
Windows-User mit einbeziehen könnte.

Gruß Hayo

von Johannes S. (demofreak)


Lesenswert?

Klar, wenn du mir nochmal den Link gibst.

Mir wäre es zugegebenermassen allerdings lieber, wenn ich das Perlscript 
mal versuchshalber für Windows und Linux tauglich mache (bisher geht es 
nur unter Linux), das alles hierher schreibe und du das dann in SF 
einstellst. Dort müsste ich mich erst anmelden... und überhaupt. :D

/Hannes

von Blue F. (blueflash)


Lesenswert?

@Kurt + Guido

Die Pixelfehler kann man besonders gut sehen wenn man einen Kanal auf 
Ground-Coupling schaltet und mit der Nullinie langsam durch den 
kritischen Bereich fährt. Das sieht schon recht merkwürdig aus...

Hayo

von Stefan E. (stefan_e)


Lesenswert?

Hallo Hannes,

so aufgeräumt sieht das Skript gleich nochmal besser aus ;-)

Da merkt man doch gleich, wenn jemand schon öfter Perl verwendet hat.

Hallo Hayo,
ich habe testweise mal die Assembler-Routine umgebaut und der Fehler 
beim Invertieren ist weg. Probiere da noch ein wenig dran rum, um das im 
Ganzen halbwegs zu verstehen.

Gruß,
Stefan

von Guido (Gast)


Lesenswert?

@ Hayo: Die Pixelfehler sind schon weg. Ich probiere gerade noch
den hässlichen Streifen zu entfernen. Gleich mehr.

Gruß, Guido

von Guido (Gast)


Lesenswert?

@ Stefan: Das klingt ja super!

@ All: Mir ist beim Debuggen aufgefallen, dass momentan nach fast
jeder Einstellungsänderung das Config-Flash überschrieben wird.
Muss man sich da Sorgen machen? Ich habe für meine Tests den
Funktionsaufruf in Tomcat auskommentiert.

Gruß, Guido

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.