Gast
#2003780
@ Hayo: Klingt aber auch nach italienischer Kundschaft: "Ich mache Ihnen ein Angebot, das Sie nicht ausschlagen können." ;-)
Nee nee, im Knochenbrechergewerbe bin ich nicht tätig... Aber wenn ich ich hier Details über meine Kunden ausplaudere dann kann ich ich mir einen Job als Hausmeister in Timbuktu suchen. Hayo
Gast
#2010368
Hallo Hayo, I tried the RS232 Updater on Welec Website, but after a few minutes trasfer stopped and appear the message:programmierung fertig.Gesamtdauer 0.00.30. and dso hangs. No more boot also with former 1.4 Let me know how to proceed BR Alex
Hi Alex, have you tried this? http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload#UploadwithWelecUpdaterviaRS232
Gast
#2010504
Hallo Kurt, I done Exactly what is described there.Hang after 30 seconds Now any update is accepted anymore.
Hayo W. schrieb: >kann ich mir einen Job als Hausmeister in Timbuktu suchen. hat einen riesigen Vorteil, das Wetter ist wesentlich besser ;)
Charly B. schrieb: > Hayo W. schrieb: >>kann ich mir einen Job als Hausmeister in Timbuktu suchen. > > hat einen riesigen Vorteil, das Wetter ist wesentlich besser ;) ...und wenn die die da auch noch eine 16K-Leitung haben kann ich ja von da weiterprogrammieren...
Hallo Hayo, in dem Zusammenhang wollte ich nochmal wegen den Funktionen zur Ansteuerung der Huckepack Platine nachfragen. Mittlerweile sollten doch alle nötigen Infos vorhanden sein? Mfg, Kurt
Alex schrieb: > Hallo Kurt, > I done Exactly what is described there.Hang after 30 seconds > Now any update is accepted anymore. Hi Alex, don't worry, update over RS232 is possible at every time, because the GERMS-Loader Routines are not part of the firmware. They are stored in a separate memory area. So lets analyze what went wrong and how we can solve this. Did You use the .flash file or did You rename the .ram file? Are You using an USB to RS232 converter or do You have a legacy RS232 Port in Your PC? Which OS do You use (WinXP, Windows Vista, Windows 7, Linux) In which version (32 Bit/64 Bit) The converters may cause problems in some cases, but mostly they work without problems. Did You use the original RS232 Kable which was delivered with the DSO? Checking the RS232 connection can be done with a terminal program (like teraterm). Did You start the GERMS-Monitor correctly? The screen makes a short white flash when switchíng to the monitor mode. If this doesn't work at all, try to use another PC (from a friend or on the work etc.) Hayo
@Kurt Mein letzter Stand war, dass Stefan da Probleme mit der Anzahl geeigneter IO-Leitungen ausgemacht hatte. Hayo
Gast
#2011585
Hallo Hayo, I used flash file directly,I use a real RS232 interface and changed already the PC. OS is XP 32bit (tried also ME), I used the original cable ,but changing the cable is the same. RS232 link to PC before upgrade attempt was good, I trasfered some picture and settings in both directions. Germs monitor start correctly but stops after 30 seconds with RS232 welec updater. I know Perl should overwite the firmware, now I can't install the serial file on perl , but may be we can understand why. Alex
Alex schrieb: > Hallo Hayo, > OS is XP 32bit (tried also ME), I used the original cable ,but changing > the cable is the same. XP 32bit is good - do You have Admin rights? > RS232 link to PC before upgrade attempt was good, I trasfered some > picture and settings in both directions. How did You do this with the original firmware??? It doesn't support the RS232 Interface! Germs monitor start correctly > but stops after 30 seconds with RS232 welec updater. Can You copy the screen of the WELEC-Updater after trying the update and post it here? May be this helps us understanding. > I know Perl should overwite the firmware, now I can't install the serial > file on perl , but may > be we can understand why. The WELEC-Updater should overwrite it also. Be shure You startet the GERMS-Monitor correctly. If You push the second key first and then the first key on the left it is only a reset. You must push the left button first and then the second button. Don't connect the USB cable at the same time as the RS232 cable. The RS232 cable should be the only connection to the PC. Did You try to upload the original firmware with the WELEC-Updater? Are You using the latest Version 0.4.8A22? To check the function I made an Upload with the 2.7 Tomcat.flash. It worked fine. Upload duration was 13 minutes (see screenshot) Also I renamed the .ram file to .flash and tried it once more. It also worked without problems. Hayo
Angehängte Dateien:
-
WELEC-Updater.jpg
(93 KB)
Gast
#2011985
Late holidays greetings to all! Regards, Luc
Gast
#2011993
Hallo Hayo, good news,we solved the problem. The cause was conflict in the bios setting of the RS232. Changing this,I tested the download 1.4 with Welec updater and was successful,then I uploaded last FW version. What stops download,and upload of course,is also:a slower PC,must be at least 1GHz CPU and screen/power savers. Your firmware is a great improvement for this DSO. If you like,I can report you some small modification:in FFT mode Hanning window is missing and for its good freq response would be nice to have.Shape and trigger upper than 50 MHz for sine wave are like 1.4 .Next days I'll go deeper,it's amazing. I would like to partecipate to this improvement project as RF technician(up to 8 GHz and more). Thank you, also to all for the info in this forum.I like the way this new year started. Ciao Alex
Alex, maybe you are interested on this project, too? 200MHz DDS-Generator Beitrag "Projekt: 200MHz DDS-Generator"
Ok Alex, good to hear that Your problems are solved - welcome to the family! :-) Help, good ideas and testing are always welcome too. Hayo
Gast
#2016598
Ciao a tutti, pare ci siano problemi con i tempi della ustb, il valore in secondi impostato non sembra corrispondere alla realtà, è molto più veloce di quello che dovrebbe essere, qualcuno può confermare? Visto che ci sono, mi sapete dire quante letture ci stanno in una schermata? Caspita peccato proprio ora che mi serviva!! :) Hello everyone, it seems there are problems with the timing of ustb, set the value in seconds does not seem to correspond to reality, is much faster than it should be, can anyone confirm? Since there are, you tell me how many there are readings on one screen? Wow sin right now I needed! :) Gyppe.
Gast
#2016619
Scusate mi sono accorto ora come funziona, il massimo è 1Sa/4s la schermata quindi registra 200s. E' poco mi sembra, prima i tempi andavano da 1 a 200 secondi o mi sto confondendo? Sarebbe possibile allungare i tempi magari a 1Sa/minuto o anche 1Sa/2 minuti così da registrare almeno 1-2 ore? Sarebbe utilissimo in tante misure. Sorry, I realized now how it works, the maximum is the screen then logs 1Sa/4s 200s. It 'just seems to me the first time ranged from 1 to 200 seconds or am I confused? It would be possible to lengthen the time or maybe even 1Sa/minuto 1NT / 2 minutes in order to register at least 1-2 hours? It would be very useful in many cases. Gyppe.
@hayo ist es eigetlich absicht das im singel modus die TB nur um 3 werte aendern laesst und die V/Div gar nicht ? :( waehre es moeglich die sperre aufzuhaeben ?, auch waehre nett wenn die verschiebung der Achse in Y Richtung funktionieren wuerde (Drehgeber direkt ueber den BNC buchsen) vlG Charly
Charly B. schrieb: > @hayo > > ist es eigetlich absicht das im singel modus die TB nur um 3 werte > aendern laesst und die V/Div gar nicht ? :( Jain, es ist durch die Sache an sich vorgegeben. > waehre es moeglich die sperre aufzuhaeben ?, Nein, das Prinzip ist ja, daß im Single/Stop Mode die Daten des bereits gemachten Samples ausgewertet werden. D.h. hier kann man nur aus dem vorhandenen schöpfen. Die Anzahl der Zeitstufen ergibt sich dabei aus der Abtastrate und der Speichertiefe. Die Spannung kann man natürlich nicht verstellen, da der Drehregler ja auf die Eingangstufe wirkt und natürlich keine neuen Werte kommen, sondern nur die Alten weiterhin aus dem Speicher gelesen werden. > auch waehre nett > wenn die verschiebung der Achse in Y Richtung funktionieren > wuerde (Drehgeber direkt ueber den BNC buchsen) Geht leider nicht, bzw. nur unter erheblichem Aufwand da die Nullinienverschiebung mit den DACs der Eingangsstufe gekoppelt ist und daher das gleiche Problem besteht wie bei der Verstellung der Spannungsbereiche. Hoffe das war einigermaßen verständlich Gruß Hayo
@Gyppe Did I understand correct, Your timing in the USTB is not korrekt (1s - 200s/Div)? I adjusted it with a precision function generator, but after that I optimized some parts in the firmware to make it faster. This could take effect to the USTB-timing but I didn't check this in the last time. Also the number of active channels may have influence to the timing. So let me know if there is any problem. Regards Hayo
Gast
#2017617
No è a posto, 1Sa/4s, 40 minuti l'intera schermata. Le volte precedenti se non sbaglio i tempi erano molto più lunghi no? E' possibile allungarli un po in futuro? Magari 2 ore tutto lo schermo, sarebbe perfetto per vedere le curve di scarica di accumulatori o cose simili. No, it's okay, 1Sa/4s, 40 minutes the whole screen. The previous times, if I remember the times were much longer right? you can stretch it a bit in the future? Maybe 2 hours the entire screen would be perfect to see the discharge curves of batteries. Grazie, Gyppe.
gyppe schrieb: > The previous times, if I remember the times were much longer right? No, I didn't change the sample rates. But before I build the USTB functions there wasn't any functionality in the slow ranges (as in the orig. 1.4 firmware). The real sample rate was 50ns/div in all ranges from 2s - 200s/div. So the ranges where useful for nothing. Most users didn't know that because they never used the slow time bases. > you can stretch it a bit in the future? Maybe 2 hours the entire screen > would be perfect to see the discharge curves of batteries. I have to check how long the maximum interval of the timer which is used can be. regards Hayo
Gast
#2017702
Tutto chiaro grazie :) I see, thanks:) >Most users didn't know that because they never used the slow time bases. I wonder too! It 's a very useful function in a DSO! >I have to check how long the maximum interval of the timer which is used can be. Wow thanks:) Hopefully! Gyppe.
@Hayo waehre es denn zumindest moeglich im 'ungetriggerten' mode die sperren von TB & V/Div aufzuheben, ist ziemlich laestig immer in den RUN mode zu wechseln (oder i bin zu verwoehnt vom Agilent & Tektronix), das waehre eine Super Aenderung :) vlG & ein schoenes WE Charly
Charly B. schrieb: > @Hayo > > waehre es denn zumindest moeglich im 'ungetriggerten' mode > die sperren von TB & V/Div aufzuheben, Das habe ich jetzt nicht so ganz verstanden. Was ist denn der ungetriggerte Mode? Gruß Hayo
wenn i das Oszi mit druecken der Single Taste 'scharf' schalte ist es ja noch 'ungetriggert', wenn es dann getriggert hat leuchtet ja Run/Stop und das ergebniss ist auf dem Schirm zu sehen, das ist dann 'getriggert' ich kenns halt so mit den 'fachausdruecken' :) (i hoff i hab dich nicht verwirrt ;) ) vlG Charly
Gast
#2019554
Hallo Hayo und alle, was Charly B. angesprochen hat, das nachträgliche Ändern der Einstellungen, ist das, was mir als allererstes negativ auffiel. Das muss sich ändern. ;-) Wer einmal mit einem LeCroy gearbeitet hat, will nicht mehr darauf verzichten, weil es dort vorbildlich gelöst ist. Hayo, hast Du Dir das ddsScope.exe schonmal angeschaut? Genau so stelle ich mir das vor. Nachträglich zoomen und verschieben in allen Variationen. Außerdem habe ich noch nicht herausgefunden, ob und wenn ja, wie Du das Force Trigger gelöst hast. Ich stelle mir das so vor: Wenn im Norm- oder Single-Mode kein Trigger kommt, will ich trotzdem manuell einen Trigger auslösen können, indem ich auf die Single-Taste drücke. Die jetzige Funktion, dass bei Drücken der Single-Taste er von Norm- in den Single-Mode wechselt, würde ich entfernen, da das über die Stop-Taste geht. Im Stop-Mode muss sich die Zeitbasis ändern lassen. Im Auto-Mode muss eine Zeit (maxWait, default 2 Divisions) einstellbar sein, nach der der Strahl automatisch startet. Im Norm- und Auto-Mode muss eine Zeit (holdoff, default=0) einstellbar sein, innerhalb der kein Trigger stattfinden kann. Die Triggered-Led sollte kürzer leuchten, bzw. es sollte auch einstellbar sein, dass sie leuchtet, sobald ein gültiger Triggersignal anliegt, unabhängig davon, ob er zum Auslösen eines Triggers führt (also auch im Stop-Mode). Die Ready-Led sollte so schaltbar sein, dass sie im Stop-Mode aus ist. Trigger soll also ein AND aus Ready-LED und Trigger-LED sein.
und durch druecken auf Edge koennte sich die Flanke umschalten ohne nochmal 'F1' (unterm displ.) zu druecken :) das Oszi ist um KLASSEN besser als das original dank Hayo (und mittester) und deswegen spenden wir dir immer neue Ideen damits noch besser wird :) vlG Charly
Oha, zumindest muß ich keine Angst haben, dass ich mich langweile sobald ich wieder mehr Zeit habe... Gruß Hayo
Gast
#2022415
Ich entschuldige mich für den fordernden Ton meines letzten Posts, ist normal nicht mein Stil, sondern aus einem "Wunschzettel" entstanden. Ich hoffe, den einen oder anderen Teil selbst dazu beitragen zu können. Auch glaube ich, durch diese Ideen wird das Programm wesentlich einfacher und schneller, und die Funktionalität noch besser. Darf ich auf meinen Abzweigung des HW-Threads hinweisen, der sich auf die Bedienelemente (Tasten, Drehgeber, Display, Stecker) beschränkt: Beitrag "Welec W20xx Bedienelemente modifizieren: Drehgeber Encoder LED BNC-Buchsen" kollegiale Grüße
Gast
#2022537
hallo Zusammen, es war keine leichte Entscheidung für mich, aber jetzt steht es fest – ich werde mein W2024 zum Verkauf anbieten. Das Gerät ist momentan in dem Zustand wie hier beschrieben: http://welecw2000a.sourceforge.net/docs/Hardware/PCB_messung_1.pdf Ich hoffe daß jemand an dem erreichten Entwicklungsstand der Huckepack-Platine anknüpfen und weitermachen möchte (und dazu noch das Gerät braucht). Weitere 4 teilbestückte (LMH6518) Huckepack-PCBs gebe ich mit. Ich fände es schade alles wegzuschmeißen, das Gerät in dem Originalzustand zurückzubauen und so zu verkaufen, also wenn jemand interessiert ist – bitte mailen. Für Rückfragen und Diskussionen werde ich nach wie vor zur Verfügung stehen. Gruß Walter
Gast
#2027597
hallo Zusammen, schon erledigt - der Oszi ist weg, jemand anders übernimmt... Gruß Walter
Gast
#2027798
Hallo Walter, ich finde es sehr schade, dass du abgesprungen bist! Hoffentlich wird eure Platine doch noch eingesetzt, wäre ja ein Jammer wenn die Entwicklung umsonst gewesen wäre (und ich meine vier Platinen wegwerfen müsste). Gruß Michael
Hallo liebe Leute, nach meiner Winterpause geht es jetzt wieder weiter! Als Einstieg hier einige Änderungen die Ihr in der Zwischenzeit als Wunsch geäußert hattet. Was ist neu? - Ausgabe der Zahlenwerte überarbeitet. Teilweise wurde durch Rundungsfehler ein xx.999 Wert ausgegeben, das ist jetzt korrigiert - Holdoff. Das Thema der letzten Wochen des Jahres 2010. Ich habe den Wertebereich auf 150ms beschränkt, da einer von Euch gemessen hatte dass ab 134ms aufwärts keine Veränderung mehr festzustellen ist. Ich habe die ganze Zähllogik komplett überarbeitet. Die kleinste Schrittweite ist jetzt 8ns. Kleinere Schritte kann die Hardware nicht abbilden. Ab 1ms ist die Schrittweite 1µs. Es gibt jetzt 3 Nachkommastellen. Durch mehrfaches Drücken der Holdofftaste kann in 10er Schritten weitergeschaltet werden. - USTB -> es gibt wie von gyppe vorgeschlagen zwei neue Zeitbasen 500s/div und 1000s/div die sich besonders dafür eignen Lade und Entladekurven von Akkus aufzuzeichnen. ---------------------------------------------------------------------- What is new? - Numeric output improved. Rounding Errors like xx.999 are corrected now. - Holdoff. Range is limited to 150ms now. Maximum Value which is working correctly is 134ms. New count logic. Smallest step width is 8ns. Smaller steps are limited by the hardware. The 1ms range has the step width 1 µs. Display has 3 digits after the dot know. Pushing the Holdoff button multiple switches the value in 10th steps. - USTB -> Like suggested by gyppe there are two new timebases 500s/div and 1000s/div which are made for accumulator loading characteristics. Gruß Hayo
Jörg H. schrieb: > eProfi schrieb: >> Z.b. in der Display::PIXELP (wenn ich das richtig sehe, wird der gesamte >> Bildschirmaufbau darüber gemacht und dementsprechend oft aufgerufen) und >> allen diese Funktion aufrufenden Routinen: >> planeadr wird etliche Male durchgereicht, das braucht jedes Mal Zeit. >> Ist es möglich, das über eine globale Variable zu lösen? >> >> Außerdem wird set verwendet. Ich fände es besser, auf 2 Routinen >> umzuschreiben, einen PIXELC (clear) und eine PIXELS (set) >> Vorteil: set entfällt und muss nicht geladen, gestackt und ausgewertet >> werden. > > Das habe ich schon so gemacht und vor vielleicht einem Jahr bei > Sourceforge eingecheckt. Zusammen mit diversen anderen Optimierungen im > Bereich der Zeichenfunktionen. > > Jörg Ich habe das mal geprüft indem ich die pixelp() als inline definiert habe. Dann fällt das Stacken auch weg - nur der Code wird etwas größer. Meine Performancemessungen haben keine Änderungen in der Geschwindigkeit ergeben!! Die Framerate ist exakt die gleiche vorher und nachher. Ich habe daher alles so gelassen wie es vorher war. War aber einen Versuch wert. Gruß Hayo
Gast
#2038824
Hayo Tanks:) > - USTB -> Suggested by gyppe Like there are two new> timebases 500s/div > Which 1000s/div and are made for loading accumulator> characteristics. Very good! The'm already trying to get the discharge curve of a rechargeable battery, 3 hours are just fine, thanks:)
Gast
#2038913
Hallo Hayo, wie schaut es eigentlich mit der Unterstützung für den 16bit DAC (LTC2602) aus? Im Zusammenspiel mit der Huckepackplatine wäre es schön, wenn dieser mit unterstützt würde, da sich ja kleinere Spannungsbasen ergeben. Gruß, branadic
Hi branadic, Du mußt mich erstmal thematisch ins Boot holen, da ich die Hardware Details zum Teil nicht so aufmerksam verfolgt habe. Der 16 Bit DAC hat doch nichts direkt mit der Platine zu tun, sondern ist optional, oder? Wenn ich Walters Ausführungen richtig in Erinnerung habe ist der LTC2602 Softwarekompatibel zu dem alten DAC (14 Bit), das heißt er sollte nach dem Austausch ohne Änderungen an der FW (bedingt) funktionieren, nur dass er nicht den vollen Bereich der 16 Bit ausschöpft - auch richtig? Man müßte also nur den numerischen Ansteuerbereich auf die 16 Bit erweitern, oder müssen auch die Skalierungsfaktoren geändert werden? -> heißt konkret: ist die Fullscale-Ausgangsspannung identisch? (ich vermute mal ja) Das hieße umgesetzt, dass statt wie jetzt die Endwerte bei +/-8192 (16384 Stufen) dann bei +/- 32768 (65536) liegen - korrekt? Gruß Hayo
Und hier geht es schon wieder weiter mit dem nächsten Release. Angeregt durch die Hinweise von eProfi habe ich die Triggerlogik geändert. Es werden jetzt auch Triggerevents im Stop-Modus angezeigt (rote LED bzw. Kanal 4 LED), auch wenn kein Signal eingelesen wird. Im Stop-Modus ist die Triggerbereitschafts LED (grün) aus. Es gibt im Mode/Coupling Menü einen neuen Button "Manual Trigger". Dieser ist verfübgbar im Single-Mode und bei Triggermodus "Normal". Es kann hiermit ein Triggerereignis manuell ausgelöst werden. So jetzt werde ich mir erstmal für die anstehenden Lötarbeiten eine Lötstation bestellen, man muß ja mittlerweile aufrüsten wenn man diesen filigran-Kram noch bearbeit können will. Und das wo die Augen immer schlechter werden... --------------------------------------------------------------------- Next version is released now... Fixed little stop/single bug, changed logic for trigger event LEDs, added manual trigger in Mode/Coupling menu. Function is described in the document Special Functions.txt Gruß Hayo
Gast
#2039993
Hayo W. schrieb: > Der 16 Bit DAC hat doch nichts direkt mit der Platine zu tun, sondern > ist optional, oder? Vollkommen richtig, zunächst einmal ist der Austausch nicht zwingend notwendig. Er wird jedoch notwendig, wenn man den Vorteil durch die Huckepackplatine nutzen will, auch kleinere Spannungsbasen darzustellen (bis runter zum 1mV/div). > Wenn ich Walters Ausführungen richtig in Erinnerung habe ist der LTC2602 > Softwarekompatibel zu dem alten DAC (14 Bit), das heißt er sollte nach > dem Austausch ohne Änderungen an der FW (bedingt) funktionieren, nur > dass er nicht den vollen Bereich der 16 Bit ausschöpft - auch richtig? Vollkommen richtig. > Man müßte also nur den numerischen Ansteuerbereich auf die 16 Bit > erweitern, oder müssen auch die Skalierungsfaktoren geändert werden? Nein, die Skalierungsfaktoren sind davon unbetroffen. branadic
Wo kriegt man die Teile am Besten her und was kosten die ? Hayo
Gast
#2040036
Hallo Hayo, such es dir aus, Digikey, RS, Farnell... Hätten wir früher drüber gesprochen hätte ich sie dir mitbestellen können, jetzt ist es zu spät, denn meine Bestellung ist bereits raus. Ich hoffe im Laufe der nächsten Woche die Bauteile hier zu haben, dann bekommst du deine Huckepackplatinen zugeschickt. Aber ich bin sicher, dass hier der ein oder andere seine Huckepackplatine ebenfalls langsam mal bestücken will. Vielleicht könnt ihr wirklich mal eine Sammelbestellung anleiern? Das würde die Diskussion um "Digikey ist teuer im Versand" abschwächen, denn ab 65,-€ Bestellwert ist der Versand kostenlos. Wenn sich nur zwei Leute zusammen tun ist der Bestellwert bereits beieinander. Zudem tun sich die Leute leichter mit der Bauteilauswahl. branadic
Hast Du das Teil schon drin? Wenn ich die FW anpasse müssen wir ja irgendwie sehen ob es funktioniert. Hayo
Hab gerade gesehen dass die Dinger 10,- pro Stück kosten. Bei diesen Bauteilpreisen ist der Preis des kompletten W2000A wie es in der letzten Zeit gehandelt wurde ja schon fast ruinös! Da es sich um Dual-Devices handelt brauche ich für das W2022A nur einen - korrekt? Hayo
Gast
#2040131
Drin hab ich sie noch nicht, aber zumindest schon hier liegen. Der Plan war es alles in einem Abwasch auf die Welec-Platine zu pflanzen, sonst muss man mehrfach das Gerät öffnen und da war ich jetzt nicht so der Freund von. branadic
Gast
#2040185
@Hayo: Du kannst auch mal ein Sample ordern: http://www.linear.com/samples/orderSamples.jsp?navId=LTC2602
Martin schrieb: > @Hayo: Du kannst auch mal ein Sample ordern: > http://www.linear.com/samples/orderSamples.jsp?navId=LTC2602 Danke für den Tip! Hab mir einfach mal 2 Samples bestellt. Mal sehen ob da was kommt. Gruß Hayo
@Hayo & all die 2.9 ist meiner Meinung nach 'Buggy' Reproduzierbar so: Ch1 auf die interne 1khz, dann Run/Stop, bild steht prima, jetzt Tastkopf weg von den 1khz, 'Bild' auch weg obwohl Run/Stop rot ist mach grad downgrade uff die 2.8, hoffe es ist dort nicht vlg Charly
@Hayo & all die 2.9 ist meiner Meinung nach 'Buggy' Reproduzierbar so: Ch1 auf die interne 1khz, dann Run/Stop, bild steht prima, jetzt Tastkopf weg von den 1khz, 'Bild' auch weg obwohl Run/Stop rot ist mach grad downgrade uff die 2.8, hoffe es ist dort nicht (Downgrade beendet, da ist der Fehler nitt) ps. warum so kompliziert mit dem manuellen triggern im Single mode ? im Single mode (Single=rot) koennte doch ein erneutes druecken der Single Taste ein Triggern ausloesen, oder ? oder man nimmt die Edge Taste denn mit der geht im moment sowieso in einen 'undefinierten' zustand (Ver. 2.8) vlg Charly
Du hast recht, es ist noch ein Fehler drin, mir ist da eine Klammer um zwei Zeilen verrutscht. Ich arbeit daran. Die korrigierte Version gibts in Kürze. Hayo
Hallo allerseits, wie versprochen hier die korrigierte 2. Compilation. Hab auch noch einige Kleinigkeiten bei der Hintergrund-Triggererkennung verbessert. Gruß Hayo
Gast
#2041445
Hallo Hayo, noch ein paar Anregungen für Implementierungen, einige hatte ich bereits erfragt. Tastkopf-Kalibrier-Menü: Wäre es möglich ein Kalibriermenü einzufügen? Aktive Tastköpfe weisen in der Regel eine Abweichung des DC-Offsets auf. Hier wird diese für den Tastkopf wegkalibriert, ohne Einfluss auf die ADC-Kalibrierung vorzunehmen. Dazu wird der Tastkopf an das Probe-Signal gehängt und der Gleichspannungsanteil korrigiert. Das Menu besteht aus der Auswahl des Kanales, an dem der Tastkopf hängt und aus den beiden Einträgen: "Lösche Tastkopfkalibrierung" und "Kalibriere Tastkopf". Es handelt sich dabei um eine reine vertikale Kalibrierung. Deskew-Menü: In diesem Menu kann man eine Phasenkompensation des Tastkopfes vornehmen, soll heißen der Tastkopf bekommt wieder das Probesignal an seinen Eingang und wird nun in der Zeitachse soweit kalibriert, bis Signaldurchgang und Triggerpunkt übereinstimmen. Das geht sowohl für positive als auch für zeitlich negative Werte. Falls sich soetwass implementieren ließe wäre das für das Oszi eine echte Bereicherung, da sonst nur teure Geräte eine solche Funktion aufweisen. branadic
Gast
#2041519
Eine kleine Anregung noch. Wäre es vielleicht sinnvoll, einen Meüstrukturplan zu erstellen? Das könnte zugleich als Dokumentation zur Firmware dienen. branadic
branadic schrieb: > Tastkopf-Kalibrier-Menü: > Wäre es möglich ein Kalibriermenü einzufügen? Möglich ist es... - allerdings habe ich einen Solchen nicht und könnte daher auch die Funktion nicht testen. Weiterhin müßte sich das doch auch über die normale DAC-Kalibrierroutine bewerkstelligen lassen, oder? > > Deskew-Menü: > In diesem Menu kann man eine Phasenkompensation des Tastkopfes > vornehmen, soll heißen der Tastkopf bekommt wieder das Probesignal an > seinen Eingang und wird nun in der Zeitachse soweit kalibriert, bis > Signaldurchgang und Triggerpunkt übereinstimmen. Dazu müßte es eine Rückkopplung des Probesignals in die Firmware geben (quasi ein Referenztrigger) um das automatisch machen zu können. Auch das sollte sich manuell uber die Delay-Einstellungen im Hardwaremenü machen lassen. > Eine kleine Anregung noch. > Wäre es vielleicht sinnvoll, einen Meüstrukturplan zu erstellen? Das > könnte zugleich als Dokumentation zur Firmware dienen. Eine Vorstufe davon befindet sich in der Programmers Reference. Ein richtiger Strukturplan wäre natürlich nicht übel. @all - Wer fühlt sich berufen diesen zu erstellen? Schon mal als Info: Die Unterstützung des LTC2602 16 Bit DAC ist schon in Arbeit und kommt mit dem nächsten Release. Wer baut Ihn denn schon mal ein damit wir testen können? Gruß Hayo
Hi Hayo, Hayo W. schrieb: > - Holdoff. Das Thema der letzten Wochen des Jahres 2010. Ich habe den > Wertebereich auf 150ms beschränkt, da einer von Euch gemessen hatte dass > ab 134ms aufwärts keine Veränderung mehr festzustellen ist. Danke für die neue Version 2.9.C2. Ich habe mir die Holdoff-Funktion noch einmal kritisch angesehen: Der Einstellbereich muß definitiv noch etwas weiter eingeschränkt werden, da scheinbar ab einem eingestellten Wert von 134.218 ms nicht nur keine Veränderung mehr festzustellen ist, sondern etwas völlig anders abläuft. Gruß Rainer
Ok, kann ich machen. Ich habe die Funktion nur oberflächlich geprüft aber keine genaue Analyse gemacht. Ich hatte die 150ms gewählt damit man noch einen gewissen Spielraum für Streuungen hat. Möglich ist natürlich, dass man mit größeren Werten quasi einen Buffer Overflow verursacht und dann andere Harwarekomponenten falsch angesteuert werden. Gruß Hayo
Gast
#2041870
Hayo W. schrieb: > Möglich ist es... - allerdings habe ich einen Solchen nicht und könnte > daher auch die Funktion nicht testen. Ich meld mich bei dir deswegen. > Weiterhin müßte sich das doch auch über die normale DAC-Kalibrierroutine > bewerkstelligen lassen, oder? Ja klar lässt sich das damit machen, allerdings ist diese Lösung dirty. Schöner wäre dafür ein eigenes Menü, weil ich dann am Kanal einfach den Tastkopf wechseln kann, ohne gleich einen komplett neuen DAC-Abgleich des gesamten Gerätes durchführen zu müssen. Stattdessen hätte ich einen zusätzlichen Abgleich für einen ausgewählten Kanal. Hayo W. schrieb: > Die Unterstützung des LTC2602 16 Bit DAC ist schon in Arbeit und kommt > mit dem nächsten Release. Wer baut Ihn denn schon mal ein damit wir > testen können? Werd ich die Tage mal angehen. branadic
Ok - Limiter auf 134ms ist eingebaut! Gruß Hayo
Hayo, bei der "Manuel Trigger"-Funktion fände ich es logischer, wenn die Taste immer gehen würde. Im Moment schein sie nicht durchzukommen, wenn Run/Stop "rot" und Single "grün" ist. Oder ist das ein größerer Aufstand? Gruß Rainer
Zur Logik die dahinter steckt: - Stop ist halt Stop. D.h. da geht nix, alles ist angehalten. - die manuelle Triggerung macht nur in einem Triggermodus Sinn, nämlich beim Normal-Trigger, da bei den anderen Trigger-Modi durch den Trigger-Timeout ohnehin ein Triggerevent ausgelöst wird. Nur beim Normaltrigger kommt halt nichts, da steht das Signal so lange bis was kommt. Der Normal-Trigger ist aktiv wenn: - der Trigger-Mode auf "Normal" steht - der Single Mode aktiv ist D.h. nur dann funktioniert sinnvollerweise der manuelle Trigger. Wenn man im Stop-Mode manuell triggern will muß man nur auf "Single" schalten und kann dann triggern. Hayo
Gast
#2042396
branadic schrieb: > Ja klar lässt sich das damit machen, allerdings ist diese Lösung dirty. > Schöner wäre dafür ein eigenes Menü, weil ich dann am Kanal einfach den > Tastkopf wechseln kann, ohne gleich einen komplett neuen DAC-Abgleich > des gesamten Gerätes durchführen zu müssen. Stattdessen hätte ich einen > zusätzlichen Abgleich für einen ausgewählten Kanal. Könnte man das nicht einfach erledigen, indem vom HW-Setup mehrere numerierte Versionen gespeichert werden können. Die Standardtastköppe sind dann mit Setting0 verknüpft. Dann braucht man für die Tastköpfe nur noch einen Menüeintrag "spezial" und bei dessen Aufruf wird wird dann neben Name und Teilverhältnis auch die Nummer des Settings eingestellt. Das könnte man später auch auf Stromsensoren usw. ausbauen.
Gast
#2042436
Danke Hayo, dass Du Dir gleich Zeit für die Verbesserungen genommen hast. Allerdings dachte ich an das manuelle Auslösen über ein zweites Drücken der Single-Taste, wie Charly schon schrieb: > ps. warum so kompliziert mit dem manuellen triggern im Single mode? > im Single mode (Single=rot) koennte doch ein erneutes druecken > der Single Taste ein Triggern ausloesen, oder ? Ich bevorzuge möglichst wenige Tastendrücke. Das mit dem Inlinen muss man nochmal im ASM-Listing prüfen, ich habe nämlich schon erlebt, dass bei einem Inline nur der Call weggespart wird, aber die Stack-Geschichte blieb. Jörg Wunsch hat mir dazu erklärt, dass das von den Compiler-Einstellungen und dem Programm-Aufbau abhängt (es gibt z.B. auch _always_include_). Steht in der gcc-Doku ziemlich gut beschrieben. > - die manuelle Triggerung macht nur in einem Triggermodus Sinn, > nämlich beim Normal-Trigger, da bei den anderen Trigger-Modi durch > den Trigger-Timeout ohnehin ein Triggerevent ausgelöst wird. > Nur beim Normaltrigger kommt halt nichts, da steht das Signal so > lange bis was kommt. > >Der Normal-Trigger ist aktiv wenn: > > - der Trigger-Mode auf "Normal" steht > - der Single Mode aktiv ist Ehrlich gesagt, musste ich das mehrmals lesen, bis ich es verstand. Warum schriebst Du nicht einfach: Die manuelle Triggerung macht nur im Normal- und Single-Triggermodus Sinn? Autor: Jörg H. (idc-dragon) Datum: 05.01.2011 14:08 Hayo, hast Du die anderen Verbesserungen mal angeschaut? Ich würde schon begrüßen, dass die Verbesserungen eingearbeitet werden, wenn Jörg sich schon so viel Mühe gemacht hat. Ich schlage einen Teil 4 vor. Das Scrollen hier dauert eine halbe Ewigkeit.
Also das Letzte zuerst, ja ich denke es macht zum neuen Jahr durchaus Sinn einen neuen Hardware und Softwarethread zu starten. Gleicher Name und eine Nummer höher, dann hat man den Bezug. Wer macht es diesmal? Nicht vergessen den alten Thread sauber abzuschließen, damit da nicht ewig weitergepostet wird. Ihr habt alle echt gute Ideen und Vorschläge, seit mir nicht böse wenn ich die nicht sofort alle umsetze. Zum Teil muß ich da erst drüber nachdenken und ich habe natürlich auch nur begrenzt Zeit für die Umsetzung. Die Sachen die sich interessant anhören notiere ich mir auf jeden Fall und gehe sie dann bei Gelegenheit an. Guats Nächtle Hayo
Gast
#2042529
Gute Idee Guido, wäre ein gangbarer Mittelweg. branadic
Hallo Hayo, ein paar Anmerkungen wegen den Screenshots: 1. Du hast die B/W screenshots im OS_CompMode wegrationalisiert. Lösung:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
2. Ein Screenshot mit der OS-Version dauert höchstens 20s. Die BF-Version braucht maximal 29s. Gibt es einen guten Grund an der BF-Version festzuhalten? Sonst machen wird die OS zum Standard und an Stelle der BF baue ich meine Routinen zur Übertragung an den SD/USB-Host ein. 3. Finde ich es sinnvoller den Softkey "Save to BMP" in "Save color" umzubenennen und "Save to PGM" in "Save B/W". Das ist eindeutiger, außerdem wechselt man eh nicht ständig das Dateiformat. Das kann ja weiterhin von der PC-Software bestimmt werden. 4. In deinen *.zip liegt im Screenshot_0.92OS Ordner ein kaputtes pdf. 5. Habe ich gerade vergessen. ;-) Mfg, Kurt
Hi Kurt. > 1. Du hast die B/W screenshots im OS_CompMode wegrationalisiert. Lösung: >
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Wozu brauchst Du denn Schwarzweiß-Screenshots? Ich dachte die wären eher überflüssig. Kann ich aber wieder nach Deinem Vorschlag einbauen wenn das benötigt wird. > 2. Ein Screenshot mit der OS-Version dauert höchstens 20s. Die > BF-Version braucht maximal 29s. Gibt es einen guten Grund an der > BF-Version festzuhalten? Sonst machen wird die OS zum Standard und an > Stelle der BF baue ich meine Routinen zur Übertragung an den SD/USB-Host > ein. Ja es gibt einen Grund, den hatte ich auch schon mal vor einiger Zeit erläutert. Die OS-Screenshotverion ist zwar von der Kompressionsroutine her auf aktuellerem (heißt schneller) Stand, aber mir gefällt das Bedienkonzept der remote Steuerung bei der OS-Version nicht so gut. Ich möchte lieber die Steuerung direkt am Oszi vornehmen. > 3. Finde ich es sinnvoller den Softkey "Save to BMP" in "Save color" > umzubenennen und "Save to PGM" in "Save B/W". Das ist eindeutiger, > außerdem wechselt man eh nicht ständig das Dateiformat. Das kann ja > weiterhin von der PC-Software bestimmt werden. Das ist aber leider nicht ganz korrekt, da auch PGM in Farbe gespeichert wird. Der Unterschied ist im Wesentlichen, dass bei PGM die Farblayer einzeln erzeugt werden, und bei BMP werden diese gleich "gemerged" zu einer Datei. Was ich mir vorstellen könnte wäre, dass abhängig von der Auswahl BF/OS die Buttons eine jeweils eigene Beschriftung und Funktion haben (dann könnte man da für die OS auch BW mit einbauen) -> also ein dynamisches Menü, dann kann jeder nach eigenem Gutdünken arbeiten. > 4. In deinen *.zip liegt im Screenshot_0.92OS Ordner ein kaputtes pdf. Muß ich mal prüfen, ich hatte den Ordner einfach so kopiert ohne den Inhalt zu checken. > 5. Habe ich gerade vergessen. ;-) Kenn ich, das ist altersbedingt. Versuchs mal mit nem Reset... Gruß Hayo
@Guido + branadic Ja das wäre so machbar und wohl die flexibelste Lösung. Hayo
eProfi schrieb: > Allerdings dachte ich an das manuelle Auslösen über ein zweites Drücken > der Single-Taste, wie Charly schon schrieb: >> ps. warum so kompliziert mit dem manuellen triggern im Single mode? >> im Single mode (Single=rot) koennte doch ein erneutes druecken >> der Single Taste ein Triggern ausloesen, oder ? Eine extra Taste für den manuellen Trigger braucht man aber auf jeden Fall, da man sonst im laufenden Betrieb bei "Normal" Triggerung nicht manuell auslösen kann. Ich kann aber den manuellen Trigger zusätzlich als weiteren Druck der Single-Taste mit einbauen. Sehen das die Anderen hier auch so? > Ehrlich gesagt, musste ich das mehrmals lesen, bis ich es verstand. > Warum schriebst Du nicht einfach: > Die manuelle Triggerung macht nur im Normal- und Single-Triggermodus > Sinn? Sorry wenn ich das unnötig verkompliziert habe. Gruß Hayo
Hayo W. schrieb: > Wozu brauchst Du denn Schwarzweiß-Screenshots? Ich brauche die garnicht, aber vieleicht jemand anders? Keine Ahnung. Hayo W. schrieb: > Ja es gibt einen Grund, den hatte ich auch schon mal vor einiger Zeit > erläutert. Die OS-Screenshotverion ist zwar von der Kompressionsroutine > her auf aktuellerem (heißt schneller) Stand, aber Das heißt du könntest nur die Kompressionsroutine übernehmen? Hayo W. schrieb: > Das ist aber leider nicht ganz korrekt, da auch PGM in Farbe gespeichert > wird. Du sagst es. Ein Portable Graymap wird in Farbe abgespeichert. Der Button sollte dann "Save to PPM" heißen. Hayo W. schrieb: > Was ich mir vorstellen könnte wäre, dass abhängig von der Auswahl BF/OS > die Buttons eine jeweils eigene Beschriftung und Funktion haben Gute Idee! Bekomme ich dann den 5. Soft-Button als "Save to USB"? Mfg, Kurt
Bitte dort weiterdiskutieren und hier zu machen. Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"