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
@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
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
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
@ 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
@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
@ 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
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
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
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
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
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
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
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
@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
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
@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
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
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
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
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
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
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
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
> 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
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
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
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?
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
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.
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
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
@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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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?
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
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
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
@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
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
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
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.
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
... 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
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
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
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
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
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!
@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
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
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
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
@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
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
@ 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
@ 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.
@ 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.
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
>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
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
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
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
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
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
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)
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
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
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
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
@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
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
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
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
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
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
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
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
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
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
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
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
@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
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.
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
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
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
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
@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
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
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
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
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
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
"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
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
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
@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
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
@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
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
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.
@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
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
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
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
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
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
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
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
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
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)
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
@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.
@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.
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
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
@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
@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
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
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
@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
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
@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
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
@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.
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.
@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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
@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
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
@ 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
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang