Hallo Hayo, habe das DSO jetzt komplett auseinander genommen um das zweite RAM zu sehen. Ist das normal, das der Teil für die Messschaltung so „zusammengeschustert“ aussieht? Habe das Foto unter "imageshack . us f 220 / wp000700.jpg" gestellt, da es etwas größer ist. Werde jetzt off gehen und morgen weiter machen. Gruß Timo
@Hayo OK, I checked carefully the PCB, the two RAM, and the others but I do not notice anything special to view. (Pins desoldered, shorts or other problem) The behaviour of the DSO it's the same. Can I do anything else to diagnose the problem? Something might be defective ... :-( What is the small button next to the RAM? Thanks Errico
@ Hayo Maybe I found two friends who have the same problem: www.mikrocontroller.net/topic/250182 I don't understand well German also with the Google Translator, but I think that the situation it's the same. I forget the DSO switched on for 4/5 hours during the night and the day after is no longer running properly as described here. :-((
Hallo Hayo, ich habe jetzt mal das Perl-Script für den RAM Loader ausgeführt. Dies lief ohne Fehler durch. Heißt das jetzt, dass die FW in das RAM geschrieben wurde, somit das RAM OK ist oder dass der LOADER es nur fehlerfrei angenommen hat und der Status der weiteren Verarbeitung ungewiss ist? Gruß Timo
Hi, bin leider momentan nur kurz mal zwischendurch online. timo r. schrieb: > Heißt das jetzt, dass die FW in das RAM geschrieben wurde, somit das RAM > OK ist oder dass der LOADER es nur fehlerfrei angenommen hat Es gibt beim Schreiben keine Rückmeldung ob der Vorgang erfolgreich war. Daher kann man das nicht unbedingt als Indikator verwenden. Ich habe inzwischen noch mal in anderen Threads zu dem Thema gestöbert. Anscheinend ist auch die Verlötung des/der FPGAs ein Kandidat für diese Probleme. Die FPGAs werden im Betrieb recht warm, da kann es sein, dass schlechte Lötverbindungen sich quasi "abarbeiten" durch die entstehenden thermischen Spannungen. Grundsätzlich tippe ich aber so oder so auf kalte Lötstellen. Die Suche ist natürlich nicht ganz einfach. Wer über einen Lötkolben mit feiner Spitze und etwas Löterfahrung verfügt, kann die Beinchen einfach mal auf Verdacht nachlöten. Leider lassen sich kalte Lötstellen nicht unbedingt mit einer Lupe erkennen. Gruß Hayo
Hayo W. schrieb: > Wer über einen Lötkolben mit feiner Spitze und etwas Löterfahrung > verfügt, kann die Beinchen einfach mal auf Verdacht nachlöten. Mit einer breiten Lötspitze - wegen des besseren Wärmeflusses - und Flußmittel geht es noch besser. So sieht das dann aus: http://www.youtube.com/watch?v=erb6-i54tbo Gruß Rainer
Noch mein Senf: timo r. schrieb: > Heißt das jetzt, dass die FW in das RAM geschrieben wurde, somit das RAM > OK ist oder dass der LOADER es nur fehlerfrei angenommen hat und der > Status der weiteren Verarbeitung ungewiss ist? Kommt drauf an. welcher Loader das war. Für den alten 3-Minuten Loader gilt wohl das was Hayo gesagt hat. Wenn du aber vom 15-Sekunden UCL-Loader sprichst liegen die Dinge etwas anders. Da ist in der 2.Phase meine Software im RAM am Ackern. Es wird eine Prüfsumme der dekomprimierten Daten gebildet. Anfangs habe ich dafür tatsächlich blockweise aus den RAM zurückgelesen, erst die neuere Assemblerversion macht das on the fly. Letztere ist noch nicht verbreitet. Jörg
E U R E K A !!! The problem was the ram, I proceeded to resolder the pins with a few drops of flux and tin and the little Welec is running back, is great with the latest firmware 5.7C2 Thanks Hayo!
Thanks Rainer Actually I did not expect to see him running so soon, with a really simple remedy. Errico
@All (with no running welec) SUUUPPPIIII mein W2024A geht wieder ... Nun wird die vermutete Hardware 1C9.0E auch erkannt. Interessant ist, dass ich vorher eine komplette Softwarerücksicherung von meinem Neuen mit der HW: 8C7.0E eingespielt hatte. Die Hardware-ID auf dem Bildschirm kommt also aus dem EPCS16. Fehlersuche ergab wie von vielen vermutet auch schlechte Lötstellen an den Speicherchips. Leider war das mein zweiter Versuch ... aber gut Ding will Weile haben. DANKE ALLEN ... PS: Ich werde wohl gleich mal die aktuelle Version von Hayo einspielen ... Grüße Andi
Hallo, danke an alle, besonders an Hayo. Mein DSO hat sich gerade wieder gemeldet. Es war bei mir auch der RAM und zwar der Chip, bei dem man das Gerät ganz zerlegen muss. Das flashen hat sogar mit der kalten Lötstelle funktioniert. Werde die FW aber zur Sicherheit noch mal neu aufspielen. ---------------------------------------------- Version : 1.2.BF.5.7 C2 Hardware: 8C7.0E Serial : 00128402C7 Model : W2022A / 2 Channels ---------------------------------------------- Gruss Timo
Holla die Waldfee... gleich drei Patienten aus dem Koma erwacht und alle drei wie vermutet mit kalten Lötstellen am RAM. Das ist ja ziemlich eindeutig. Das sind ja mal richtig gute Nachrichten. Glückwunsch auch von mir. It is nice to hear the success message. It is also an approvement for me that the RAM soldering is not the best... I think we will hear more from such problems in future. Wish You much fun with Your little toy Hayo
@Rainer Sehr schönes Video. Der Kollege der das vorführt hat es gut drauf. Sehen ja besser aus als werksverlötet die Beinchen. Gruß Hayo
@Hayo, ja jetzt kann es losgehen ... Der Versionssprung (von 1.4 Welec auf Deine letzte) ist ja absolut der Hammer ... ich konnte ja die letzte Nacht gar nicht mehr ruhig schlafen ;-) Grüße
Angehängte Dateien:
@Hayo,
ich hätte da noch einen kleinen Schönheitsfehler ...
Versuche mal im normalen Horizontalen "Main"-Modus die manuelle Messung
("Cursors"). Dann über "Main/Delayed" auf FFT umstellen ...
... dann sind noch die alten Buttons und Linien (bei mir) zu sehen.
PS: Leider bin ich für mein Käferreporting bekannt ... ;-)
Grüße Andi
Hi Andi, durch solche Fehlermeldungen konnte die Firmware entscheidend verbessert werden. Sobald ich etwas Zeit habe werde ich mir das mal ansehen. Danke für den Hinweis. Gruß Hayo
Angehängte Dateien:
@Hayo, sehr schön ... Im Zusammenhang stehend evtl. noch ein Hinweis zum Remote Export einer B/W-Grafik ... ... bei den Zusatzlabeln ist das Gitter noch zu sehen. Könnten diese Label evtl. noch mit weiß gefüllt werden? Das sieht etwas besser aus wenn man die Bilder vewenden möchte. PS: Nice to have! Evtl. gibt es ja noch Gegenargumente ... Grüße Andi
Angehängte Dateien:
@Hayo Noch etwas was mit dem Browse-Button ... Im MAIN mit BROWSE ... Umstellung auf FFT ... zeigt folgendes Bild! PS: Viel Spaß beim Lernen ... ;-) Grüße Andi
hm, könnte ich die Experten nochmals um einen Kommentar bitten ? Ich wollte heute Hayos letzte Softwareversion aufspielen, leider verhält sich das DSO dabei sehr sonderbar. Ich schaffe es nämlich nicht, es in den "Downloadmodus" zu versetzen. Zwar reagieren die zwei berühmten grauen Knöpfe links unterm Schirm bei der entsprechenden Menüwahl jeweils wie sie sollen, gleichzeitiges Drücken (egal in welchem Grundmenü ich gerade bin) bringt aber nicht den ersehnten "weißen Schirm" den ich brauche um das Aufspielen zu starten. Alles andere scheint normal zu funktionieren. Auch mehrfaches Ein und Ausschalten hat nichts gebracht ... Mir tun schon die Finger weh' vom vielen Knöpfe drücken ! Hätte jemand vielleicht 'ne schlaue Idee ? Danke: Hermann
Bei mir wird der Bildschirm in der Regel auch nicht weiß, bleibt eher schwarz, bzw. wird es nach dem Loslassen wieder. Hat du die Knöpfe in der richtigen Reihenfolge losgelassen? Den äußeren (linken) länger halten, den anderen zuerst freigeben. Die Drück-Reihenfolge scheint egal zu sein, wichtig ist das sie mal beide gleichzeitig gedrückt waren. Den linken länger halten ist Bootloader, andersrum einfacher Reset. Jörg
wow, dat war fix ! danke Jörg für die schnelle Antwort! Leider ändert die Reihenfolge mit der ich die Knöpfe drücke bzw. loslasse nichts. Der Schirm bleibt immer "an" (dh. er wird nie schwarz bzw. weiß und verbleibt in seinem momentanen Modus) egal wie rum ich's angehe. Ach ja, die Version die ich momentan drauf habe ist die 1.2.BF.5.1C4 obwohl das hier kaum relevant sein dürfte. Grüsse: Hermann
Hermann E. schrieb: > Ach ja, die Version die ich momentan drauf habe ist die 1.2.BF.5.1C4 > obwohl das hier kaum relevant sein dürfte. In der Tat. Probiere die Tasten mal im Menu, ob die vllt. defekt sind. Erst die ganz linke Taste drücken, dann die zweite von links. Anschließend die 2. von links loslassen und zuletzt die ganz linke.
Da sind ja noch jede Menge Nachteulen unterwegs ! War gerade weg da ich im Keller noch mein altes Tektronix (ursprünglich vom Müll) wieder ausgegraben habe. Erst mal Danke für eure Hilfe, in der Not schätze ich diese gleich doppelt ! Was die Tasten angeht habe ich so ziemlich alle möglichen Sequenzen und Dauer versucht - ohne Erfolg. Wie gesagt, jede einzelne Taste reagiert noch im Sinne des Menus (soweit ich das sehen kann). Ich denke also nicht das die Tasten bzw ihre Anschlüsse selbst defekt sind. Gibt's vielleicht die Möglichkeit so 'ne Art "Hard reset" zu machen indem man auf dem PCB irgendwelche Kontakte kurzschliesst bzw auf Null zieht, ähnlich wie beim AVR-Programmieren ? Grüsse: Hermann
Ich hab sowas auch schon mal erlebt, geholfen hatte bei mir den Flash nachlöten(W2022A). Allerdings sah das Fehlerbild anders aus, timeout beim flashen. Gute Nacht - Jochen
Die Lötstellen scheinen ja ein echter Schwachpunkt zu sein. Wüsstest Du an was man das Flash erkennen kann, bzw wo es sitzt ? Gute Nacht auch meinerseits: Hermann
Ja, gibt eine schöne Doku dazu - ich poste gleich mal den link, moment....
...im dritten Bild unter der Stiftleiste, ungefair in der Mitte oberhalb der 16(beim 2024) adc´s - sourceforge.net/apps/trac/welecw2000a/wiki/Hardware http... voran
Danke ! Ich gehe davon aus das es das etwas grössere Chip ist !? Schaut schwer zu Löten aus da mir auf dem Bild die Kontakte ziemlich klein erscheinen. Jetzt muss ich aber wirklich in die Heia ... Gute Nacht: Hermann
Wenn Du das Gehäuse aufgeschraubt hast, kannst Du ihn nicht verfehlen. In der Nähe, eher rechts von der Stiftleiste gibt es auch einen Taster für den manuellen Reset. Sei ganz vorsichtig beim Löten, nicht ohne Flussmittel!! Viel Erfolg!
Würde der Taster auch das Neuaufspielen der Firmware ermöglichen (Falls er denn geht ?) Ich geh' mal schon Zähneputzen ... Hermann
@Hermann bei mir ist das nur ein normaler Reset (der kleine Taster auf der Platine). Um in den GERMS Modus zu kommen, benötigst Du schon die beiden linken Tasten wie vom Jörg beschrieben. Gruß Andi
Danke Andi, das erspart mir ein unnötiges Ausprobieren. Ich zier mich noch ein wenig mit dem Löteisen ranzugehen, die Frage ist es so zu lassen (der Spatz in der Hand) oder es zu versuchen für das Update (Die Schwalbe auf dem Dach). Muss eh' erst noch Flussmittel bestellen, das läßt mir Zeit zum Nachdenken. Nochmals Danke: Hermann
Ich hatte mir auch die Arbeit gemacht und alle Pins des Flash nachgelötet. Leider ist der Pinabstand so klein, dass das Flussmittel (wie schon beschrieben) dringend verwendet werden sollte(muss). PS: ... das alte Geigenkolophonium mit Spiritus würde es auch machen ;-) ... mir wäre die Schwalbe lieber ... und Hayo freut sich. Grüße
Hi there. Any news about the spikes fix? It seemed me we were on the right way, maybe through updating the fpga by quartus to reach 1c9.0e version or so and adjusting the power supply value of the FPGA. Cheer, Cy
boh ! wollte heute das Flash nachlöten und habe davor einen letzten Versuch gemacht das DSO in Lademodus zu versetzen - und siehe da es hat funktioniert (aber nach wie vor bei weitem nicht bei jedem Mal). Nach ca 20 Versuchen konnte ich die letzte BF Version (endlich) erfolgreich flashen. In der Regel verschwinden solche Probleme natürlich nicht von alleine, aber solange ich eine Operation am offenen Herzen vermeiden kann ... Nochmals vielen Dank an alle (Jochen, Jörg, Andreas, Guido) die mir mit Rat und Tat zur Seite gestanden sind und natürlich vor allem an Hayo: Die ersten Tests der letzten Version sehen vielversprechend aus ! Hermann
Welec scheint dazu gelernt zu haben... Ich hab meines damals auch direkt bei Welec ersteigert (war aber noch ein anderen eBay Account) - und für 140€ bekommen, ein anderes ging zeitgleich für 160€ raus - da war der Startpreis noch wesentlich geringer und bei so einem Nieschenprodukt war es nicht sehr klug vom Verkäufer, mehrere Auktionen zeitgleich enden zu lassen.
Sebastian S. schrieb: > Ich hab meines damals auch direkt bei Welec ersteigert (war aber > noch ein anderen eBay Account) Wahrscheinlich tek4you_eu. Der Account scheint inzwischen nicht mehr zu existieren.
ich bin nun auch im Club, habe heute mal Oszi auf die Arbeit mitgenommen und nach dem Einschalten bleibt es dunkel, wobei Bootloadermodus zeigt er an also dieser weiß/schwarz Wechsel. Komischerweise geht das WLAN, was sonst bei eingeschaltetem Oszi nicht ging, anscheinend bleibt es irgendwo hängen wo noch keine Display angesteuert wird, da dieses bzw. die Abstrahlung der Displayleitungen zur Störung des WLANs führen. Die Firmware kann leider erst heute Abend wieder einführen. Jemand eine Idee woran dieses unerwartete Nichtstarten liegt. Oder könnte es ein Netzteil sein welches den FPGA versorgt? Wie war nochmal die Tastenkombi für einen Neustart, Taste 2 und danach Taste 1?
Hallo Thomas, ich zitier mal Jörg der mir bei meinem Problem weitergeholfen hat: "Den äußeren (linken Knopf) länger halten, den anderen zuerst freigeben. Die Drück-Reihenfolge scheint egal zu sein, wichtig ist das sie mal beide gleichzeitig gedrückt waren. Den linken länger halten ist Bootloader, andersrum einfacher Reset". Bei mir hat erneutes Versuchen nach einigen Tagen das Problem (zeitweilig ?) gelöst, leider weis ich auch nicht mehr ... Grüsse und viel Erfolg: Hermann
ich hatte mal eine Mail an alle Wittigs geschrieben. Einer bot mir eine Reparatur als Garantieleistung an, einer wollte einen Reparaturversuch für 120€ starten oder 300€ für ein Neugerät. Werde da nochmal anrufen und es klären, 120€ für einen Versuch ist mir zuviel Risiko, gerade wenn es sich nur um einen Lötversuch handeln würde. Gibt es eigentlich noch andere Oszilloskope für die es Open Source gibt?
Thomas O. schrieb: > Gibt es eigentlich noch > andere Oszilloskope für die es Open Source gibt? Meines Wissens nicht, das macht ja unser Oszi trotz seiner kleinen Schwächen so attraktiv. Gruß Hayo
Hey Skipper, wie sieht es aus, können wir gratulieren? Grüße, Guido
Jupp die Sache ist geritzt! Boot ist auch schon gechartert. Vorraussichtlicher Termin für die Weiterentwicklung unseres Projektes ist ab Mitte/Ende Juli. Vorher werde ich da nicht zu kommen, da ich meinen Fuhrpark noch auf Vordermann bringen muß. Gruß Hayo
Macht es tatsächlich noch Sinn an der BF-Firmware weiter zu arbeiten, obwohl Osoz nun schon einen Stand erreicht hat, bei dem es sich lohnt anzuknüpfen? Nicht nur der ernorme Geschwindigkeitszuwachs sprechen dafür. Ich möchte nicht zuletzt auch erwähnen, dass Osoz die Huckepackplatine und die neue gewonnenen Vertikalablenkungen super unterstützt. branadic
Ich gehe mal davon aus, daß Hayo mit "unser Projekt" auch Osoz meinte. Jörg
Hayo W. schrieb: > Jupp die Sache ist geritzt! Na dann meine Glückwünsche, und natürlich: Schönen Urlaub.
Jörg H. schrieb: > Ich gehe mal davon aus, daß Hayo mit "unser Projekt" auch Osoz meinte. > > Jörg Korrekt, so ist es! Guido schrieb: > Na dann meine Glückwünsche, und natürlich: Schönen Urlaub. Besten Dank, bei dem Sch....wetter hier brauche ich das auch. Gruß Hayo
Hallo Hayo and the team, any news about this project,may be within Christmas? Regards, Sandro
Hi there, yes I know it is really quiet here now but don't worry about that, it will go on. Unfortunately I'm really busy with several things at this time but I have good ideas about our old firmware and I'm really looking forward what the other guys are working out with the new FPGA design. The WELEC never will die... So I hope I will find the time to go on with some further improvements which we also can overtake into the new osoz firmware. Have a nice evening Hayo
Hi, who knows personally the engineers who sold the oscilloscope? I am still waiting to receive it won on EBAY! Disappeared? if anyone can contact them look a refund.
Giuseppe schrieb: > Hi, who knows personally the engineers who sold the oscilloscope? > I am still waiting to receive it won on EBAY! > Disappeared? > > if anyone can contact them look a refund. Hi Giuseppe, just if the sellers ebay name was 'welecgmbh', you may get in contact with Mr. Erich Wittig (E.Wittig@welec.de). He seems to be an honest person. Kind regards, Peter M.
> So I hope I will find the time to go on with some further improvements > which we also can overtake into the new osoz firmware. Und Hayo, was gibt es denn inzwischen so Neues zu berichten? Das ist hier so richtig still geworden, schade! Wohin treibt das Schiff?
Hi Robert, auch wenn es hier momentan sehr ruhig ist - ich bin immer noch dabei, zur Zeit halt passiv. Leider hatte ich bislang eine Menge anderer Sachen um die Ohren. Zudem ist der Stand der BF-Firmware eigentlich recht stabil. Die Not und der Druck etwas zu tun ist daher nicht sooo groß. Echte Verbesserungen sind aus diesem FPGA-Design leider ohnenhin nicht mehr rauszuholen. Deswegen verfolge ich auch mit Spannung die Fortschritte die Jörg macht. Denn echte Verbesserungen werden nur so möglich sein. Es lohnt daher eigentlich nicht für das alte Design größere Neuentwicklungen zu starten. Sollte es noch kleinere Wünsche (zusätzliche Funktionen oder Menüeinträge), Verbesserungen oder Bugs geben die ich beheben kann mache ich das natürlich gerne. Gibt es da konkrete Wünsche die sich noch lohnen in die bisherige FW einzubauen? Gruß Hayo
>Gibt es da konkrete Wünsche die sich noch lohnen in die bisherige FW >einzubauen? Von meiner Seite aus zur Zeit nicht. Wollte halt nur mal den Stand der Dinge wissen. Aber schön zu wissen das Du noch am Ball bist!
Hayos Posting hatte ich doch glatt eine Weile übersehen, irgendwie ist die Benachrichtigungsfunktion nicht mehr scharf. Ich bin nächste+übernächste Woche voraussichtlich ein paar Tage dienstlich in Hamburg, wir planen auch ein Treffen. Vor etwa einem Jahr war ich schon mal bei Hayo, wird nun schon fast eine Tradition! ;-) Noch was: Sourceforge "droht" mit einer Umstellung, wir müßten auf deren neue Allura-Platform migrieren. Was das genau bedeutet weiß ich nicht. Die Adresse soll sich in dem Zuge auch ändern. Ich habe natürlich noch nicht auf das angebotene Knöpfchen gedrückt, aber es soll im ersten Quartal 2013 durch sein. Jörg
Angeregt durch Robert habe ich noch mal über die letzte BF-Version sinniert und bin darauf gestoßen, dass es noch einige Sachen gibt mit denen ich etwas unzufrieden bin, die aber völlig Hardwareunabhängig sind und somit eigentlich als Basis für OSOZ dienen könnten. Dazu gehört zum Beispiel der zentrale FFT-Algorithmus und noch einige andere Berechnungen. Mal sehen ob ich mich aufraffen kann da noch eine aktualisierte Version zu bauen. Gruß Hayo
Hi there. Hayo, about improvements to be introduced in the calculations are you thinking something for the sin(x)/x interpolation? I believe it would be a great thing, seems to me some attemps was had already been made in the past and the routine already drafted but never implemented in firmware. And again, any news about the spikes fix? It seemed me we were on the right way, maybe through updating the fpga by quartus to reach 1c9.0e version or so and adjusting the power supply value of the FPGA, but then no news about this important issue. Cheer, Cy
Cy schrieb: > Hayo, about improvements to be introduced in the calculations are you > thinking something for the sin(x)/x interpolation? The sinc interpolation is implemented yet as a draft. But it costs a lot of time of development and there have to be done some more improvements. The main problem is the slow NIOS cpu. The calculation of the sinc algorithm is very slow, although I tried to optimize the calculation speed. But it is not forgotten, I just made a little break to solve some other issues. If Jörgs new OSOZ FPGA with multiplication unit is running stable, it will be no problem to implement the sinc interpolation. > And again, any news about the spikes fix? I got no news about that, but maybe some of the other guys here? This problem will also be obsolete with Jörgs new FPGA-design. I'm looking forward... But the good news are: I'm working on a new BF-version with improved FFT routines. Maybe I will get ready until XMas. Kind regards Hayo
Das "Gipfeltreffen" mit Hayo fiel erstmal aus, weil ich einen Tag später als geplant in Hamburg anfing, Hayo hatte nur am ersten Tag Zeit. Im Januar könnte sich nochmal die Gelegenheit bieten. Für die FFT könnte ich im neuen Design Hilfestellung anbieten. Der Nios erlaubt ja "custom instructions", man könnte vielleicht sowas wie einen Butterfly-Befehl bauen. Im Moment bin ich aber noch an anderen Baustellen. Ein etwas anderer Programmierstiel kann nützen, Tabellen sind nicht mehr unbedingt so angesagt wenn sie nur wenige Rechenoperationen ersetzen. Der Nios II hat als neues Feature zwar einen Datencache, aber der ist leider nicht mehrfach assoziativ. Heißt, wenn 2 Adressen binär hinten gleich enden (modulo Cachegröße in die gleiche Cacheline fallen), dann werfen sie sich zwingend gegenseitig aus dem Cache. Ein Lesezugriff der einen anderen Cacheeintrag verdrängt führt erstmal zu einem Burst aus 8 Schreibzugriffen, dann ein Burst aus 8 Lesezugriffen, in Summe vielleicht 20 Takte. Die Datenbursts können leider auch nicht "critical word first", also die Zugriffsreihenfolge so sortieren daß das gewünschte Datum zuerst gelesen wird und es möglichst schnell weitergeht. Der Instruction-Cache hingegen beherrscht diese Umsortierung, das wäre sonst wohl auch echt übel. Die Länge einer Datencacheline ist einstellbar, man kann die auch verkürzen, für Anwendungen die viel random access machen. Wegen des Instruction-Cache sollte man von loop unrolling eher Abstand nehmen, das bringt nicht viel und verdrängt anderswo Code aus dem Cache. Jörg
Hallo, ich hätte da noch einen Vorschlag für eine Funktion die mich da brennend interessieren würde. Ich bastle ab und an mal an analogen Verstärkerschaltungen und habe dann das normale und das verstärkte Signale an einem Kanal. Wäre es möglich softwaremäßig 2 Kanäle automatisch über einander legen zu lassen und das schwächere Signal per Software zu verstärken bzw. das stärke abzuschwächen. Bei einem analog Oszi kann man neben der 1:10 1:100...Auswahl noch manual stufenlos das Signal noch etwas abschwächen. Wodurch man dann beide signale übereinanderschieben kann. Das ganze müsste auch nur im Single Shot Modus funktionieren dann könnte man soetwas direkt übereinanderlegen und vergleichen. http://www.hobby-bastelecke.de/bilder/schirmbilder/sinus2gleich.jpg
@Jörg Ja die Optimierungen werden beim NIOS II sicher anders aussehen. Da muß man sicher auch etwas mit Try and Error experimentieren was unter dem Strich wirklich was bringt. Nicht desto Trotz bin ich momentan mit dem Ergebnis der überarbeiteten FFT-Routinen recht zufrieden. Das hat auch wieder Lust auf "Mehr" gemacht. Als Referenz verwende ich unter Anderem auch die FFT des chinesischen OWON SDS8102 welches ich seit einiger Zeit besitze. Da muß sich unser Teil nicht verstecken, im Gegenteil. @Thomas Das Thema variable Skalierung hatten wir in der Vergangenheit öfters mal. Grundsätzlich: Ja, ist machbar! Ist aber etwas Fummelkram mit den Skalierungstabellen, da diese dann für jede Einstellung neu berechnet werden müssen. Habe ich aber auch schon drüber nachgedacht. Wäre auf jeden Fall eine nette Herausforderung. Als weitere interessante Herausforderung hatte ich mir schon mal Gedanken zu einer Peak-Detect-Funktion gemacht. Auch nicht trivial aber machbar. Da müßte ich dann Teile in Assembler schreiben um einigermaßen performant zu sein. Sicher auch für OSOZ nicht uninteressant. Gruß Hayo
So Liebe W2000A Gemeinde, es gibt wieder neues Futter. Die neue Xmas Edition ist rechtzeitig zum Fest fertig. Diesmal habe ich an der FFT herumgeschraubt. Achtung - beim ersten Start kommt ein Popup hoch welches darüber informiert, dass die trigonometrischen Tabellen ins Flash geladen werden. Dieser Vorgang dauert ziemlich genau 10 Minuten. Eine Fortschrittsanzeige informiert über den aktuellen Stand. Also bitte mit einplanen und gegebenenfalls Kaffee bereithalten... Wird der Vorgang abgebrochen erscheint das Popup beim nächsten Start erneut, nach Abschluß des Ladevorgangs erscheint das Popup nicht wieder. Dear not german speaking users. Please read the attached read me file because of special upload notes. Gruß Hayo
Danke für das Weihnachtsgeschenk!! Spiele ich morgen gleich auf. Frohes Fest!
Hallo Hayo, willkommen zurück! Apropos Flash: ich hatte mal hier (Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)") u.A. geschrieben, das wir für den Nios-II eine Einteilung des Flash brauche, von wo der denn sein Image ablegen soll. Momentan holt es mein Bootloader von Adresse 0, ab dort habe ich aber nur 3 Pages (a 64k) frei, in der 4. speichert Osoz seine Einstelungen, ab der 5. beginnt das klassische Image. Ich überblicke den Rest nicht, könntest du mal eine Memory Map erstellen, oder gibt es schon eine? Jörg
Moin Jörg. Ja es gibt schon eine. Die aktuelle Version ist immer im jeweiligen Download im DOCS Verzeichnis zu finden unter W2000A Programmers Reference. Da mein Libre-Office die Dateien im Excelformat auf über 13MB aufbläht habe ich diesmal nur die .ods Datei mit reingetan. Ich habe aber gerade auf meinem alten Rechner mit Open Office 3 eine kleine kompakte Datei erzeugt und hänge sie hier mal dran. Zu den Änderungen in der neuen Firmware: Ich habe die bisherigen Tabellen die fest im Code abgelegt waren und damit zur Laufzeit das RAM unnötig blockiert haben rausgeschmissen. Stattdessen gibt es jetzt Generatorfunktionen, die die Tabellen berechnen und eine weitere Funktion, die diese dann ins Flash schreibt. Zur Laufzeit holt sich die FFT nur die jeweils benötigten Tabellen aus dem Flash ins RAM. Dadurch haben wir jetzt genügend Platz um jede Menge Fensterfunktionen in 4096er Breite unterzubringen. Das wäre sonst mit den fest codierten Tabellen etwas eng geworden. Mit der nächsten Version ist es auch geplant die FFT Menüs scrollbar zu machen, da es momentan etwas mühselig ist sich durch die vielen Einträge zu arbeiten. Gruß Hayo
Hallo Hayo, sehr schön, vielen Dank! Wenn das so stimmt gibt es ja tatsächlich geeignet große unbenutzte Bereiche, dann brauchen wir zunächst nichts limitieren oder herumschieben. Ich könnte z.B. die 10 Sektoren ab 0x600000 für das Nios II Image definieren? Bei 0x30000 liegt wie gesagt derzeit der Sektor für die Osoz-Settings, falls du das auch mit in die Tabelle aufnehmen magst. Kann von mir aus auch in einen anderen Sektor. Was ist das diverse "Kleinzeug" gegen Ende? Für die fernere Zukunft mit dem Nios II schwebt mir vor, den Code größtenteils aus dem RAM rauszuhalten (dafür ist es nämlich eigentlich zu schade) und direkt aus dem Flash auszuführen, Cache sei dank. Dann können wir uns feature-mäßig richtig austoben, vielleicht auch modular mit einem Plugin-System. Bis dahin sollten wir die Flash-Map aufgeräumt haben. Jörg
Jörg H. schrieb: > Ich könnte z.B. die 10 Sektoren ab 0x600000 für das Nios II Image > definieren? Ja, die sind leer. > Bei 0x30000 liegt wie gesagt derzeit der Sektor für die Osoz-Settings, > falls du das auch mit in die Tabelle aufnehmen magst. Kann von mir aus > auch in einen anderen Sektor. Ich kann das mit eintragen. > Was ist das diverse "Kleinzeug" gegen Ende? Das ist der Bereich in dem die Konfigurationsdaten liegen. "Protected" sind die festen Einstellungen, das Andere sind die gerade aktuellen Einstellungen die bei jedem Start restauriert werden. > Für die fernere Zukunft mit dem Nios II schwebt mir vor, den Code > größtenteils aus.... dem Flash auszuführen... Wie willst Du das machen? Mit einem Sprungbefehl direkt an eine Flashadresse verzweigen und dann den Code von da weiter ausführen? Hab ich so noch nicht gemacht, interessanter Gedanke. Gruß Hayo
Als Nachtrag: man müßte doch beim Code im Flash alle Sprungaddressen korrigieren um den Addressoffset zwischen RAM und Flash, sonst würde die Ausführung doch wieder zurück an eine RAM-Adresse springen. Oder wie hast Du Dir das gedacht? Hayo
Hallo Hayo, sorry, du bist völlig auf dem Holzweg. :-/ Der Linker täte das für uns erledigen. Man würde eine Section definieren die im RAM liegt und eine die im Flash liegt. Dann kann man für Funktionen oder Daten per #pragma oder auch globaler vorgeben, in welche Section sie sollen. Der Linker berechnet dann automatisch alle Sprungadressen korrekt, da muß man sich um nichts mehr kümmern. Etwas komplizierter ist der Startup-Code. Eine Section muß ins RAM kopiert werden (so wie derzeit alles), die andere bleibt unangetastet, liegt bereits an der richtigen Adresse. Beim alten Nios beginnt "unsere" Programmausführung sowieso im Flash. Der ROM-Bootloader springt dorthin, wenn eine Kennung vorhanden ist und nicht die magische Tastenkombi F1+F2 gehalten wurde. Dort liegt der Startup-Code, der von mir seinerzeit optimierte Hexfile-Schnipsel der immer vorangestellt wird. Der kopiert unser Zeug ins RAM und springt dorthin. Beim Nios-II ist es etwas intelligenter. Der ROM-Bootloader guckt im Flash nach einem "Boot Image", das ist eine Liste von zu kopierenden Speicherblöcken. Die arbeitet er selber ab, am Ende der Liste steht ein Sprungziel. Derzeit besteht die Liste aus nur einem Block, der ins RAM kopiert und angesprungen wird. Jörg
Aaah, verstehe. Also lag ich ja nicht sooo verkehrt, nur dass der Linker dann die Adressen gleich richtig berechnet. Wird die Ausführungsgeschwindigkeit nicht etwas gebremst? Schließlich müssen ja die Daten erstmal in den Cache geladen werden, insbesondere bei Cache-Miss. Die Zugriffszeiten auf das Flash sind doch nicht sonderlich schnell. Bei Cache-Hit läuft es dann natürlich mit voller Geschwindigkeit. Gibt es da Erfahrungswerte, oder sind das eher Vermutungen. Hayo
Hayo W. schrieb: > Wird die Ausführungsgeschwindigkeit nicht etwas gebremst? Schließlich > müssen ja die Daten erstmal in den Cache geladen werden, insbesondere > bei Cache-Miss. Die Zugriffszeiten auf das Flash sind doch nicht > sonderlich schnell. Mal rechnen...: "nicht sonderlich schnell" ist sogar geschmeichelt. Ich habe es am 25MHz Peripherie-Bus hängen, damit möglichst wenig am schnellen Bus hängt. Diese "Clock Crossing Bridge" kostet uns pro Richtung ca. 2 Takte, in Rückrichtung 2 von den langsamen. Das Flash ist nur 8 Bit breit, um eine Cacheline mit 8 32bit Worten zu füllen werden also 32 Zugriffe gebraucht. Das Flash hat 90 ns Zugriffszeit, wegen Aufrundung auf ganze Takte werden derzeit 120 ns draus. Das kann ich noch optimieren, der Peripherietakt kommt neuerdings aus einer PLL. Wenn ich da 44 MHz draus mache wären es 4 Takte für einen Zyklus, also 128 für eine Cacheline, plus 2 für die Bridge macht 130 von den 44MHz Takten plus noch 2 von den 75MHz Takten macht bestenfalls rund 3 us. Das SRAM schafft eine Cacheline in 11 von den 75MHz Takten, macht 0,15 us, ist also gut 20 mal schneller. Klingt erstmal dramatisch. > Bei Cache-Hit läuft es dann natürlich mit voller Geschwindigkeit. Gibt > es da Erfahrungswerte, oder sind das eher Vermutungen. Die geschwindigkeitskritischen Funktionen zum Zeichnen und Rechnen sowie Interrupthandler würde ich natürlich im SRAM lassen. Aber der ganze Menü-Code, Zeichensätze, etc. ist meiner Erfahrung nach völlig egal. Jörg
PS, gerade nachgemessen: Im Moment dauert eine Flash-Cacheline 3,85 us, das kommt hin, entspricht etwa der jetzigen Verlangsamung von 90 auf 120 ns.
Hmm, vermutlich muß man es am "lebenden" Objekt mal probieren wie es sich auswirkt bzw. bei welchen Funktionen es sich eher nicht auswirkt. Aber ist natürlich eine Möglichkeit das RAM freizuhalten. Wieviel RAM gibts denn im neuen Design? Hayo
Hayo W. schrieb: > Wieviel RAM gibts denn im neuen Design? Nach wie vor 2 MB SRAM, von den Chips verschwindet keiner, und ich habe leider auch keine Magie zu bieten da mehr draus zu machen. ;-) Verwechselst du das gerade mit FPGA-internem Speicher? Capture-Memory bleibt wohl auch bei 16K/Kanal, soll aber effizienter genutzt werden. Volle Größe auch bei Zeitbasen mit <4 ADCs, 32K wenn nur ein Kanal pro FPGA benutzt wird. Jörg
Ups, ja hab das mit dem RAM und dem Capture-Speicher verwechselt. Hayo
Hi Hayo, Jörg H., Thomas O. and guys all! Hayo, thanks You very, very much for the free time You provided generously to us and for this new firmware's version!!! I downloaded your latest great job, the new 1.2.BF.5.8XE and I will go to test it a bit. I will let you know, keep in touch! ;-) As always I am speechless, RESPECT!!! Jörg H schrieb: >Ein etwas anderer Programmierstiel kann nützen, Tabellen sind nicht mehr >unbedingt so angesagt wenn sie nur wenige Rechenoperationen ersetzen. Hayo, in the ultimate 1.2.BF.5.8XE firmware you moved FFT tables from RAM to flash memory. Is it also for compatibility with the Jörg H. new OSOZ FPGA design? Working synergically follow suggestions and planned road map will take us far, great work! Thanks Jörg H., Hayo and all which are involved in the Welec Project! Hayo W. schrieb: >The main problem is the slow NIOS cpu. >But it is not forgotten, I just made a little break to solve some >other issues. If Jörgs new OSOZ FPGA with multiplication unit is running >stable, it will be no problem to implement the sinc interpolation. Hayo, this is a good news, i believe sin(x)/x interpolation will be an important improvement for our beloved DSOs. Thanks a lot! Hayo W. schrieb: >> And again, any news about the spikes fix? >I got no news about that, but maybe some of the other guys here? This >problem will also be obsolete with Jörgs new FPGA-design. I'm looking >forward... OK Hayo and all. I hope someone fix the problem in a way or other. As it is now it is one of the great trouble with the Welec's DSOs. Lucky are the people which they have the 1C9.0E FPGA version because seems that have not the spikes problem if I am not wrong reading old posts in the forum. May be the new FPGA design surely solve the problem. Thomas O. schrieb: >Wäre es möglich softwaremäßig 2 Kanäle automatisch über einander legen >zu lassen und das schwächere Signal per Software zu verstärken bzw. das >stärke abzuschwächen. > >Bei einem analog Oszi kann man neben der 1:10 1:100...Auswahl noch >manual stufenlos das Signal noch etwas abschwächen. Wodurch man dann >beide signale übereinanderschieben kann. > >Das ganze müsste auch nur im Single Shot Modus funktionieren dann könnte >man soetwas direkt übereinanderlegen und vergleichen. I agree, good suggestion Thomas O.! That is roughly I wrote in the past about the possibility to implement FINE/COARSE in the rotatory amplitude setting, thing it is pretty normal in analog oscilloscopes and some DSO(Tektronixs TDS2xx and TDS 1xxx family DSO have it). I know, it is not simple, but perhaps with the new Jörg's new OSOZ FPGA... :-) We will see! ;-) A last thing if I can. It is about the anomaly in the scale factor when measuring pulse waveforms. Please refer at these: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" May be due an hardware lack, but it could even be a software problem. Has somebody noticed something like that? Thanks in advance Vielen Dank und Frohes Fest! Mit freundlichen Grüßen, Luc
Hallo an alle, Grüße aus dem Samnaun in der Schweiz und habe gerade festgestellt, dass es hier im Hotel WLAN gibt. Werde also mal zum Forum und auf die Mails antworten. Hi Luc, greetings from Swiss, the country of clocks. I will try to answer Your questions carefully. > I downloaded your latest great job, the new 1.2.BF.5.8XE and I will go > to test it a bit. > I will let you know, keep in touch! ;-) Thanks from my side too for your really good testing. In this version I only improved the FFT - not enough time. But it was a good possibility to start a comeback ;-) > Hayo, in the ultimate 1.2.BF.5.8XE firmware you moved FFT tables from > RAM to flash memory. > Is it also for compatibility with the Jörg H. new OSOZ FPGA design? Indeed, it is. Although the new design will have a much faster multiplication, the calculation of the trigonometric function, especially the window functions will cost too much time. So this part of the FFT calculation will be the same in the new design. But there are some other calculations that might be much faster in the new design and maybe we won't need tables for the scaling anymore. Also it may be possible to implement special "signal processor like" registers or processing options which will speed up combined multiplication and addition like FFT calculations (butterfly) or filter calculations like sinc interpolation. >>> And again, any news about the spikes fix? > I hope someone fix the problem in a way or other. This problem is for sure a problem with the timing in the FPGA when writing ADC values into the capture memory. If I'm informed right there are existing two main versions (in three FPGA versions) Version 1 (which are both of mine) has spikes only on some special situations and as my 4 Channel DSO when it is hot after using for some hours. Version 2 has the spike problem every time! If you got this version, the only possibility might be to change the FPGA version to one of the version 1 (don't know if someone tried this). The ultimative change will be the new OSOZ-Design, because of continuous development and improvement - and open source! > I agree, good suggestion Thomas O.! > That is roughly I wrote in the past about the possibility to implement > FINE/COARSE in the rotatory amplitude setting, thing it is pretty normal > in analog oscilloscopes and some DSO(Tektronixs TDS2xx and TDS 1xxx > family DSO have it). Yes I know, my analog Tek does have it too and I like it. I will think about it... > A last thing if I can. > It is about the anomaly in the scale factor when measuring pulse > waveforms. > Please refer at these: > Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" > Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" > May be due an hardware lack, but it could even be a software problem. I did not see this problem when I tested different wave forms. Maybe I have to check it once more... Wish you all a happy xmas ...and some snow and lower temperatures for me ;-) Hayo
Happy 2013 and thank you to Hayo and the team from Sandro
Neues Jahr, neues Glück. Wieder einige Bugfixes (auch von Dir Andi), Erweiterungen und Verbesserungen. Für diejenigen die die letzte Version (5.8 XE) noch nicht aufgespielt hatten: Nach dem Upload werden die trigonometrischen Tabellen neu berechnet und ins Flash geschrieben. Das dauert 10 Minuten. Ein Popup informiert über den Fortschritt. Viel Spaß
Hallo an alle, und vielen Dank Hayo für die neue Version. Die Erweiterung ist wirklich sehr brauchbar, freu! Gruß Jochen
Hallo allerseits, schon gibt es das nächste Update. Hintergrund ist der Beitrag von Jörg in dem er darauf hinweist, dass der Abschlußwiderstand im DSO Eingang aufgrund der parallel liegenden ADCs nicht 150 Ohm betragen muß sondern 174 Ohm um einen Gesamtwiderstand von 150 Ohm zu erreichen. Durch den falschen Abschluß wird sonst der Vorverstärker am Ausgang überlastet. Ich habe also den Widerstand gegen 180 Ohm (ist eine gängige Größe) ausgetauscht und kann bestätigen, dass die vorher aufgetretenen leichten Verzerrungen (Treppchenbildung) verschwunden sind. Wer also in seiner Eingangsstufe etwas ohne großen Aufwand optimieren will sollte die Kombination 24.9 Ohm / 180 Ohm verwenden. Passend dazu habe ich die Skalierungsfaktoren in der neuen Version angepaßt. Die Faktoren für die Kombination 24.9 Ohm / 150 Ohm stehen weiterhin zur Verfügung, sozusagen als Bestandsschutz. Gruß Hayo p.s. wer absolut keine Widerstände auf Teileträgern findet - ich habe noch 4998 Stück in 180R rumliegen.
Moin Hayo, werden die trigonometrischen Tabellen nach dem letzten Update nicht wieder in das Flash geladen, oder bleiben diese erhalten? Wo werden die denn hingeschrieben, vielleicht in den protected Bereich? Denn nach dem Flashen, wird sonst nichts geladen, das Welec ist danach sofort betriebsbereit! Gruß Michael
Moin Michael, > werden die trigonometrischen Tabellen nach dem letzten Update nicht > wieder in das Flash geladen, oder bleiben diese erhalten? Genau, einmal ins Flash geschrieben bleiben die auf ewig (so ungefähr jedenfalls) drin und müssen nicht mehr neu geschrieben werden. > Wo werden die denn hingeschrieben, vielleicht in den protected Bereich? Nein, die Tabellen liegen in drei eigenen Sektoren im hinteren Drittel des Flash. Dort ist noch eine ganze Menge ungenutzter Platz. Die Config und Protected Sektoren liegen ganz am Ende. Die genaue Belegung kann man sich in der Programmers Reference auf dem Tab "Flash" ansehen. > Denn nach dem Flashen, wird sonst nichts geladen, das Welec ist danach > sofort betriebsbereit! Genau, so soll es sein. Gruß Hayo
Hi, ich melde mich auch mal wieder, nachdem ich eine Weile nicht öffentlich in Erscheinung getreten bin. Letzte Woche habe ich Hayo besucht. Wir haben unsere Zeit leider nicht sehr effizient genutzt, haben hauptsächlich Quartus installiert (und sind nicht ganz fertig geworden damit), statt eine Roadmap zu pflegen, Hayo in Osoz und Nios II einzuarbeiten, etc... Den zweiten Teil des Abends waren wir beim berühmten Griechen. Nun weiß ich, warum es Hayo da so gefällt. ;-) Hayo W. schrieb: > Hintergrund ist der Beitrag von Jörg > in dem er darauf hinweist, dass der Abschlußwiderstand im DSO Eingang > aufgrund der parallel liegenden ADCs nicht 150 Ohm betragen muß sondern > 174 Ohm um einen Gesamtwiderstand von 150 Ohm zu erreichen. Durch den > falschen Abschluß wird sonst der Vorverstärker am Ausgang überlastet. > > Ich habe also den Widerstand gegen 180 Ohm (ist eine gängige Größe) > ausgetauscht und kann bestätigen, dass die vorher aufgetretenen leichten > Verzerrungen (Treppchenbildung) verschwunden sind. Die Ehre gebührt Branadic, nicht mir. Überlastung ist weniger das Problem (glaube ich mich zu erinnern), eher eine Fehlanpassung, was die HF-Eigenschaften verschlechtert. Warum nicht gleich den richtigen Widerstand von 174 Ohm einlöten? Den "Fehler" hatten wir doch schon mal, mit 33 oder 22 Ohm statt der 24,9. Wer will denn diesen Zoo von Fehlbestückungen im UI haben? Ich finde, wir sollten nur die Originalbestückung und den korrekten Wert unterstützen, nicht alles mögliche was irgendwer gerade in der Bastelkiste hatte. Wer das löten kann, der kann sich auch die korrekten Werte besorgen. Und wenn sich die Erkenntnis ändert, dem folgen. Wir sind nicht im Hardwarethread, aber im Zusammenhang der Längswiderstände: Mit denen verringert sich die Spannung am ADC und der Vorteiler kann im Ausgleich mehr draufgeben, eine Stufe unempfindlicher werden. Beides zusammen sorgt dafür, das der ADC wesentlich besser ausgesteuert wird, quasi perfekt statt vorher nur gut zur Hälfte. Die Darstellung wird deutlich feiner, weil die Software die Rohwerte nicht so aufzoomen muß. Leider beginnt im neu erreichten Aussteuerbereich bereits die Sättigung der letzten Ausgangsstufe, die wird dort etwas nichtlinear. (Müßte in der FFT-Darstellung gut als K3 zu sehen sein.) Um das zu vermeiden kann laut Branadic die Versorgungsspannung des letzten OpAmp von 3,3V auf 5V umgeändert werden. Das hat aber noch keiner ausprobiert. Scheint zusammen mit Längswiderständen eine sinnvolle Modifikation zu sein. Jörg
Damit das hier nicht zu offtopic wird habe ich das mal in den Hardwarethread umgebogen: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"
Kleine aber feine Info über die Tests mit dem OSOZ Triger-API in der BF-Firmware: Ich habe jetzt den Pulsweitentrigger überreden können in allen drei Betriebsarten zu arbeiten: - Trigger wenn die Pulsbreite kleiner als der Schwellwert - Trigger wenn die Pulsbreite größer als der Schwellwert - Trigger wenn die Pulsbreite zwischen zwei Schwellwerten Das funktioniert tatsächlich ganz gut. Ich war selbst überascht. Wahrscheinlich haben die Jungs von WELEC das selber noch nie funktionierend gesehen. Ihr seht schon, die nächste Firmwareversion hat dank der Arbeiten an OSOZ einiges an Verbesserungen zu bieten. Gruß Hayo
Und da ist sie auch schon. Da sich ziemlich viel getan hat, habe ich die Firmware auf die nächste Major-Version gebracht. Die Änderungen am Triggerinterface sind so umfangreich, dass man vom alten Coding kaum noch was wiederfindet. Der Einbau des OSOZ Trigger-API hat den Vorteil, das man Erkenntnisse aus Tests sowohl aus der einen als auch der anderen Richtung sofort in das jeweils andere Coding übernehmen kann. In Kürze die Änderungen: - OSOZ-Trigger-API - neuer Triggermodus "Free Run" - Pulsweitentrigger funktioniert jetzt in allen drei Bereichen - Alle Triggermodes sind jetzt auch für den Pulsweitentrigger verfügbar Gruß Hayo p.s. Holdoff ist zum Teil getestet und scheint ganz anständig zu funktionieren. Detailiertere Tests folgen noch.
moin Hayo, war gerade am Rechner und habe das Welec angestöppselt, dann die 6.0 in 10sek. aufgespielt... Nach dem Neustart und Default Setup, ist im Edge-Modus kein Triggerlevel einstellbar! Nach einiger Sucherei, hatte ich den Übeltäter! Der Source-Button war quasi leer!? Ein Haken steht unter Source, keine Quelle. Als Source dann Kanal eins angewählt und es triggert. Nur mal so zur Info! Gruß Michael
Danke für die Info, den Effekt hatte ich bei mir auch, nur dachte ich, dass das durch die Testerei passiert ist. Ich schau mal nach wo das herkommt. Also an Alle: Nach dem Update die Trigger Source neu einstellen! Please setup the trigger source after updating Your firmware! There is a little failure which deletes the correct entry. Hayo
Im Puls-Width Modus ist alles hübsch soweit, da funktioniert der Trigger-Level nach dem Update! Irgendwie komme ich mit dem Free run-Modus nicht klar, was bedeutet das denn? Im Free run-Mode, hat der Trigger-Level keine Wirkung auf das Signal... Gruß Michael
Ok Fehler gefunden und behoben. Im Default Setup wurde das Menü falsch vorbelegt. @ Michael Free Run heißt zu gut Deutsch -> Trigger ausgeschaltet. Daher auch keine Reaktion auf den Level. Das DSO wartet also nicht bis zum nächsten Ereignis, sondern liest sofort die neue Dataline ein. Deswegen sieht das Signal dann so unruhig aus. p.s. Mist falsche readme erwischt - die zweite ist die aktuelle
@Hayo > Im Default Setup wurde das Menü falsch vorbelegt. Wenn man es weiß, passt das ja. Sonst hast du nix geändert? > @ Michael > Free Run heißt zu gut Deutsch -> Trigger ausgeschaltet. Daher auch keine > Reaktion auf den Level. Das DSO wartet also nicht bis zum nächsten > Ereignis, sondern liest sofort die neue Dataline ein. Deswegen sieht das > Signal dann so unruhig aus. Mit anderen Worten, kann man das Signal nur im Stop bzw. im Single-Modus betrachten? Ich habe das gerade mal getestet, im Single-Modus bleibt das Signal nach jedem drücken, schön auf der selben Stelle! Das finde ich jetzt praktisch. Gruß Michael
Michael D. schrieb: > Sonst hast du nix geändert? Zur ersten Compilation nicht. Ich habe außer den besagten Änderungen auch wieder weiter in den Variablen aufgeräumt. Heißt überflüssige nicht benutzte Variablen gelöscht, kontextabhängige Variablen als Attribute in die entsprechenden Klassen verschoben und sinnig neu benannt. Nebenbei gehe ich dann immer noch durch und tausche numerische Array-Indices gegen sprechende Defines oder Enumeratoren. Und bei letzterem ist mir einfach das falsche Define in das Menü geraten. Vielleicht sollte ich nicht immer bis früh morgens programmieren, da bleibt irgendwann die Konzentration auf der Strecke... Hayo
Hayo W. schrieb: > Vielleicht sollte ich > nicht immer bis früh morgens programmieren, da bleibt irgendwann die > Konzentration auf der Strecke... Außerdem gibt das auf die Dauer nur Stress mit der besten ... ;-) Grüße, Guido
Die nutzt die Gelegenheit und guckt Frauensendungen bis der Arzt kommt... ;-)
Hayo W. schrieb: > Die nutzt die Gelegenheit und guckt Frauensendungen bis der Arzt > kommt... Vielleicht sollte sie dann mal eine Arztserie gucken? ;-) Zum Oszi: ist der Trigger jetzt für Osoz aktuell eingecheckt? Ich hätte da noch Fragen: - Es gibt 2 Funktionen, die am SPI drehen, namentlich CaptureTrigSetExtSource() und CaptureTrigSetExtCoupling(). Die gehören nicht in den Capture-Treiber, der soll sich nur mit dem FPGA beschäftigen. Ich hatte in trigger.c bereits TiggerSetExtSrc() und TiggerSetExtCoupling() vorgesehen. Da ist auch bereits Code, ist der in Ordnung? Ich hatte auch bereits den TV-Trigger vorgesehen. - Du hast die "magischen Registerwerte" für ctrl und adc_ctrl verändert, wie kamst du darauf, klappt das auch noch mit einem 2Kanäler? Mußte man da nicht was aus dem Protected Flash auslesen oder die FPGA-Version heranziehen, um die korrekten Werte einzustellen? Ich meine das hatte ich noch nicht fertig. Geht das auch ohne, machst du das in deiner BF-Firmware nun auch so? Jörg
Jörg H. schrieb: > Hayo W. schrieb: >> Die nutzt die Gelegenheit und guckt Frauensendungen bis der Arzt >> kommt... > > Vielleicht sollte sie dann mal eine Arztserie gucken? ;-) Die sind ihr auch zu doof... > Zum Oszi: ist der Trigger jetzt für Osoz aktuell eingecheckt? Ich hätte > da noch Fragen: Nicht ganz, einige Kleinigkeiten sind noch offen, siehe unten... > beschäftigen. Ich hatte in trigger.c bereits TiggerSetExtSrc() und > TiggerSetExtCoupling() vorgesehen. Da ist auch bereits Code, ist der in > Ordnung? Ich hatte auch bereits den TV-Trigger vorgesehen. Aah, das war der Hinweis den ich brauchte. Baue ich natürlich noch ein. Beim TV-Trigger habe ich das Problem, dass ich nicht genau weiß was der eigentlich machen soll, da mir die Anforderungen eines Fernsehtechnikers unbekannt sind. Grundsätzlich soll der ja wohl irgendwie auf das jeweilige Syncsignal (hor. / vert.) triggern. Mir fehlen da aber Details. Ich weiß auch nicht ob das von unserer Hardware unterstützt wird. Irgendeinen Sync-Interupt gab es ja glaube ich. Dazu kommt, dass das eine aussterbende Technik ist. Bei uns z.B. gibt es keinen einzigen Röhren-TV mehr. > - Du hast die "magischen Registerwerte" für ctrl und adc_ctrl verändert, > wie kamst du darauf, klappt das auch noch mit einem 2Kanäler? Alles durch Ausprobieren. Natürlich immer für beide Versionen, deshalb hab ich ja auch den "DSO-Stack" auf meinem Tisch stehen. Außerdem wurden die Registerwerte in der alten FW auch noch direkt während des Schreibens verändert ohne das diese Werte in den Shadow zurückgeschrieben wurden. D.h. die angezeigten Werte waren nicht die tatsächlich eingestellten Werte! >Mußte man > da nicht was aus dem Protected Flash auslesen oder die FPGA-Version > heranziehen, um die korrekten Werte einzustellen? Nein, nicht bei diesen Registern. Das sind channel_Adr und adc_change. Die werden aus dem Protected Flash gezogen. > Ich meine das hatte > ich noch nicht fertig. Geht das auch ohne, machst du das in deiner > BF-Firmware nun auch so? Die Triggerregister werden in beiden Firmwareversionen identisch gesetzt. Das API ist genau das Gleiche. Die beiden ADC-Steuerregister hattest Du mit Defaultwerten vorbelegt. Eine Flashleseroutine habe ich nicht gebaut, das müßte noch gemacht werden. Soll ich da irgendwie tätig werden? Die Trigger-Register werden bei mir vor jedem Einstellvorgang auf einen Initialwert gesetzt und dann mit dem API richtig eingestellt. Dafür fehlt eigentlich noch eine entsprechende Funktion im API (CaptureTrigPrepare() oder CaptureTrigReset() oder so ähnlich). Die CaptureInit() ist dafür nicht geeignet da hier alle Register initialisiert werden. Hayo
> Die Trigger-Register werden bei mir vor jedem Einstellvorgang auf einen > Initialwert gesetzt und dann mit dem API richtig eingestellt. Ich habe noch mal einige Tests gemacht, und festgestellt, das die Initialisierung vor jedem Einstellvorgang nicht notwendig ist. Diese hatte ich am Anfang eingeführt um immer eine saubere Ausgangssituation zu haben. Das API scheint aber so konsistent zu sein das nur beim Systemstart einmal initialisiert werden muß. Eine Prepare() Funktion ist damit also überflüssig. Hayo
Hayo W. schrieb: > Beim TV-Trigger habe ich das Problem, dass ich nicht genau weiß was der > eigentlich machen soll, da mir die Anforderungen eines Fernsehtechnikers > unbekannt sind. Grundsätzlich soll der ja wohl irgendwie auf das > jeweilige Syncsignal (hor. / vert.) triggern. Mir fehlen da aber > Details. Ich weiß auch nicht ob das von unserer Hardware unterstützt > wird. Irgendeinen Sync-Interupt gab es ja glaube ich. Im Welec ist sogar ein extra Chip für den TV-Trigger. Insofern fände ich es schade, das brachliegen zu lassen. Ich hatte da mal ein Stück weit verfolgt. Dieser Sync-Separator ist an Kanal 1 angeschlossen. Alle TV-Optionen machen also nur dort Sinn. Mit den SPI-Bits wird ein Mux gesteuert, der die externe Triggerquelle umschaltet. In Software muß man also wenig tun, nur diesen Mux bedienen. (Ein zukünftiges FPGA-Design könnte noch die gewünschte Zeile auszählen und dann erst triggern...) > Dazu kommt, dass > das eine aussterbende Technik ist. Bei uns z.B. gibt es keinen einzigen > Röhren-TV mehr. Auch eure Flachbildschirme können mit einem FBAS-Signal umgehen... ;-) Seit einiger Zeit ist es beliebt, mit Microcontrollern durch Bitbanging ein Fernsehsignal zu erzeugen, um so z.B. günstig ein Display zu haben. Gibt's diverse Postings zu, hier im Forum. Auch von daher finde ich das nicht ausgestorben. >>Mußte man >> da nicht was aus dem Protected Flash auslesen oder die FPGA-Version >> heranziehen, um die korrekten Werte einzustellen? > > Die Triggerregister werden in beiden Firmwareversionen identisch > gesetzt. Das API ist genau das Gleiche. Die beiden ADC-Steuerregister > hattest Du mit Defaultwerten vorbelegt. Eine Flashleseroutine habe ich > nicht gebaut, das müßte noch gemacht werden. Soll ich da irgendwie tätig > werden? Sehr gern. Das Flash ist ja direkt lesbar, also braucht es da keine großartige API, einfach einen Zeiger aufsetzen und los. Jörg
Jörg H. schrieb: > Sehr gern. Das Flash ist ja direkt lesbar, also braucht es da keine > großartige API, einfach einen Zeiger aufsetzen und los. PS: Wenn's netter ausschauen soll, mit FlashSectorGetAddr() holen.
Nett aussehen soll es ja auf jeden Fall...
Bin gerade dabei das API zu überarbeiten und stelle erst jetzt fest, dass ja das API für den externen Trigger schon komplett fertig in trigger.c enthalten ist. Ich schmeiße das also aus capture.c wieder raus und passe auch das API in der BF Firmware an damit die Ergebnisse reproduzierbar sind. Ist in Arbeit...
Hallo, habe heute gerade mein W2022A auf die neue Firmware aktualisiert. Wenn ich mit dem w200a-screenshot Tool probiere auf das Oszi zuzugreifen bekomme ich folgende Meldung:
1 | * Connecting to DSO and retrieving version information... done |
2 | w2000a-screenshot: This version needs at least firmware version 2.20, but you've got 0.0. |
3 | Please update your DSO. |
Außerdem habe ich noch folgende Probleme: CH1: Auf 1:1 eingestellt (Tastkopf auch): Sobald ich die Skalierung auf größer 1V/div Stelle bekomme ich kein Signal mehr. Normal oder habe ich es irgendwie geschafft den Eingangsverstärker oder so zu schießen? Bei Tastkopf 10:1 ergibt sich das selbe ab Skalierung 10V/div. CH2: Sobald ich einen Offset einstelle (Position der Waveform am Bildschirm) und Teile des Signals liegen in der oberen Hälfte zeigt das Oszi starke Spitzen bzw einen dicken grünen Balken für die Signalteile, unabhängig von der eingestellten Skalierung. Ist dies normal? Danke, Stefan
Hallo Stefan, Stefan S. schrieb: > CH1: Auf 1:1 eingestellt (Tastkopf auch): Sobald ich die Skalierung auf > größer 1V/div Stelle bekomme ich kein Signal mehr. Normal oder habe ich > es irgendwie geschafft den Eingangsverstärker oder so zu schießen? Bei > Tastkopf 10:1 ergibt sich das selbe ab Skalierung 10V/div. Das beschriebene Verhalten habe ich auf meinem Gerät nicht! Ich habe zusätzlich noch einen Test beim Kanal 2 durchgeführt .... auch da kann ich Deinen Fehler nicht reproduzieren. Probier noch einmal "Utility", "Default Setup" ... Gruß Andi
Hallo Stefan, mein Screenshot funktioniert einwandfrei. Hast Du als Destination "PC" gewählt? Auch die anderen Probleme treten bei meinen Geräten nicht auf. Wie Andi schon sagt Default Setup machen. Bzw. vielleicht die Firmware nochmal flashen. Gruß Hayo
Angehängte Dateien:
-
ch1_2v.jpg
86 KB -
ch1_5v.jpg
85 KB -
ch1_10v.jpg
85 KB -
ch2_5v.jpg
83 KB -
ch2_5v_offset.jpg
84 KB -
ch2_5v_more_offset.jpg
86 KB -
ch2_offset_persist.jpg
60 KB
Hallo, Default Setup und Firmware nochmals flashen haben nichts gebracht. Im Anhang noch ein paar Bildchen. Stefan
Angehängte Dateien:
-
ch2_10ns.jpg
80 KB
Hallo, also das Problem auf Channel 2 tritt nur auf bei einer Timebase kleiner 10us. Bei 10us ist alles o.k. doch sobald ich auf 5us drehe kommen die Störungen. Hier noch ein Bild der Spitzen bei 10ns Timebase. Bei CH1 hört man ein Relais umschalten wenn ich bei 1:1 von 500mV auf 1V schalte. Bei 500mV sehe ich noch was bei 1V nichts mehr. Da scheint es mir irgendwas intern zerstört zu haben. Komisch da ich bis jetzt nur an 5V uC-Schaltungen / FPGA gemessen habe und eigentlich immer mit 10:1 Tastkopf.... Hatte das Oszi lange nicht im Betrieb und jetzt diese Probleme. Hoffe jemand von euch kann mit weiter helfen. Danke, Stefan
Stefan: die Spitzen sehen mir aus wie die berüchtigten Spikes, Datenübernamefehler intern im FPGA wegen zu agressivem Timing, sprich schlechtem Design. Bessert sich das wieder, wenn du auf die ältere Software zurückgehst? Hayo: wird das vielleicht mit dem neuen Code forciert, weil die magischen Register nicht so stehen wie vorher? Jörg
Hallo Jörg, In der Zwischenzeit habe ich mich größtenteils durch die Welec Threads hier gekämpft. Ich habe mein Scope jetzt auseinandergenommen und die RAM und ADC Bausteine nachgelötet. Nach dem Zusammenbau sind die Probleme von Kanal 2 verschwunden. Juhu. Für Kanal 1 werde ich in den nächsten Tagen mal das Scope wieder auseinander nehmen und unter der Abschirmung nachschauen was es mir da zerstört hat. Danke, Stefan
War wieder fleißig gestern nacht und heute. Die neue Version enthält das OSOZ API für den externen Trigger und den TV-Trigger. Angeregt durch Jörgs Hinweise habe ich den TV-Trgger auch gleich implementiert und getestet. Das Sync-Signal liegt an Kanal 1 an. Ich habe mit einem 15.6 KHz Rechtecksignal getestet (was ungefähr dem Vertikalsync entspricht). Der externe Triggerlevel muß einen positiven Wert haben, dann triggert es. Scheint soweit also tatsächlich zu funktionieren. Detailiertere Tests müßte man an einem echten Syncsignal vornehmen. Gruß Hayo
Hallo Hayo, mal kurz zwischendurch, ein kleiner Vorschlag... Wäre es sinnvoll den Noise-Filtern statt den Namen: Smooth, Strong, usw... vielleicht in die Grenzfrequenzen umzubennen? Z.B. 20MHz, 30MHz... oder cut-20MHz, cut-30MHz... fände ich etwas informativer. Gruß Michael EDIT: Zusätzlich vielleicht noch ein kleines Info-Fenster oben in der Leiste, welcher Filter gerade aktiv ist...
komisch ist die Sache mit den Spikes aber trotzdem. Bin ja scheinbar nicht der einzige bei dem das jetzt auf einmal verstärkt bzw. überhaupt auftaucht. Zwar konnten wir die Sache auf einen Temperatureinfluss zurückführen (siehe Hardware Thread) (unter 10°C gibts wohl bei allen Geräten die Spikes?), allerdings habe ich die Spikes definitv jetzt auch bei etwas niedrigeren Raumtemperaturen direkt nach dem Einschalten, wo sie früher nicht vorhanden waren. Unabhängig auch wenn ich eine alte FW aufspiele. @sar: kannst du das Spike Problem nach deiner Lötaktion auch bei niedrigeren Temperaturen als erledigt bezeichnen? Hast du mit Heissluft oder mit dem Lötkolben nachgelötet? Fast ein Hardware Beitrag geworden, sorry.
@ben: Ich habe mit Heißluft gelötet. Werde mal schauen ob ich das Oszi an die frische Luft für einen Test bewegen kann.
@Michael Du willst aber auch wieder alles... ;-) Das Problem bei der Benennung ist, dass mir nichts wirklich Sinnvolles eingefallen ist. Die Grenzfrequenz beim Smooth-Filter ist die halbe Abtastfrequenz, da dieser verlustfrei arbeitet mit den ungenutzten Werten zwischen den angezeigten Punkten. Der Strong Filter liegt da etwas niedriger, ist aber auch abhängig von der eingestellten Abtastrate und der Anzahl der Punkte die zwischen der angezeigten Abtastung liegen. Du siehst also - nicht so einfach. Gute Ideen sind aber willkommen und fließen auch sofort in die Firmware ein. Also macht weitere Vorschläge... Übrigens - in der Leiste ist kein Platz mehr, die ist schon voll. Jedenfalls bei den 4 Kanalern. @Ben Mir war es nie aufgefallen, weil meine DSOs immer den ganzen Tag lang laufen wenn ich programmiere und teste. Die sind also immer auf Temperatur. Geht evtl. einigen Anderen ähnlich. Ich habe es erst gemerkt als ich wegen des Hinweises meine Büchse mal bei niedrigen Temperaturen auf der Terrasse angemacht habe. Da war ich echt erstaunt. Das Problem gab es aber wahrscheinlich schon von Anfang an. Falls die Lötaktion tatsächlich Abhilfe geschaffen hat wäre das natürlich eine Maßnahme um dem zu Leibe zu rücken. Gruß Hayo
Hayo W. schrieb: > Gute Ideen sind aber willkommen und > fließen auch sofort in die Firmware ein. Also macht weitere > Vorschläge... kein Problem, hier ist ein SEHR guter Vorschlag: bei Buttons die den 'Wert' mit anzeigen nervt (zumindest mich) das 'popup' extrem, i denk das koennte man doch abschalten. Z.B. bei Coupling steht DC , mochte ich auf AC umschalten druecke ich den Button, dann ein popup, und dann nochmal druecken um auf AC zu schalten, ohne Popup waehre es nur ein Tastendruck und auch von der zeit her schneller, unn was meist du dazu ? vlG Charly
@Hayo > Du willst aber auch wieder alles... ;-) Selbstverständlich! ;-) Ich habe hier noch ein Voltcraft 3062C. Dies war eigentlich als 60MHz gedacht, kann jetzt aber durch einen Hack um die 200MHz. Da drin werkelt ein Hantek-Board, welches ursprünglich für diese Bandbreite gedacht war. Wie auch immer, im Moment kann man nur einen Filter von 20MHz setzen, was aber praktischer Weise auch auf dem Display angezeigt wird, daher kam mir diese Idee. > Das Problem bei der Benennung ist, dass mir nichts wirklich Sinnvolles > eingefallen ist. Die Grenzfrequenz beim Smooth-Filter ist die halbe > Abtastfrequenz, da dieser verlustfrei arbeitet mit den ungenutzten > Werten zwischen den angezeigten Punkten. Das wäre doch schon mal ein Anhaltspunkt!? > Der Strong Filter liegt da > etwas niedriger, ist aber auch abhängig von der eingestellten Abtastrate > und der Anzahl der Punkte die zwischen der angezeigten Abtastung liegen. Der Strong Filter bügelt ja quasi alles weg. Irgendwo war doch mal eine Liste der Grenzfrequenzen, die auch u.a. IIR 1-3 Stage beschreiben, oder? Ich finde die leider nicht mehr. > Du siehst also - nicht so einfach. Gute Ideen sind aber willkommen und > fließen auch sofort in die Firmware ein. Also macht weitere > Vorschläge... > Übrigens - in der Leiste ist kein Platz mehr, die ist schon voll. > Jedenfalls bei den 4 Kanalern. Ja, eben. Jetzt könnten die 2Kanaler ja egoistisch sein...kann man da nicht noch etwas rücken? Oder, wie sieht es denn rechts oder links, neben dem Grit aus? Könnte ja auch mit den Cursern bzw. mit der Nullinie mit wandern, oder... Vielleicht hat ja noch jemand einen guten Vorschlag? @Charly mich nervt das auch ein wenig. Leider hat das Gerät auch keine Drehgeber mit Drucktaster, da wäre es einfacher. Nur wo willst du dann mit der GND-Option hin? 3x drücken, müßte man ja trotzdem Gruß Michael
@Michael einmal druecken = um eins weiterschalten, warum eigentlich einmal druecken um das popup zu oeffnen und dann nochmal druecken um eins weiterzuschalten ? vlG Charly
@Charly Ich verstehe schon was Du meinst. Bei meinen alten Analog-Oszis ist das auch bequemer, aber da steht auch auf dem Panel dran was der Knopf macht. Bei dem Bedienkonzept der modernen Oszis wird aber Platz auf der Front gespart, indem eine Menügesteuerte Bedienung eingesetzt wird. Da hat man aber nicht die Möglichkeit die Bedienoptionen eines Knopfes auf dem Panel unterzubringen, sondern muß das irgendwie als Popup umsetzen oder bei weniger Optionen gäbe es die Möglichkeit in der ersten Zeile des Knopfes die Optionen anzuzeigen, und in der zweiten Zeile ein Symbol für die Auswahl (so wie beim Pulsweitentrigger der < > >< Knopf). Bei AC DC GND wird es aber schon ganz schön eng in der ersten Zeile. Weitere Möglichkeit wäre, das nicht das Popup mit der aktuellen Einstellung aufpopt, sondern gleich beim Drücken einen weiter springt und die neue Einstellung anzeigt, dann wäre kein weiterer Druck mehr nötig. @Michael Die Liste mit den Frequenzen findest Du in dem "Docs" Verzeichnis in der Datei "Special Functions". > Ich habe hier noch ein Voltcraft 3062C. Dies war eigentlich als 60MHz > gedacht, kann jetzt aber durch einen Hack um die 200MHz. Ja ich hatte davon in einem Forum gelesen. Und? Bist Du mit dem Gerät zufrieden? Wie ist die Benutzerführung/Bedienbarkeit? (ist etwas offtopic hier, aber evtl. kann man ja gute Umsetzungen in unsere Firmware übernehmen). Ich habe ja auch ein Vergleichsgerät von den China Boys hier bei mir, Das OWON SDS8102. Technisch ist das Gerät unserem ziemlich überlegen, aber die Bedienung und die Spezialfunktionen sind nicht so gut Revision von mir gibt es hier: Beitrag "WELEC W2000A vs. OWON SDS8102" ...aber die kennst Du glaube ich schon. Wieder zurück zum Filter. > Wie auch immer, im Moment kann man nur einen Filter von 20MHz setzen, Ja das ist Standard, und das hat unseres auch, das ist die "BW Limit" Option. Das ist aber ein Hardwarefilter, das eigentlich die meisten Oszis haben. Damit kriegt man aber nicht das ADC-Rauschen oder intern erzeugte Spikes weg. Die Filter die ich da eingebaut habe sind Softwarefilter, die erst nach der ADC-Wandlung greifen und daher auch interne Einflüsse glattbügeln. Sowas haben nur wenige Oszis im Angebot. > Oder, wie sieht es denn rechts oder links, neben dem Grit aus? > Könnte ja auch mit den Cursern bzw. mit der Nullinie > mit wandern, oder... Hmm, da wäre ich eher dafür das in der Gridfarbe in der oberen linken oder rechten Ecke im Grid selbst einzublenden. Das Signal würde dann einfach drüberliegen wenn es denn mal in die Ecke käme, was aber eher nicht die Regel ist. Wäre das eine Option? Gruß Hayo
@Hayo > Die Liste mit den Frequenzen findest Du in dem "Docs" Verzeichnis in der > Datei "Special Functions". Ups, sollte da doch öfter mal vorbei schauen... >> Ich habe hier noch ein Voltcraft 3062C. Dies war eigentlich als 60MHz >> gedacht, kann jetzt aber durch einen Hack um die 200MHz. > Ja ich hatte davon in einem Forum gelesen. Und? Bist Du mit dem Gerät > zufrieden? Ich bin damit "soweit" zufrieden, weil es ziehmlich schnell ist. Z.B. Beim einblenden von Measure(wird eingeblendet rechts vom Display), was bei uns "Quick Measure" ist, gibt es keine Geschwindigkeitseinbuse, egal ob ein oder zwei Kanäle eingeschaltet sind, da lahmt ja schon das Welec. Der Bildschirm ist riesig und es passt natürlich jede Menge drauf, die Auflösung ist 800x480 Pixel. Noch ein großer Vorteil ist eine USB-Schnittstelle und ein USB-Slot für Speichersticks. Auf die Sticks kann man bequem Screenshots speichern und über diese werden auch Software-Updates auf das DSO gespielt, also ist man nicht vom PC abhängig. Das war mal ein kleiner Auszug. Um etwas mehr darüber zu erfahren müsstest du mal in diese Threads schauen, die auch schon eine beachtliche länge erreicht haben: Beitrag "VOLTCRAFT DSO-3062C 60 MHz = baugleich mit?" Beitrag "TEKWAY DST1xx2B Oszilloskop" Natürlich wird auch dort das Eine oder Andere schlecht geredet, man hat eben keine Eierlegende Wollmilchsau und für den Preis, ist das Voltcraft völlich in Ordnung! > Wie ist die Benutzerführung/Bedienbarkeit? (ist etwas > offtopic hier, aber evtl. kann man ja gute Umsetzungen in unsere > Firmware übernehmen). Eben, warum denn nicht? Der Vorteil von der Bediehnbarkeit her ist, das "fast" alle Drehgeber, Drucktaster besitzen, da ist das Einstellungsziehl schneller erreicht. Ansonsten hat das Teil so viele Funktionen und um diese zu erreichen, muß man sich natürlich auch etwas durch die Menus und deren Untermenus rangeln. Ansonsten hat man es mit etwas Übung schnell raus. Manchmal erwische ich mich dabei beim Welec auf den Knöppen herum zu drücken, wie doof ist das denn? Ich habe ja auch ein Vergleichsgerät von den China > Boys hier bei mir, Das OWON SDS8102. Technisch ist das Gerät unserem > ziemlich überlegen, aber die Bedienung und die Spezialfunktionen sind > nicht so gut Revision von mir gibt es hier: > Beitrag "WELEC W2000A vs. OWON SDS8102" > ...aber die kennst Du glaube ich schon. Ja, ist aber auch schon eine Weile her und wieder in Vergessenheit geraten. Ich hatte tatsächlich mal mit dem Gedanken gespielt, mir ein Exemplar zuzulegen. Ich hatte das wieder verworfen, da mir das Angebot von Voltcraft in die Quere kam. Ich hätte es nie erstanden, wären die oben angegebeben Threads nicht gewesen! > Wieder zurück zum Filter. >> Wie auch immer, im Moment kann man nur einen Filter von 20MHz setzen, > Ja das ist Standard, und das hat unseres auch, das ist die "BW Limit" > Option. Das ist aber ein Hardwarefilter, das eigentlich die meisten > Oszis haben. Du Schande, ich wußte bisher nichts damit anzufangen, dabei ist die Definition ja eindeutig: Bandbreitenbegrenzung? > Damit kriegt man aber nicht das ADC-Rauschen oder intern erzeugte Spikes > weg. Die Filter die ich da eingebaut habe sind Softwarefilter, die erst > nach der ADC-Wandlung greifen und daher auch interne Einflüsse > glattbügeln. Genau! Das Voltcraft/Hantek/Tekway, haben ebenfalls diese Softwarefilter, sind aber leider ohne Funktion! Mich stört das ein wenig, wenn ich beim messen, diverse Überlagerungen wegfiltern möchte. Da punktet dann das Welec! Da kann ich Einiges platt machen und mich später um die HF-Störungen kümmern... > Sowas haben nur wenige Oszis im Angebot. >> Oder, wie sieht es denn rechts oder links, neben dem Grit aus? >> Könnte ja auch mit den Cursern bzw. mit der Nullinie >> mit wandern, oder... > Hmm, da wäre ich eher dafür das in der Gridfarbe in der oberen linken > oder rechten Ecke im Grid selbst einzublenden. Das Signal würde dann > einfach drüberliegen wenn es denn mal in die Ecke käme, was aber eher > nicht die Regel ist. Wäre das eine Option? Allerdings! Sowas in der Richtung dachte ich mir erst auch, der Platz wird eh kaum benutzt. Ich bin schon auf deine Umsetzung gespannt! Du weißt ja, für einen User gibt es nichts schöneres, als ein Update mit neuen Funktionen!!! Gruß Michael
Ist schon in Arbeit, die ersten Versuche sehen ganz nett aus. Leider habe ich den Rest der Woche eine Schulung bei der ich der Referent bin. Da bin ich Abends immer ziemlich platt - mal sehen ob ich da noch Lust habe mich dranzusetzen. Ansonsten am Wochenende. Hayo
Angehängte Dateien:
-
OnScreenStatus01.jpeg
48 KB
Hier schon mal eine kleine Kostprobe. Der OnScreen Status ist natürlich im Display Menü abschaltbar. Hayo
na, das ist ja mal was! Durch den quasi "Hologramm" Effekt, wirkt sich das nicht störend auf das Grid aus. Da könnte man ja noch reichlich Infos einblenden, bei Bedarf! Was wäre denn noch so relevant? Sieht schon mal gut aus!!! Gruß Michael
Hayo W. schrieb: > sondern gleich beim Drücken einen weiter springt > und die neue Einstellung anzeigt, dann wäre kein weiterer Druck mehr > nötig. Genau so meine ich das, sowas waehre super, und dann wenn machbar noch als kleine 'luxuserweiterung' ein druck wechselt zw AC & DC und ein langer druck zb. > 1s schaltet auf GND ich meine das Agilent machte das so vlG Charly
So, nachdem ich mich den ganzen Tag mit Programmieranfängern rumschlagen mußte habe ich mich mal rangesetzt und ein paar entspannte Zeilen reingehämmert. Hier eine Beta zum Ausprobieren. 1. Der On Screen Status (OSS). Läßt sich im Display Sub-Menü anschalten. Der Zustand wird aber noch nicht im Flash gespeichert. Ist also beim nächsten Anschalten wieder aus. Auch sind die Texte noch an festen Positionen. Angedacht sind variable Slots, die immer linksbündig verschoben werden je nachdem was gerade angezeigt wird oder nicht. Bedient werden zur Zeit Logic Average Noise Filter 2. Der AC/DC Button. Auf Kanal 1 habe ich mal eine mögliche Lösung implementiert die eigentlich alle Bedürfnisse abdeckt. Langsames Einfachdrücken -> das bekannte Menü poppt hoch Schneller Doppeldruck -> es wird zwischen AC / DC hin und her geschaltet Probiert mal aus ob das Euren Vorstellungen entgegen kommt. Gruß Hayo
@Hayo dankeschoen!, wenn du jetzt das noch umdrehst/vertauscht wuerde ich es als PERFEKT ansehen also quasi so: Schneller Doppeldruck -> das bekannte Menü poppt hoch Langsames Einfachdrücken-> es wird zwischen AC / DC hin und her geschaltet denn man (ich) schaltet vieeeel oefter zw. ac & dc um als ich das popup mit GND brauche vlG Charly
Hahaha, das hatte ich mir gedacht. Hab ich auch im ersten Anlauf so gemacht, aber das Popup das dann beim Doppeldruck hochkommt läßt sich mit dem Doppeldruck nicht richtig bedienen. Ich kann mal versuchen ob ich da mit einem Hackentrick weiterkomme, kann aber nichts versprechen. Gruß Hayo
noch ein Vorschlag: (wenn besser realisierbar) kurzer druck wechselt AC/DC langer druck = GND ne Frage am Rande, wozu wird hier GND eigentlich noch gebrauch? bei meinem 'Analog-Oszi' brauch i es manchmal aber hier nie 2. was passiert bei GND ? wird da der Eingang wirklich auf GND geschaltet oder nur der Wert des AD Wandlers einfach durch $80 ersetzt ? vlG Charly
Charly B. schrieb: > ne Frage am Rande, wozu wird hier GND eigentlich noch > gebrauch? bei meinem 'Analog-Oszi' brauch i es manchmal > aber hier nie > 2. was passiert bei GND ? wird da der Eingang wirklich auf > GND geschaltet oder nur der Wert des AD Wandlers einfach > durch $80 ersetzt ? Üblicherweise ist diese Funktion dazu da das Rauschen der Eingangsstufe zu quantifizieren, nicht zuletzt auch für die Kalibration. Beim Welec und bei vielen anderen DSOs der unteren Preisklasse ist diese Funktion jedoch nicht in Hardware umgesetzt, sondern eine reine Softwaresache und damit eigentlich obsolet. Theoretisch könnte sie hier daher auch gelöscht werden, weil sie niemandem einen wirklichen Nutzen bringt. branadic
Danke branadic, das hatte ich vermutet, i denke Hayo kann 'das GND' weglassen vlG Charly
Leider hat branadic recht, schöner wäre ein Relais, welches den Eingang des ADC auf Masse schaltet. Leider ist das dem Geiz zum Opfer gefallen. Evtl. kann man das Signal für Tests einiger mathematischer Funktionen verwenden, da es halt die mathematisch exakte Nulllinie des ADC simuliert. Ansonsten ist der Nutzen in der Tat eher kosmetischer Natur. > noch ein Vorschlag: (wenn besser realisierbar) > kurzer druck wechselt AC/DC langer druck = GND Das mit dem Kurz oder Lang ist nicht so einfach, das kann man nur mit einem Timer realisieren. Da muß man dann einen Timer mit einer Zeitkonstante laden und in einer Interuptserviceroutine entsprechend reagieren. Unsere drei Timer sind aber schon für diverse Sachen in Benutzung. Andere Möglichkeit wäre ein Zeittakt, den Jörg für seinen Heartbeat-timer nutzt, den Vsync-Interrupt, den könnte man evtl. nutzen. Ist aber alles etwas aufwändiger. Ich schau mal... Hayo
Halo Hayo, saubere Arbeit, fällt kaum auf im Grid und stört keinesfalls! Gefällt mir sehr gut!!! Die Werte würde ich nicht nachrücken lassen, sondern auf einer festen Position belassen. Das geht mir schon beim Quickmeasure auf den Geist, das da die Einheiten immer herum wandern, nur dort geht es wohl nicht anders... Ich habe hier mal den Auszug der Cutoff-Frequenzen: - Smooth ca. 80-90 Mhz - Strong ca. 30 Mhz - IIR 1 Stage ca. 70-80Mhz - IIR 2 Stage ca. 35-40Mhz - IIR 3 Stage ca. 20MHhz mir würde es besser gefallen, nur die Frequenzen der Filter im Grit-Menu einzublenden. Das hat eine klare Aussage, finde ich! Was meint der Rest dazu? Gruß Michael EDIT: Wäre es nicht praktischer den BW-Limit Button in das Average Menu zu verschieben?
@Hayo i denk du sollst da nicht unnoetig energie reinstecken, mein vorschlag: lass Gnd und das popup weg und ein druck auf die Taste schaltet zw. AC und DC um, fertich vlG Charly
Die Cutoff-Frequenzen sind nur für Abtastrate 1GS/s richtig! Die Eckfrequenzen der Softwarefilter hängen natürlich immer von der Abtastfrequenz ab. Der Smoothfilter hat in allen langsameren Zeitbasen die Cutoff-Frequenz der halben virtuellen Abtastrate, da die tatsächliche Abtastrate viel höher ist und die ungenutzetn Samples für die Filterung benutzt werden. > Wäre es nicht praktischer den BW-Limit Button in das Average Menu > zu verschieben? Da passen keine 4 weiteren Buttons rein! Hayo
Charly B. schrieb: > mein vorschlag: lass Gnd und das popup weg und ein druck > auf die Taste schaltet zw. AC und DC um, fertich Ja ich glaube Du hast recht, das scheint das Praktischste zu sein. Hayo
Die "alte" Hardware kann nicht zwischen kurzem und langem Drücken unterscheiden, weil nur die eine Flanke gemeldet wird, der Status nicht abfragbar ist. So zumindest mein Forschungsstand. Die neue Nios II Hardware kann das "natürlich". ;-) Jörg
War ja klar :-) I'm looking forward... Hayo
Hier eine geänderte Version mit einfacher Druckfunktion. GND ist nicht mehr auswählbar. So wird es dann wohl auch bleiben. Hayo
Hi Hayo and guys all!
Apologize me for my lack in communication in recent months but
I was a bit busy.
Hayo, again thanks You very much for the free time You generously
provided to us and for this new firmware's version!!!
I downloaded your latest great job, the new 1.2.BF.6.2beta and I've
tried it a little.
Now I'm a bit hurry but in the week end I hope to let You know my
impression on it but I'd like to take this opportunity to say some
things about what I could see: of course as always this is only for
knowledge and no for criticism.
I noted that the graticule setting in the display menu doesn't work.
Only line is drawn on the screen, dotted never appeared or if it is in
its place I get some corruption on the line graticule.
Sometime even changing modality (entering FFT, X-Y or Delay for
instance) I get garbage on the screen expecially in graticule but
may be also on other things on the screen.
This I tested either W2022a and W2012a.
Hayo W. schrieb:
> GND ist nicht mehr auswählbar. So wird es dann wohl auch bleiben.
I understand GND flag is always been as a cosmetic function without
any functionality but I would have preferred it was not removed because
I often used it as a marker on the screen.
That is on my opinion.
As I have already had occasion to write now we can choose to show or
hide markers' line when Quick Measure are switched on, but I believe
that could be useful to have the cursors visible in Quick Measure.
Let me explain better.
I mean set the cursors in the Cursors screen, not necessarily
simultaneously Time and Voltage cursors but even only one type at a
time, then keep them fixed visible on the Quick Measure screen in order
to use them as reference.
I do not mean to have functioning cursors on the Quick Measure screen
(that already there is it and we know it can be switch on or off by
setting
in DISPLAY menu) but only set them in the Cursors screen and then
keep them visible on that of the Quick Measure.
Practically this would to superimpose some static marker on the Quick
Measure screen, not necessarily that they have to be adjustable when
on the Quick Measure screen.
Many DSOs allow it, for example the TDS220 do it, not Time and Voltage
cursors at same time but only one at a time but it is however useful in
my opinion.
In some occasion I happened to sacrifice one channel by putting it in
GND mode and using it as a marker on the screen in order to perform
some measures.
Okay, okay, I know there are other way to reach the same result hence
GND is not so indispensable, but IHMO for me would be better not to be
cleared it from the choices
Hayo thank You very much again, You are great: RESPECT!!!!!!!
Vielen Dank!
Mit freundlichen Grüßen,
Luc
P.S. Today, yesterday due the time ;-), my W2022a and W2012a "battled"
against some DSO (LeCroy and Tektronix) winning on them in the display
of an elusive short and fast signal.
The W2012a has achieved similar performance than a Wave Ace 224 by
LeCroy whch is a 200MHz bandwidth DSO, the W2022a was better than
the WaveAce 224.
The results were confirmed by a 500MHz bandwidth DPO by Tektronix,
where the W2022a showed the real shape of the signal that the WaveAce
224 and the W2012a could only do suppose.
* Vielen Dank an alle Unterstützer des Projekts Welec! *
* * * * R E S P E C T ! ! ! * * *
Hi Luc, as always I enjoyed reading Your precise description of Your analysis and tests :-) The grid problem is a "beta" bug and disappeared in the version 6.3 which is coming out soon. What to do with the GND function is - indeed - difficult to decide. Without it the handling is much faster and more pleasant but sometimes (I agree) it is a littlebit useful to have the ground line (which is created by writing ADC zero into the memory). I racked my brain to get a solution which fits all requirements - but without success. One Idea I got just in this moment. What about using the button as AC/DC switch only but offering the complete Menu with GND/AC/DC when turning the main wheel? Is that a suggestion? If You have a better idea - don't hesitate to tell us! Kind regards Hayo
@Hayo im 'Mode/Coupling' Menu koennte man auch die beiden ersten Tasten ohne 'popup' konfigurieren, dankeschoen! @Luc i use as Marker one of the Grid Lines, then you can switch off the not used Channel and you 'speedup' the Scope ;) best regards & vlG Charly
Hi, wenn jemand daran interessiert ist mein W2022A zu kaufen, dann biete ich es hier jetzt an. Es hat die oben beschriebenen Macken. Preisvorschläge bitte per PN. lg, Stefan
@all: Bevor ich das Scope verkaufe habe ich jetzt gerade nochmals die 1.3er orginal Firmware aufgespielt. Die oben beschrieben Spikes (Heißluft behob das Problem nur temporär) und auch die Probleme mit dem Kanal 1 sind mit der orginal FW nicht vorhanden! Hat mich gewundert, ist aber so. Gibt es noch irgendwas, was ich testen kann um auch die neue Firmware zu verwenden? Danke, Stefan
Hab ich das jetzt richtig verstanden? Mit der WELEC Gurken-FW hast Du zwar auch die Spikes, aber keine Probleme mit Kanal 1, während Du mit der BF-Firmware auf Kanal 1 Probleme hast? Gruß Hayo
Hallo Hayo, Die Spikes sind weg. Wegen Kanal 1 habe ich mich getäuscht. Da habe ich nur auf die angezeigte Kanal-Skalierung geachtet. Diese wird allerdings beim Umschalten 1:1 zu 10:1 nicht angepasst bei der orginal FW. Aber die Spikes sind weg und sind bis jetzt auch nicht wieder da. Stefan
Angehängte Dateien:
-
EXT_Trig_slope_high.png
4,8 KB -
EXT_Trig_slope_high.jpg
47 KB -
EXT_Trig_slope_low.jpg
47 KB -
ALT_TRIG.jpg
55 KB -
DELAYED.jpg
76 KB -
Spikes_when_two_trace.jpg
55 KB -
512_points.jpg
55 KB -
1024_points.jpg
55 KB -
2048_points.jpg
55 KB -
4096_points.jpg
55 KB -
Q-Measure.jpg
43 KB -
X-Y.jpg
47 KB -
HOLD_OFF.jpg
56 KB -
Delayed_.jpg
75 KB
Guten Abend Hayo, Charly B., Rainer W. und alle! Wie versprochen Hier ist eine kurze Anleitung, die neue Firmware 1.2.BF.6.2beta. I briefly tested it with my poor equipment, nothing exceptional, but I want to contribute. Because I'm a little dumb sadly I missed some of my screenshots, few in this occasion, so Rainer W. (rawi) not have to worry this time: they are only 13! ;-) I think I had better save screenshots directly from DSO instead of being stored in it and then sent to the computer, this because I saw some parameters were changed in values when I read them from the DSO in order to put them in the computer, strange thing but it is so (of course some parameters are missed in that way, for instance the HOLD OFF value, but that is normal). However doing so I tested memory function and it works fine! Due the fact my reference is a 150MHz bandwidth analog oscilloscope I tested my W2012a comparing it with the first, even if the Welec has the 24,9/150 ohm hardware modifications, so its bandwidth is now about 170MHz for what I could see. The W2012a also have all the hardware modifications on the trigger stage as they was described on this Forum. The W2012a DSO was set like follow: ADC SETUP: High Frequ PRE GAIN: 24,9/150 ohm DRAW MODE: Accurate ACQUIRE: Normal As always what will it to follow is only for knowledge and no for criticism. Said that, here the results. Pulse Trigger works fine in all setting (Normal, Auto, Combi). I tested it with my old and trusted Lyons Instruments pulse generator, I tried it quickly and seems to me there isn't any issue on it, RESPECT! EXT Trigger also works fine but I noticed something strange Using a sine wave in order to test it there are not problems when slope is changed, while using a pulse then changing slope have no effect if trigger level have not tuning. Tuning the trigger level fix the issue but however saving the waveforms in the DSO, after recalling them the sine ones are OK but pulse ones are shifted in respect with the trigger position on the top of the screen. I hope I was understandable. Please see screenshots "EXT Trig slope low" and "EXT Trig slope high". ALT TRIGGER, it works. However, the value in the top of the screen is strange: for instance I had trigger level set to 1,10V but when I switched to the ALT TRIGGER it became 50,4V, I don't know why and if this is normal or no, I emphasize it only as knowledge. Please see screenshot named "ALT TRIG". Using DELAYED screen, as well using "Pre Triffìgger Keep+follow", "Keep Value and "Trace Middle", get garbage on the waveforms at the trigger time expecially analyzing two waveforms, seems to me something related with the infamous "spikes problem". Same issue is present in MAIN screen using "Pre Triffìgger Keep+follow", "Keep Value and "Trace Middle", others configurations are OK. Seems to me setting "PRETRIGGER GRID MIDDLE" occasionally moves from the center of the grid and it is necessary to reset it. Please see screenshots "DELAYED" and "Spikes when two trace". FFT had some issues. The graticule had garbage(*) on it and this is known, but seems to me "div" and "fN" values change when choosing for 512, 1024, 2048 and 4096 points. 512 and 1024 points has not changed, but 2048 and 4096 they have their own values. Seems to me also scale factor changed setting 2048 and 4096 points but may be a consequently to other problems in this beta version. Good the rotary controls, of course 2048 and 4096 points slow down the screen refresh. Please look at the screenshots "512 points", "1024 points", "2048 points" and "4096 points". (*)Graticule issue also involves certain buttons, for instance sometimes FFT and X-Y become gray even if they can be activated by pushing their buttons. Perform reset do not fix grey buttons problem but only graticule and garbage on the screen. HOLD OFF seems to me it works great: RESPECT! As always the Quick Measure and the X-Y (**) mode they work like a charm. In reference to the precision attainable by the Quick Measure screen, please to look at the screenshot named "Q-Measure" (*) where you can see Quick Measure working on the output of my Lyons pulse generator setting for a 25Vpp pulse with a 10nS of rise time, 8nS of the fall time and 100nS width...RESPECT! (*) The time trigger position is wrong on the screenshot for the reason I anticipated when I wrote about the fact some parameters were changed in values when recalled from memory location, in real time it was right. (**)"X-Y" it show a 3,6MHz sine wave on X axis and a 44ns pulse repeated at 1MHz range on Y axis Sadly I was unable to verify the TV trigger, maybe next time ;-) And that's all, I hope I was understandable. @Charly B. You are right, thanks for the hint! Doing that way the DSO becomes speedy, me too sometimes use it. However for some kind of measures sometime I can't use that way because waveforms don't reach two lines on the graticule and sadly Volt/DIV aren't adjustable. Here is why I wrote in the past about the possibility to implement FINE/COARSE in the rotatory amplitude setting, thing it is pretty normal in analog oscilloscopes and some DSO(Tektronixs TDS2xx and TDS 1xxx family DSO have it, but this is another story. @Hayo (or somebody else which know the answer) I'm very dumb, I don't understand how to use "FREE RUN" trigger. Maybe elsewhere it was already explained but I can't find it. I would have more to say here and in the hardware thread, but sadly it's late now. Hayo thank you once again for the excellent work and the time devoted to us, as I also thank all those who are involved in the Welec project. Vielen Dank!!! Gruß Luc P.S. apologize me for my poor English, today even more bad than ever! I sent "EXT_Trig_slope_high.png" as error, sorry about that!
Stefan S. schrieb: > wenn jemand daran interessiert ist mein W2022A zu kaufen, dann biete ich > es hier jetzt an. Es hat die oben beschriebenen Macken. Bevor sich irgendwer über Spikes frustriert, wartet erstmal das Nios II Design ab. Mein Gerät ist mit dem Original-FPGA auch quasi unbrauchbar, bei den höheren Abtastraten kriege ich sogar Bildstörungen im LCD. Mit der neuen Hardware ist davon nichts zu sehen, die sonst unvermeidlichen Spikes sind auch weg. Das Originaldesign ist halt über-kritisch, vermutlich an diversen Stellen außerhalb des legalen Timings. Stay tuned... Jörg
@ Luc Thanks for testing so much and for reporting so detailed. I'm a little bit out of time, so let me say four things first: - the setting "High Frequ" in the hardware setup may fit some demands when measuring higher frequencies, but You have to disregard that spikes or other distortions may occur on the signal in some conditions. If You are measuring at lower Frequencies (< 10MHz) the factory setting is recommended. - Grid and drawing failures are only an beta problem and solved since BF.6.3 - FFT df/div are correct. Length 512 / 1024 both use full frequency range 0.5 * sample rate. Because of only 512 points available on screen the length 2048 uses 0.25 * sample rate and 4096 uses 0.125 * sample rate. So you can calculate by Your self which value is correct. - Trigger -> free run simply means trigger switched off. Data acquistion is running completely asynchronous as fast as it is possible without waiting until any event may occur. All other issues I have to check later Kind regards Hayo
Die neue BF.6.3 ist jetzt im SVN eingecheckt. Den Download hier bereite ich gerade vor. Die Switchlogik für Channel-Coupling habe ich so gelöst: 1 mal drücken wechselt sofort zwischen AC/DC. Mehrfaches Drücken bietet frei Auswahl im Popupmenü. Hoffe das findet Wohlwollen. Gruß Hayo
Ok wie versprochen die 6.3 zum download. Den neuen OnScreenStatus könnt ihr im Display-Submenü anschalten. Gruß Hayo
Beitrag #3042250 wurde von einem Moderator gelöscht.
Hallo Hayo, > Den neuen OnScreenStatus könnt > ihr im Display-Submenü anschalten. leider nicht, da du die 6.1 hier hochgeladen hast. Ich dachte schon, hätte einen an der Waffel und habe mir einen Wolf gedrückt, nix gefunden. Dann schaute ich in die FW-Info, da steht die 6.1 drin. Gruß Michael
Kann man den nicht sperren? Edit: Danke für das Löschen.
Guten Abend Hayo und all jene, die an dem Projekt beteiligt sind Welec! Hayo Sie wie immer schnell sein, so schnell, dass meine Antwort spät kam!:KLASSE!!! Hayo W. schrieb: >Die neue BF.6.3 ist jetzt im SVN eingecheckt. Den Download hier bereite >ich gerade vor. > >Die Switchlogik für Channel-Coupling habe ich so gelöst: > >1 mal drücken wechselt sofort zwischen AC/DC. Mehrfaches Drücken bietet >frei Auswahl im Popupmenü. Hoffe das findet Wohlwollen. klasse! :-) @Hayo about the new 1.2.BF.6.3 firmware release Hayo Vielen Dank für die unermüdliche Arbeit, dass Geschenke zu uns, Sie sehr freundlich: KLASSE!!! Ich laufe, es zu versuchen, nochmals vielen Dank! Vielen Dank!!! Gruß Luc
Was war das denn jetzt? Das war ja schnell gelöscht... Kann meine Aussage Jemand bestätigen?
Michael D. schrieb: > Hallo Hayo, > leider nicht, da du die 6.1 hier hochgeladen hast. Nein, das ist die 6.3, hab sie nochmal hier runtergeladen und geflasht. Im Utility-Menü kommt 6.3! Allerdings sehe ich gerade, dass die gepackten Dateien fehlen. Werd ich nochmal nachreichen. Was läuft da bei Dir schief? Gruß Hayo
Angehängte Dateien:
-
OnScreenStatus02.jpeg
44 KB
Wenn alles gut läuft sollte der Screen so aussehen! @Luc The Problem with Logic Analyser and QM should be solved now. If not, please contact me. @Michael Sag was, hast Du noch Probleme? Hayo
> Was läuft da bei Dir schief?
das ist ja interessant.
Ich habe den UCL-Ordner mit der schnelleren Übertragung in den Ordner
der 6.3 kopiert, dann das aktuelle Flash eingesetzt und es erschien in
der Info die 6.1 auch dessen Funktionen, also ohne OSS.
Jetzt habe ich den originalen Germsloader verwendet (der braucht ja um
Einiges länger), die Aktuelle 6.3 hinein kopiert und jetzt habe ich
plötzlich die richtige Version geladen, wie geht das denn?
Bevor ich los plärrte, hatte ich das noch mal mit der 6.2 getestet, die
auch geladen wurde. OSS konnte ich dort auch anwählen, allerdings noch
die Betaversion.
Verstehe ich jetzt nicht so ganz...
Gruß Michael
Das von Dir beschriebene Phänomen hatte ich auch - bei der Umstellung der Versionsnummer von 6.2beta auf 6.3. Dabei hatte ich nur die Versionsnummer geändert, sonst nichts. Nach dem Laden mit der normalen Flashdatei ging alles wieder. Ich dachte ich hätte mich im Verzeichnis geirrt. Sollte die UCL-Routine hier eine Macke haben? Jedenfalls ging es danach bei mir wieder ohne jegliche Beanstandung. Hat sonst noch jemand Probleme?
Ok, ich hab's rausgefunden! Die Endung im UCL-Verzeichnis heißt nicht "TomCat.flash" sondern "TomCat_flash.ucl" !!! Die Datei ist ja nur ganze 163kB groß!? Das heißt, ich muß die fette Flash gar nicht da rein kopieren! Na, jetzt bin ich schlauer. Wie habt ihr die denn so klein bekommen? Gruß Michael EDIT: Die Filter werden in MHz angezeigt, wie fein ist das denn? Sieht prima aus, du bist mein Held!!!
Michael D. schrieb: > Die Filter werden in MHz angezeigt, Und auch in KHz für die etwas langsameren TB. War ja Dein Vorschlag. Habe eine eigene Funktion geschrieben, die die Cutoff berechnet. :-) Was sagt Ihr zu der Lösung mit der AC/DC Umschaltung? Hayo
> Und auch in KHz für die etwas langsameren TB. War ja Dein Vorschlag. > Habe eine eigene Funktion geschrieben, die die Cutoff berechnet. Wie jetzt, da sind noch niedrigere Cutoff-Filter? Kannst du dazu noch was sagen? > :-) > Was sagt Ihr zu der Lösung mit der AC/DC Umschaltung? Optimaler geht's ja wohl nicht, da freut sich der Charly. BtW. mich hatte es jetzt nicht so gestört... Gruß Michael EDIT: Mit was hast du, (oder war es Jörg) denn jetzt das Flashfile komprimiert bzw. wo wird es wieder dekomprimiert?
Michael D. schrieb: > EDIT: Mit was hast du, (oder war es Jörg) denn jetzt das Flashfile > komprimiert bzw. wo wird es wieder dekomprimiert? Ich war's. Das Komprimieren passiert als Teil des Build nach dem Kompilieren, mit einem Tool namens "uclpack". Das ist zugegeben exotisch, aber komprimiert besser als zip und der Dekompressor ist sehr klein. Dekomprimiert wird es im Gerät. nach der Übertragung, vor dem eigentlichen Schreiben ins Flash. Das macht ein kleiner Loader, der zuerst auf "konventionelle Weise" geladen wird. So verbessern wir den Flaschenhals der seriellen Schnittstelle. Ich weiß gar nicht, warum der Hayo den alten Weg immer noch mit ausliefert, und das ucl-Flashing in einem Unterverzeichnis versteckt. Sorgt wie man sieht für Verwirrung, kipp' das doch mal auf den Müllhaufen der Geschichte! Jörg
Sorry, ich hab das so gepackt wie es bei mir auf der Platte liegt. Ich hab für mich ganz gerne noch die normalen Flashfiles als Backup, auch wenn ich sie nicht benutze. Beim nächsten Mal gibts dann nur noch die UCLs. Hayo
OK, gut, ich gebe schon Ruhe. ;-) Mir fällt auf, vielleicht sollten wir ein Make-Target "release" oder so haben, was alles nötige zusammenzipt? Jörg
Keine schlechte Idee, ich bin aber mit Make nicht unbedungt auf Du und Du. Ich müßte mich da erst tiefer reinarbeiten, da ich da sonst nur einfache Änderungen dran gemacht habe. Ich schau mir das mal an, ob mir da was Sinniges einfällt.
Michael D. schrieb: > Wie jetzt, da sind noch niedrigere Cutoff-Filter? Kannst du dazu noch > was sagen? Wie schon angedeutet sind es digitale Softwarefilter. Deren absoluter Bezugspunkt ist immer die Abtastrate. Alle Parameter dieser Filter sind immer relativ zur Abtastfrequenz (bei "Smooth" und "Strong" zur virtuellen, die indirekt durch die Zeit/div angegeben wird). Heißt etwas direkter gesagt, je niedriger die Abtastfrequenz, desto niedriger auch die Eckfrequenzen eines digitalen Filters. Gruß Hayo
Hallo Jörg und Hayo, Hayo W. schrieb: > Sorry, ich hab das so gepackt wie es bei mir auf der Platte liegt. Ich > hab für mich ganz gerne noch die normalen Flashfiles als Backup, auch > wenn ich sie nicht benutze. Beim nächsten Mal gibts dann nur noch die > UCLs. Lasst doch bitte die normalen Flashfiles im Makefile drin! Sie sind nunmal der native Weg die Firmware zu laden. Ich hatte ja schon vor längerer Zeit geschrieben, daß ich vor den UCLs grundsätzlich mit einem normalen Terminalprogramm (OcConsole/Win und glaube GTKTerm/Linux) geflasht habe. Das lief dann nur 5 min. Eine kleine Ewigkeit gegenüber den gepackten Dateien :-) Aber immernoch schnell gegenüber den oft gelesenen 20 min mit den Perl-Scripten bzw. Welecupdater. Das muss(!) gehen, wenn nicht im Hintergrund noch aller Unsinn läuft, der etwa die Serielle checkt und man ein vernüftiges Terminalprogramm und eine richtige RS232 benutzt Es gibt vielleicht Leute, die nicht erst Perl installieren wollen und mal schnell das Oszi updaten wollen. Danke! Grüsse Jürgen
Jürgen schrieb: > Lasst doch bitte die normalen Flashfiles im Makefile drin! Sie sind > nunmal der native Weg die Firmware zu laden. Im Makefile ist das sowieso drin, keine Sorge. Wenn's unbedingt sein muß, wie wäre es denn, umgekehrt die "legacy" Hexfiles in ein Unterverzeichnis zu verstecken? > Es gibt vielleicht Leute, die nicht erst Perl installieren wollen und > mal schnell das Oszi updaten wollen. Mal schnell, hihi. Ich glaube, Perl ist schneller installiert als auf den alten Flow zu warten... :-)) Wenn ich richtig flüstern höre wird es auch nicht (nur) bei Perl bleiben. Jörg
Jörg H. schrieb: > enn's unbedingt sein muß, wie wäre es denn, umgekehrt die "legacy" > Hexfiles in ein Unterverzeichnis zu verstecken? > Kein Problem! > > Wenn ich richtig flüstern höre wird es auch nicht (nur) bei Perl > bleiben. Meinst Du etwa noch Software von Altera? Das ist auf dem Desktop-PC schon lange drauf und wartet ungeduldig auf Programmer Input. :-) Jürgen
Btw... make release ist als Prototyp fertig. Bin gerade am Testen. Geht ganz gut. Hayo
Angehängte Dateien:
-
Backup-Flash.png
12 KB
> Meinst Du etwa noch Software von Altera? Das ist auf dem Desktop-PC > schon lange drauf und wartet ungeduldig auf Programmer Input. :-) aber sowas von... @Hayo > make release ist als Prototyp fertig. Bin gerade am Testen. Geht ganz > gut. fein! auch mal BtW. ich benutze gerade den Germs für ein Backup mit den Parametern: perl GERMSloader.pl COM6 -r flash_dump.flash 40000 7fffff Leider werden dafür satte 2400 Sekunden gebraucht, das macht über 40min. Gibt es eine Möglichkeit, auch das Dump ziehen zu beschleunigen? Vielleicht ist es ja nicht so wichtig, ich dachte nur, im Falle eines Problems, könnte man dann verifizieren!? ...nur so eine Idee. Gruß Michael
Das neue Makefile ist eingecheckt. Die Verzeichnisstruktur habe ich im ersten Wurf noch nicht geändert (nur Verzeichnisnamen umbenannt). @Michael Nein, das Gesamtbackup dauert halt etwas länger. Aber es werden nachher weniger als 40 min wenn ich mich recht erinnere, das ist nur die Anfangskalkulation. Hayo
>> Meinst Du etwa noch Software von Altera? Das ist auf dem Desktop-PC >> schon lange drauf und wartet ungeduldig auf Programmer Input. :-) > aber sowas von... Nein, die meinte ich eigentlich nicht, aber: Über JTAG kann man mit dem Nios II ruckzuck das Flash auslesen (oder brennen). Und von wegen Input: Ihr könnt das Design und Osoz für Nios II gern mal bauen. Der Andiiy macht das auch gelegentlich. OK, ich sollte mal ein Pre-Pre-Release machen. Jörg
Jörg H. schrieb: > OK, ich sollte mal ein Pre-Pre-Release machen. Na das wäre dann eine Alpha-Version. :-)
Ich wäre auch interessiert... Ich habe ja meinen JTAG-Adapter noch unbenutzt liegen. Bislang hatte ich noch keine Gelegenheit den mal zu testen. Mal wieder offtopic: Hat jemand das Bild zur Hand auf dem zu erkennen ist wo beim 4-Kanaler die Brücke hinmuß, damit Quartus die Büchse über JTAG erkennt? Hayo
öhm, warum in der HW stochern? Dafür gibt es doch den Altera-USB-Blaster.
Angehängte Dateien:
-
USB_and_JTAG.png
160 KB
Hayo W. schrieb: > Hat jemand das Bild zur Hand auf dem zu erkennen ist wo beim 4-Kanaler > die Brücke hinmuß, damit Quartus die Büchse über JTAG erkennt? Das gab es hier: http://sourceforge.net/apps/trac/welecw2000a/attachment/wiki/USBBlaster/Solder%20here%20kl.JPG @ Mike > Dafür gibt es doch den Altera-USB-Blaster. Der geht dann auch auf JTAG. Siehe Anhang Jürgen
Guten Abend Hayo und all jene, die an dem Projekt beteiligt sind Welec! Hayo, nochmals vielen Dank für die hervorragende und unermüdliche Arbeit! Vielen Dank für die Zeit, die Sie bei uns verbringen, Sie sind sehr freundlich! Wie immer bin ich sprachlos!: KLASSE! Hayo W. schrieb: >@Luc > >The Problem with Logic Analyser and QM should be solved now. If not, >please contact me. Hayo there isn't need, as always You are right and all troubles which I have reported in the former beta version are gone: RESPECT!!! I quickly tested all them and none of them is survived in the new 1.2.BF.6.3 firmware's release. As usual in the weekend it will follow my review with more accurate tests. ;-) I'm working to improve my 300pS pulse generator adding to it a coaxial line stub. As You and All other here know, I'm pretty interested about the Welec's bandwidth and about how to improve it and I read in the "Wittig(welec) DSO W20xxA Hardware (Teil 2)" that there are some good news (thanks to Branadic for the intuition and thanks to Jörg H., Jürgen, Michael D. and Hayo for the the research of the implementation: RESPECT to all You!). I know, that is a bit OT here, so sorry about it, see You later in the Hardware thread. ;-) Returning IT, maybe I'm wrong but seems to me in this new release the trigger works better than ever either inner than EXTernal trigger, really very good: KLASSE! Even very nice and impressive the screen status as it is now implemented: KLASSE! But only one thing and as always only for knowledge and no for criticism. Hayo, now using ALTernate trigger the trigger level on the top of the screen became 0 Volt but adjusting it throught its knob it is possible to change the level, which however it remain as it was setted when ALTernate trigger is switched off returning in usual trigger mode (CH1 or CH2 for two channels DSO version or even CH3 or CH4 for the four channels version). Instead if the trigger level knob is not adjusted then switching among ALTernate tiggers and the previous setting, the trigger level shown on the top of the screen return to be as it was setted before to switch in ALTernate mode. Seems to me the values that I obtain by adjusting the trigger level knob during the time which ALTernate trigger is settled on are dummy, they are not real. I hope I was understandable although I realize I explained badly. However I don't know why and if this is normal or no, I emphasize it only as knowledge. Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Michael D. schrieb: >> Was sagt Ihr zu der Lösung mit der AC/DC Umschaltung? > Optimaler geht's ja wohl nicht, da freut sich der Charly. naja, nicht wirklich ;( es geht schon wieder so ein Popup auf und vergeudet 3 wertvolle Sekunden meines Lebens ;) ne im ernst, ein schnelles umschalten ist jetzt durch das Popup nicht moeglich, vielleicht bin ich auch durch das Agilent zu sehr verwoehnt worden.Bei mir ist es auch so dass ich nach einer recht kurzen Zeit ein von mir verwendetes Geraet quasi 'Blind' bediene, zB. weis ich wenn eine bestimmte Einstellung vorhanden ist dass ich zB. 3 mal die Taste druecken muss um die neue Einstellung zu erreichen. Da ich das Oszi halt auch Beruflich nutze sitze ich halt schon oefter mehrere Stunden davor. Frage: was macht das Popup eigentlich fuer einen Sinn wenn ich doch nur weiterschalten kann? @Hayo, vielleicht ueberdenkste das nochmal mit dem Popup, ich waehre dir auf jedenfall dankbar dafuer (und wieder happy) vlG Charly
@Jürgen Jupp das isses, danke. Dann werd ich mal den Lötkolben anspitzen... @Michael Die Brücke muß auch für den Blastertreiber beim 4-Kanaler rein. @Luc Yes I know that the level adjusting in alternate mode is a little bit "suboptimal". The adjusting is alternating (as the trigger channel) and it is a little bit confusing. So the work around is, to adjust it before switching to alternate mode. I'm working on a solution. @Charly > Frage: was macht das Popup eigentlich fuer einen Sinn wenn ich > doch nur weiterschalten kann? Du kannst mit einzelnem Druck direkt umschalten (ohne hinzusehen), was viel schneller geht, das Popup hat natürlich trotzdem noch seine Timeout-Pause. Aber man kann mit mehrfachem Druck auch GND auswählen was ich als ganz guten Kompromiss empfinde. Bliebe nur noch die Variante die ich schon angedacht hatte mit dem Drehknopf, dann könnte das Popup beim Druckknopf wegfallen. Ich schau mal... Hayo
Hayo W. schrieb: >> Frage: was macht das Popup eigentlich fuer einen Sinn wenn ich >> doch nur weiterschalten kann? > > Du kannst mit einzelnem Druck direkt umschalten (ohne hinzusehen), was > viel schneller geht, das Popup hat natürlich trotzdem noch seine > Timeout-Pause. Ja und genau diese Timeout Phase ist das Stoerende > Bliebe nur noch die Variante die ich schon angedacht hatte mit dem > Drehknopf, dann könnte das Popup beim Druckknopf wegfallen. Ich schau > mal... das waehre dann die wesentlich bessere Alternative denk ich vlG Charly
Ach ja was ich zu den Änderungen der letzten beiden FW Versionen vergessen habe zu erwähnen, was mir aber durch Lucs Beitrag wieder eingefallen ist - die Triggerlevelregister haben (was wir ja schon länger wissen) ein stark nicht lineares Verhalten und der Level stimmte anfangs überhaupt nicht. Ich hatte dann mal eine einfache Korrektur eingebaut, die aber den Nachteil hatte, dass es einen blinden Fleck irgendwo in der Signalmitte gab und der Trigger nur ab einer Mindestsignalamplitude von einem div ansprach. Seit FW 6.0 habe ich da einen neuen Korrekturalgorithmus eingebaut, der besser arbeitet und auch Signale mit Amplituden < 0.5 div erkennt. Soweit zur allgemeinen Info Gruß Hayo
Guten Abend Hayo und all jene, die an dem Projekt beteiligt sind Welec! Hayo W. schrieb: >Yes I know that the level adjusting in alternate mode is a little bit >"suboptimal". The adjusting is alternating (as the trigger channel) and >it is a little bit confusing. So the work around is, to adjust it before >switching to alternate mode. I'm working on a solution. Ok Hayo, I understand and as always I thank you for the explanation: RESPECT! However I wrote about that only for knowledge as I already said, for me as it is now the new firmware it works well and the trigger level shown on the top of the screen when in ALTernate trigger isn't so important. Of course any further improvement there will it will not be despised, so thanks in advance! ;-) I'm not involved in software development but I imagine the difficulties that You have to overcome in order to be able to do what You do. It's very hard and honestly often I can not understand how You can reach the results You get, so RESPECT to You one time again! Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Guten Abend Hayo und all jene, die an dem Projekt beteiligt sind Welec! Wie heute bekannt gegeben, versuchte ich die neueste Version der Firmware, 1.2.BF.6.3. Es scheint mir, dass alles in Ordnung ist, habe ich nicht finden Mängeln, so vielen Dank Hayo: KLASSE! Ich spielte auch ein wenig mit einem 133MHz FPGA-Board Vergleich der Signale auf meinem Welec W2012A und W2022A angezeigt mit den von einem Logikanalysator erhaltene. Auffallend ähnliche Ergebnisse, indem Sie die Trigger-Logik bis 3,3 V. Ich habe schon gesagt, dass es nicht falsch zu unserer Welec als MSO Oszilloskope definieren ;-): KLASSE! Inzwischen, dass ich dort war Ich habe einen Blick auf die Impulsantwort wo aber habe ich nicht gefunden neue, Ich fand das Format der Skala von Proportionen falsch Unterschreiten 1V/div. Siehe hier Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" und hier Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Beim Abstieg von 1V/div 500mV/DIV zu arbeiten, höre ich das Relais und dann das Signal auf dem Bildschirm wird kleiner, als ob der Größenskala des Gitters war falsch aber ich kann nicht verstehen, warum. In jedem Fall ist es offensichtlich, wie der Frequenzgang des W2022A signifikant besser als diejenige des W2012A ist (sowohl Welec mit dem Widerstand 24,9 / 150 Ohm aktualisiert werden). Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Ein kleiner Zwischenbericht aus der Programmiererecke. Während Jörg an unserer Hardwarezukunft dengelt hole ich noch das Letzte aus dem alten Design heraus bevor diese Entwicklungslinie stirbt. Jörg hat mich bei unserem letzten Telefonat auf die Idee gebracht die gelesenen Daten zu reduzieren um die Geschwindigkeit noch zu erhöhen. Gesagt getan. Es war etwas knifflig die Pointer vom schnellen ADC-Speicher, dem Lesebuffer und der Ausgabe auf dem Screen zu synchronisieren, aber es läuft jetzt stabil und schnell. Nur so als Anhaltspunkt: die schnellen Zeitbasen 200ns - 2ns (ja auch die interpolierten Zeitbasen!) sind jetzt doppelt so schnell. Das macht sich besonders positiv bemerkbar wenn man alle 4 Kanäle gleichzeitig in Betrieb hat. Die 6.4 wird auch noch weitere Features mitbringen. Gruß Hayo
So, da ist sie. Für die neue Version habe ich mich noch mal richtig ins Zeug gelegt, sprich sie ist schöner, schneller - besser! Hier die wesentlichen Punkte: - wie schon angekündigt sind die Zeitbasen ab 500ns deutlich schneller geworden - im Hardwaremenu kann man jetzt die Skalierung selber feinjustieren. Der Justierbereich geht von 0.5 - 2 - die IIR Cutoff Frequenzen im On Screen Status sind korrigiert - QM mißt jetzt endlich korrekte Spannungspegel! Vergleicht das mal vor dem Flashen und hinterher. Es wurden immer zu niedrige Werte gemessen. - Für Charly habe ich noch mal die Button Logik geändert. Wenn es so nicht passt dann weiß ich auch nicht... - Der Probe-Divider kann jetzt nicht nur Untersetzungen sondern auch Verstärkungen (0.5:1 / 0.2:1 / 0.1:1) - diverse kleinere Fixes Gruß Hayo
Angehängte Dateien:
Hallo Hayo, dann fange ich mal an: hier 2 Shots, vorher(6.3) und nachher(6.4) zu sehen ist ein PWM-Signal mit 131Hz von einem Selbstbau RGB-Dimmer. Nach dem Flashen der 6.4, habe ich jetzt aber mehr Grundrauschen ohne Signaleingang, das war vorher weniger. Für was ist jetzt die Gain im HW-Menu? Zur reinen Feinjustierung oder Skalierung? Ich denke eher ersteres? Gruß Michael
Angehängte Dateien:
-
6.3-Noise.png
4,6 KB -
6.4-Noise.png
4,7 KB
Hier mal die Bilder vom Grundrauschen. 1.Pic: Ver6.3 2.Pic. Ver6.4 Bei beiden Versionen habe ich Defaultsetup gemacht und danach mehrmals kalibriert. Gruß Michael
moinmoin Hayo & 'Leidensgenossen' ;) 1. das mit den hoheren Grundrauschen ist mir auch aufgefallen 2. das mit der Button Logik ist so BESTENS , 'NUR' haste das im Mode/Coupling menue bei den ersten 2 Tasten vergessen ;( i denke das kann man bei jeder Taste realisieren die ein Popup oeffnet und dann nur weiterschaltet, i wuerd wetten das nach kurzer eingewoehnung das keiner mehr missen moechte.... nochmals Danke! & ein schoenes WE Charly
Angehängte Dateien:
-
W2022A.jpg
87 KB
Ich möchte mein kleines Welec verkaufen: Zustand: - Neuwertig - Zusätzliches Schirmblech - 2 zusätzliche Triggerleds - 24,9Ohm/174Ohm Widerstandbestückung - 2 Tastköpfe inkl. Zubehör sowie Netzkabel - auf Wunsch inkl. Platine (ohne Bauteile) für USB-Host Realistische Preisvorschläge bitte per PN. Mfg, Kurt
Charly B. schrieb: > 1. das mit den hoheren Grundrauschen ist mir auch aufgefallen Sorry, anscheinend ist bei der Kalibrierroutine durch die umfangreichen Änderungen ein kleiner Bug reingeraten, Korrektur kommt so schnell wie möglich. > 2. das mit der Button Logik ist so BESTENS , 'NUR' haste das > im Mode/Coupling menue bei den ersten 2 Tasten vergessen ;( Nein, hab ich nich vergessen. Den Mode kann man schon seit Längerem durch mehrfaches Drücken des Mode/Coupling Buttons verstellen, was ich schnell genug finde und die Kopplung des externen Triggers ist wohl nicht so zeitkritisch denke ich oder? Hayo
So bin gerade erst wieder zu hause und hab mich gleich drangesetzt. War auch recht schnell gefunden. Zur Erklärung: Ich stelle gerade die Kanalnummerierung im ganzen Programm Stück für Stück um. Im normalen Leben zählt man ja von 1 bis 4, der geneigte Programmierer zählt aber anders, nämlich von 0 bis 3. Leider hat der gute WELEC-Programmierer sich etwas sehr am normalen Leben orientiert und alles von 1 bis 4 durchnummeriert. Dadurch kann man kein Array vernünftig ansteuern bzw. muß den Index immer wieder um eins zurückrechnen. Bei dieser Umstellung kann einem schon mal die eine oder andere Stelle entgehen. Ich bitte also um etwas Nachsicht wenn's da mal hakt. Jetzt habe ich aber erstmal nichts mehr gefunden. Gruß Hayo p.s. ach ja, eine Änderung hatte ich noch vergessen - die Anzeige des Triggerlevel hab ich noch korrigiert, die hat auch etwas falsch gerechnet, alles noch Altlasten die ich jetzt beseitigt habe.
Angehängte Dateien:
-
2.Kanal-Noise.png
4 KB
Halo Hayo, habe gerade hier gesessen, da hat die Email-Trulla geplärrt! ;-) Natürlich habe ich gleich die 6.4C2 geflasht, Default Setup, kalibriert... Der 1.Kanal ist erste Sahne vom Rauschverhalten, der 2.Kanal will nicht, hast du den vergessen zu korrigieren? Gruß Michael
Hmm, sieht ja komisch aus. Nein eigentlich sollte das gehen, bei mir sehen alle 4 Kanaäle gut aus. Warte mal, ich flash das mal eben in mein W2022A rein, da hab ich noch die 6.3 als Vergleich drin. Hayo
Ja Du hast recht, da ist noch der Wurm drin, bei mir ist auch der zweite Kanal nicht kalibriert. Komischerweise ist mein W2014A da ganz unbeeindruckt. Ist also in Arbeit, danke für den Hinweis. Hayo
Hi Hayo, das funktioniert jetzt! Tolle Arbeit! Da hat sich aber noch ein kleines Häkchen auf dem F6-Button unter Utility/Hardware/F6 versteckt, der ev. auch nur der Return-Pfeil nach oben sein soll? Irgendwie ist die stdint.h abhanden gekommen, bzw. wurde vorher noch nicht benutzt. Kannst Du die bitte mal hochladen und dann mit ins Archiv legen? Compilieren geht sonst nicht.... Danke und Gruß Jürgen
habe gerade am Trigger gespielt. Es tritt auf bei 50, 20, 10µs, ok 5µs, Noise 2µs, 1µs ok 500ns, Noise 200ns, ok 100ns, 50, 20... Noise
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.