Announcement: there is an English version of this forum on 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
Ist schon ok, ich klemm mich mal wieder raus und schau mal, ob ich eine UserCalib vom Agilent aufzeichnen kann. Gruß, Ulrich
@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
Hab ich mal gecheckt, Stop_Record() scheidet aus. 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
Jo ich habs!!!!!!!!!!!! Details erzähl ich später. Muß jetzt los. Hayo
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
Hallo sunny, danke, damit werde ich mal spielen. Gruß, Guido
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
Ok, danke für die Info, ich schau es mir mal an. Gruß Hayo
@Michel Konnte ich nicht nachvollziehen. Kriegst Du das nochmal hin? Wenn ja dann die genauen Einstellungen posten (evtl. Bild). Gruß Hayo
Angehängte Dateien:
-
noProbeson1_Pulse.jpg
86 KB
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
Ich meine den ganzen Bildschirm. Aber wenn während der Anzeige noch weiter initialisiert wird, macht es keinen Sinn.
@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
Angehängte Dateien:
-
branadic1.JPG
400 KB
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
Angehängte Dateien:
-
AC_DC.jpg
200 KB
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
Ich kann übrigens gerne mal eine umskalierte Fassung raushauen, wenn Ihr mal sehen wollt wie das aussieht. Müßt Ihr nur sagen... 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
P.S.: @ Hayo: Kannst du den verdammten Testgenerator in der Betaphase nicht einfach disablen? Es gäbe dann weniger Messfehler ;-). Guido
Ja, das Testsignal ist AC! 800mVSS. Bei mir ohne Offset.
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
Angehängte Dateien:
-
Original.jpg
140 KB
Kleiner Vergleich für alle! Hier die originale Skalierung...
Angehängte Dateien:
-
Umskaliert.jpg
150 KB
...und im Vergleich die umskalierte Fassung. Alles mit dem gleichen Signal. Hayo
Angehängte Dateien:
-
original_100mV.jpg
200 KB
...und hier zum direkten Vergleich der originale 100mV Bereich der ja der umskalierte 200mV Bereich ist 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
Wie steht es eigentlich um die QuickMeasure Funktionen? Währe schön, wenn die wieder funktionieren würden.
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
Gibt es die offizielle FW1.4 eigentlich als Download auf Wittigs Homepage? ansonsten stelle ich sie gerne als Flashdump zur Verfügung. Hayo
@Guido Wenn ich mir das so überlege wäre es natürlich noch sinnvoller die Stellen auszukommentiern an denen ClearPlanes() aufgerufen wird. Hayo
@ Hayo: Das ist aber eigentlich nur im UserInterface. Guido
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 Hayo, ein Backup der FW1.4 vom 2024A gab es hier: Beitrag "Re: Wittig(welec) Oszilloskop firmware problem" Gruß Jürgen
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
Achso, falls es sich jemand anschauen möchte. Guido
Hallo Guido, welche FW-Version hast du verwendet? Die letzte Beta von Hayo? Gruß, branadic
Hallo branadic,
>welche FW-Version hast du verwendet? Die letzte Beta von Hayo?
jepp, wie immer (also die 0.62).
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
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 :)
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
Ach ja: Testsignal war der interne Rechteck 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
Angehängte Dateien:
-
pixel.jpg
98 KB
@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
hallo stefan dein script rennt ja durch wie schmitt's katze. super! lässt sich damit auch die .flash datei übertragen? gruß sunny
@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
ich hab's mal ein wenig abgeändert so dass man es auch für die .flash datei verwenden kann.
@Hayo, also bei mir habe auch die Signale fehlende Pixel auf beiden Kanälen. Siehe Screenshot.
@sunny Wie schnell läufts mit der .flash? Gruß, 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.
Angehängte Dateien:
-
SNC00080.jpg
93 KB
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
ich hab das mit den waitstates mal versucht. es werden jetzt 2000 zeilen am stück übertragen und dann 1 sek gewartet.
Sagt mal einer was zu der verwendeten Version von GTKTerm? Es scheint da zwei unterschiedliche Programme mit dem gleichen Namen zu geben. Hayo
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
Hallo Hayo, die Version 0.99.5 funktioniert bei mir prima. Ob die englisch oder französisch ist weiß ich nicht. Guido
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.
Hallo Stefan, sorry ich habe vergessen zu erwähnen, dass ich eine normale ser. Schnittstelle verwende. Vllt. macht das den Unterschied. Gruß, Guido
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
@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
@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
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
@ Hayo: Die Pixelfehler sind schon weg. Ich probiere gerade noch den hässlichen Streifen zu entfernen. Gleich mehr. Gruß, Guido
@ 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
Thread beobachten
Seitenaufteilung abschalten