Die 0.82 läuft hier auf einem 2024A 8C7.C9 ohne Probleme.
Ging ganz genau so, wie Hayo beschrieben hat. Man, was bin ich erleichtert :) Btw: vielen Dank Euch allen, dass Ihr Euch so reinhängt !
@Bruno Also grundsätzlich zur Scalierung ist anzumerken, dass sich die Performance bei der FFT unter anderem nur bewerkstelligen ließ, in dem auf Multiplikationen verzichtet wurde und stattdessen Shift-Operationen eingesetzt wurden. Dadurch sind die verfügbaren Skalierungen erstmal beschränkt. Man kann das sicher auch noch etwas feiner abstufen, wie bei der normalen Grafikroutine, aber auch das kostet zusätzlich Zeit. Hier muß man also abwägen. Die Beschriftung für das Grid ist erstmal nur im Log-Modus verfügbar da diese sich ja wegen der Normierung nicht ändert. Wenn ich den Linearen Modus beschrifte muß ich jedesmal einen Refresh durchführen wenn der Messbereich wechselt. Ist aber durchaus machbar. Das Gleiche gilt für die Frequenzanzeige. Ich habe auch schon überlegt was sich da an eleganten Lösungen so anbietet. Die Beschreibung von Lecroy ist sehr interessant, die werde ich mir noch mal genauer ansehen. Ich lasse da gerne Anregungen von anderen Oszis mit einfließen. > 4.) Lecroy korrigiert die fft Darstellung so, daß die > Spektralllinien im Pegel dem Level im Zeitbereich entsprechen > s.h. Dokument, Seite C-5 oben. Das war ursprünglich bei mir auch so, aber ich fand es besser die volle Gridhöhe zu nutzen. Spricht was dagegen? OdB bezieht sich auf die Amplitude des Signals im Zeitbereich bei Vollaussteuerung. D.h. ein Sinussignal sollte eine Frequenzlinie mit 0 dB Verlust haben, während ein Rechteck sogar mit der Grundschwingung H1 ein wenig im +dB Bereich (Verstärkung) liegen sollte wenn im Zeitbereich der ADC-Wandler mit den vollen 8 Bit (255) ausgesteuert ist. Zu 8: Die Aliasfrequenzen entstehen leider nicht erst bei der FFT, sondern schon direkt bei der Abtastung, so dass man einem Datensatz nicht ansieht ob die Frequenzen nun echt sind oder nicht. Wenn man die Auswirkungen kennt, kann ein Mensch das zwar auf dem Bild erkennen, aber der Rechner kann es nicht herausrechnen - schade, sonst könnte man sich Bandbegrenzungsfilter sparen. Gruß Hayo
@Bruno Ich habe mir die LeCroy-Doku noch mal genauer durchgelesen. Mit der Skalierung der Amplitude auf die Amplitudenhöhe im Zeitbereich war hier nicht der Skalierungsmaßstab gemeint, sondern die Korrektur der Amplitude, wenn diese in einen gedämpften Frequenzbereich fällt. Siehe hierzu auch meine Anleitung Seite 10 Abb. 7 - Gewichtung im Frequenzbereich. Eine solche Korrektur ist natürlich eine feine Sache, das wäre noch was für die ToDo-Liste, ebenso wie die Anzeige des Leistungsspektrums. Werde ich mir mal vornehmen... Gruß Hayo
@Niklas Der Screenshot funktioniert ja, wie die Anderen ja auch bereits feststellten, prima; nur ist das Ergebnis auf dem PC doch sehr flau. Besteht da eine Chance, dass die auf dem Scope dargestellten satte Farben auf dem PC ein ähnliches Niveau erreichen. Also Gelb ein FFFF00, Grün ein 00FF00 u.s.w. Das Blassgrün in Verbindung mit dem Blassblau hat einen doch sehr niedrigen Kontrast. Ich möchte nicht quengelig erscheinen; das was Du hier abgeliefert hast, hilft mir sehr und ist weit mehr, als man eigentlich in so kurzer Zeit erwarten konnte - vielen Dank noch einmal !
Hallo Hayo, zu 8.) hast du natürlich recht... war ein Schnellschuß- kann in meinem Alter schon mal vorkommen ;-) Wenn das so einfach wäre, würden das renommierte SA Hersteller schon lange so machen. Kannst du unter 2.) aufgeführtes Phänomen nachvollziehen? zu 5.) Soweit kein Problem- wenn man weiß wo der Bezugspunkt, sprich 0dB liegt. Gruß, brunowe
Quick-Measure funktioniert prima - viel besser als erwartet. Mir ist dabei aufgefallen, dass eine Umschaltung des Kanals via Softkey nichts bewirkt. Erst das Aus- und wieder Einschalten von Quick-Measure übernimmt den geänderten Kanal. Wenn man einmal 'Measure Average' gewählt hat, wie kommt man wieder zur vorhergehenden Einstellung (?) ist das eine Einbahnstraße ?
Angehängte Dateien:
-
new.jpg
48 KB
@Stefan,
gefällt es dir so besser?
/* Channel_Plane2 */ { 0x00, 0xFF, 0x00 }, /* green */
/* Channel_Plane3 */ { 0x18, 0x35, 0xc2 }, /* blue */
Ich habe die Datenkompression für Niklas' Quick-Print-Funktionen etwas überarbeitet. Die Datenmenge ist deutlich kleiner, die Geschwindigkeit leider nicht so ganz. Ein SW-Dump dauert jetzt 10s, Farbe dauert 30s. Bei Interesse stelle ich die Änderungen hier ein. (Oder zieht Ihr einen anderen Ort vor?) Als nächstes könnte ich die "Save to CSV"-Funktion schreiben. Falk
Hallo Kurt, das macht es schon deutlich einfacher, die Darstellung der einzelnen Kanäle zu differenzieren. Auch wenn hier noch etwas Abstimmung in bezug auf die Wahrnehmung der einzelnen Farben (annähernd gleiche Helligkeit) erforderlich wäre. Ist das gleiche Problem, dass sich beim layouten darstellt. Grün und Gelb recht dominant gegenüber Rot und in diesem Fall besonders Blau.
Weitere Möglichkeit zur Datenreduktion: Die FFT läuft jeweils nur auf einem einzigen Kanal. Die Planes der anderen 3 Kanäle müssen nicht übertragen werden. Das Grid, auch wenn es mehrere gibt ist immer gleich. Es reicht die Grids durchzunummerieren und die Nummer des jeweils aktiven Grid zu übertragen. Die eigentlichen Daten dieser Plane liegen im PC Prog als Tabelle vor. Es muss nicht die Cursor oder Math Plane übertragen werden, wenn die garnicht benutzt werden... Wenn man zuerst den aktuellen Betriebsmodus sendet und nur die nötigen Daten solle sich die Übertragungszeit um 15-20 sec. reduzieren lassen.
@Bruno Nein, bei mir sieht das völlig anders aus. Bei 25mV + 50mV mit Rechteckfenster werden 40mV angezeigt, mit Poisson-Fenster nur noch ca. 12mv - Das ist ein durchaus nicht unerwartetes Ergebnis. Hayo
@Falk Prima, einfach hier hochladen, ich baue das dann ein. Gruß Hayo
Angehängte Dateien:
-
screenshot.png
5,3 KB
Stefan, du könntest auch diese Bild mit einem Zeichenprogramm ausmalen ;-) PaintNet zeigt direkt die HEX Werte der Farben an. Die geraden Linien mit dem "Farbeimer", die diagonalen mit dem Linienwerkzeug. Wenn du die schönste Farbkombination gefunden hast kann man die im Oszi und im Programm einbauen. Ich bin leider Farbenblind. ;-)
Hallo, @Stefan: > Besteht da eine Chance, dass die auf dem Scope dargestellten satte > Farben auf dem PC ein ähnliches Niveau erreichen. Ja, sicher. Die Werte die ich genommen habe sind nur per Daumen und Augenmass anhand meiner Wahrnehmung vom DSO Output von mir geschaetzt, hab' da aber nicht wirklich Zeit fuer investiert. Wie Kurt zeigt kann man die Konstanten aendern, sicher koennen wir in zukuenftigen Versionen die Werte ueber z.B. eine .ini-Datei direkt vom Benutzter anpassen lassen. @Falk: [Optimierung RLE Algo, Zeitreduktion] Das klingt gut, ich finde wir sollten Deine Aenderungen direkt uebernehmen. Ich persoenlich finde das diff-Format dazu ( http://de.wikipedia.org/wiki/Diff ) am praktischsten. > Bei Interesse stelle ich die Änderungen hier ein. > (Oder zieht Ihr einen anderen Ort vor?) Ob wir das immer alles hier in dieses Forum posten sollten weisz ich nicht, fuer mich waere auch die Google Group i.O.. Das pflegen des Codes ueber eine Versionsverwaltung waere auch in Ordnung, ich hab' hier schonmal gelesen das wohl der Service von Sourceforge nicht so prickeln ist und Leute Probleme damit haben. Wenn Interesse besteht kann ich sowas aber auch selbst hosten (habe eigene Rechner in RZ). > Als nächstes könnte ich die "Save to CSV"-Funktion schreiben. Ja kannst Du wenn Du Zeit hast mit anfangen, ich hab' da diesbzgl. auszer den geschilderten Vorueberlegungen nocht nichts gemacht. Ich werde auch noch meine bereits geschriebenen ZModem Funktionen einstellen, auch wenn da noch noch auf dem DSO die ISR Anpassung fehlt um die verwenden zu koennen. @Kurt: [Nicht alle Planes uebertragen] Daran hab' ich auch schon gedacht. In der Tat sind ein paar der 16 Planes ueberhaupt gar nicht benutzt, zudem kann man wie Du beschreibst noch weitere ausschlieszen. Da das DSO ohnehin da "Ewigkeiten" pro Plane braucht liesze sich da deutlich Zeit einsparen. Es gibt allerdings ein paar Sachen zu beachten, ich hab' ja schon die Beobachtung gemacht (im Sourcecode gibt's nen Kommentar dazu), dass die roten Pfeile und das rote Stop(p)-Schild auf die Channel 4 Plane gelegt sind (weil die vmtl. gerade rot war, oder so...). Ohnehin war mir zum Zeitpunkt als ich das schrieb' noch nicht klar, welche Planes nun genau zu welchem Zweck genutzt wurden und habe alle rausschreiben lassen, auch die Marker Planes, die gar keine Einfaerbung erhalten. Also ja. Auch die Zeitersparnis die wir dadurch gewinnen koennen wir bitter gebrauchen. Vllt. noch fuer die Entwicklung die Moeglichkeit offen lassen trotzdem alles zu uebertragen, um wie schonmal gesagt Darstellungsfehler einfacher lokalisieren zu koennen. @alle: Sollten wir vllt. irgendwo eine stets aktuell gehaltene Liste haben "wer arbeitet gerade woran" um doppelte Arbeit zu vermeiden? Niklas
Hallo, hier wie im letzten Post beschrieben die ZModem Routinen. Sourcecode im Anhang, Header Inline:
1 | #ifndef _zmodem_h_
|
2 | #define _zmodem_h_
|
3 | |
4 | static void zm_send_hexhdr(int, char [4]); |
5 | static void zm_send_zdle(int); |
6 | static void zm_send_binhdr(int, char [4]); |
7 | static void zm_send_data(char, char *, int); |
8 | static int zm_get_hexhdr(void); |
9 | static int zm_get_binhdr(void); |
10 | static int zm_get_header(void); |
11 | static int rd_char(void); |
12 | void zm_test(void); |
13 | void zm_buf(int); |
14 | static int GETCH(void); |
15 | |
16 | #endif
|
Niklas
Angehängte Dateien:
-
Clipboard01.png
37 KB
Kurt, Ich musste eben auch feststellen, dass es nicht ganz so trivial ist wie es auf den ersten Blick schien :-\ Ein paar Linien mit Corel auf einer schwarzen Fläche sind ähnlich blass, wenn nicht schlimmer; hingegen kommt ein Screenshot aus dem Layout doch deutlich "leuchtender" rüber - mir fehlt jetzt ein sich am Kopf kratzender Smiley ;) Ich vermute mal, dass mein Bildschirm bescheiden abbildet oder meine Augen schlecht eingestellt sind...
Ich glaube auch es sind deine Augen ;-) Im Layout will man immer möglichst große Flächen haben, wohingegen im Screenshot die Linien möglichst dünn sein sollen. Das verbessert deren Sichtbarkeit natürlich nicht gerade.
Hallo Kurt, > Den Wechsel von .c auf .cpp hat das Studio vorgegeben. Nötig ist er > glaube ich nicht. Ja, ich hab' die w2000a-screenshot.c nur zu nem .cpp gemacht weil der Parser die ComTools.h sonst nicht fressen wollte. Die benoetigten Sachen die die ComTools machen koennen wir denke ich auch leicht selbst neu bauen. > Die unistd darf bei mir nur unter Linux eingebunden werden. > Ersetzen von (int) usleep(1000) durch (void) Sleep(1000) sleep(1000) wuerde 1000 Sekunden warten unter allen mir bekannten libc... (Ist abgesehen davon auch POSIX) > Ersetzen von snprintf() durch sprintf_s(). > Aus fopen wird fopen_s Noch nie irgendwo implementiert gesehen, was machen die anders als die n-Versionen? http://netbsd.gw.com/cgi-bin/man-cgi?snprintf Die n sind egtl. soweit ich weisz auch C99... > Dann gibt es noch Probleme mit optarg und getopt()... Zu erwarten... > Die Frage ist ob die Änderungen auch mit Linux laufen. Leider nicht. > PS: > Mit MinGW geht es bei mir aber auch so. Ich musste erstmal > googlen wie man damit kompiliert. ;-) Wollen wir bei MinGW bleiben, oder statt der n die ganz normalen Versionen verwenden und getopt() selbst implementieren? Statt fopen() geht ja auch open(), oder fehlt das auch? Niklas
Hallo, nochmal, urgs, merke gerade das ich oben als ich von den Planes mit (mir) noch nicht bekannten Funktionen sprach da die Marker Planes erwaehne. Da meinte ich natuerlich die Memory Planes. Niklas
Da dieser Thread mittlerweile die 1000 Einträge überschritten hat, wäre es da evtl. sinnvoll ihn noch einmal zu splitten (?) funktioniert ja bei Hardware | Software auch ganz gut. Dieser hier würde dann für Rückmeldungen bzgl. eventueller Fehler, Usability und ggf. Wunschdenken aktiv bleiben, während sich ein neuer Thread in Richtung allgemeine Entwicklung, Tools, sowie konzeptionelle Ausrichtung und Strategien abspaltet... ich vermute mal, dass eine Abspaltung der überschaubaren Anzahl aktiver Entwickler disziplinierter vonstatten gehen würde, als die Vielzahl der hier mitlesenden auf einen neuen Thread umzubiegen. Ist nur so eine Idee - bitte nicht kreuzigen :)
Ich denke eine weitere Aufsplittung würde es eher unübersichtlicher machen, allerdings könnte man den Thread evtl. mal wieder neu aufsetzen damit die Beiträge überschaubar bleiben. Hayo
Hallo Hayo, ich habe folgendes Problem: ich nehme ein Signal auf (5µs/div), drücke auf Stop. Signal bleibt stehen. Ich zoome rein auf 2µs/div, Signal wird kurz vergrößert dargestellt, so wie es gedacht ist. Aber dann wird auch schon ein neues aufgezeichnet. Kannst du das mal fixen? Gruß, Stefan
Hi, anbei die diffs für die überarbeiteten Screenshot-funktionen. Das diff für die Firmware ist für 0.82, kann aber einfach am Ende von src/display_t.cpp gegen die drei ursprünglichen Funktionen, tschuldigung, Methoden, is ja C++ ;-) ausgetauscht werden. Das diff für den PC-Teil bezieht sich auf die Version 0.2, wenn Niklas den entsprechend einpflegen könnte? @Hayo: Mein Vorschlag zur Bedienung der Screenschot-Funktion: Quick-Print macht einen Screenshot wie in 1.2.BF.0.82. Da die Screenshots und Rohdaten ohne ein Stück Software auf dem PC sowieso sinnlos sind, kann die PC-Soft einfach ein Kommand über RS232 schicken, das die gewünschte Aktion startet. Ich stelle mir das so vor, daß die bisherige Steuerung unverändert bleibt, abgesehen von dem Zeichen "starte spezielle funktion" STX, ASCII 0x02. Hardware::ISR_UART bekommt eine simple State-machine, die alles durchreicht, außer STX-LEN-Daten-ETX und nach ETX ein Flag setzt. Das könnte mit UART_NewData=2 realisiert werden. In Hardware::Keyboard_Interface könnte dann etwa so aussehen:
1 | switch (UART_NewData) { |
2 | case 1: UART_NewData = 0; //reset UART ISR flag |
3 | if (UART_RXData == 'a' ) { lMenuKey = 0; } // Acquire |
4 | ....
|
5 | case 2: handle_remote_control(...) |
6 | }
|
7 | UART_NewData=0 |
Ich würde das einbauen, wenn wir uns nicht gegenseitig dabei stören. Gruß, Falk
Stefan schrieb: > Da dieser Thread mittlerweile die 1000 Einträge überschritten hat, wäre > es da evtl. sinnvoll ihn noch einmal zu splitten (?) funktioniert ja bei > Hardware | Software auch ganz gut. Wie wäre es mit einem eigenen Forum. Dann könnte man die Threads nach HW, Software, Diskussionen etc. trennen. Mir gefällt "Phorum" ganz gut und einen Server hätte ich dafür. Falk
@BF.0.82: Läuft ziemlich gut. 3 Dinge sind mir aufgefallen: * About Oscilloscope: Auch hier gibts Artefakte, wenn man z.B. vorher im Quick Measurement Menü war * Quick Measurement: Wenn ich z.B. das Probe Comp Signal (bei 200uS/div) anschaue, dann ist die Periode dauerhaft 1.00ms, aber die Frequenz flackert zwischen 995.0 und 999.0 Hz, ohne dass die Nachkommastelle mal ungleich wäre. Auch die Spannungsmessungen wie z.B. Pk-Pk ändern nie ihre Nachkommastelle. * UART: Wenn ich im Quick Measurement Modus bin, reden die Messfunktionen bei jedem Aufruf auf der UART. Solche Meldungen, die beim Entwickeln sehr helfen, solltet ihr unter Zuhilfenahme eines Makros ausspucken, damit die in den Releases still sind. Das kostet alles unnötige Zeit, wenn andauernd auf die UART geschrieben wird. Falk Willberg schrieb: > Wie wäre es mit einem eigenen Forum. Dann könnte man die Threads nach > HW, Software, Diskussionen etc. trennen. > > Mir gefällt "Phorum" ganz gut und einen Server hätte ich dafür. Nochmal das Angebot: Nutzt doch das phpBB auf SourceForge mit: http://sourceforge.net/apps/phpbb/welecw2000a/ SourceForge-Handles haben eh' die meisten schon, und ihr könnt gern alle Mod- oder Admin-Rechte haben und eine beliebige Menge Foren und Kategorien anlegen. Würde mich freuen, wenn das Forum dort mehr genutzt würde.
Daniel H. schrieb: ... > Nochmal das Angebot: Nutzt doch das phpBB auf SourceForge mit: > http://sourceforge.net/apps/phpbb/welecw2000a/ Gefällt mir ;-) Mal sehen, ob es ankommt... Falk
@Daniel SFN könnte man natürlich machen, aber ich fand das immer recht zäh und langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit eigene Foren einzurichten ist natürlich nicht übel. @Falk Auch Dein Angebot einen Server zur Verfügung zu stellen ist recht reizvoll da dann die Kontrolle quasi "in unserer Hand" bzw. in Deiner läge. Vermutlich wären auch die Antwortzeiten attraktiver als bei SFN. Zudem bestünde wohl auch die Möglichkeit überlaufende Threads in regelmäßigen Abständen zu archvieren und zu bereinigen, so dass nicht immer neue Treads nötig sind. Zum UART: Von meiner Seite her keine Einwände. Ich bin da nicht mehr zugange, ich hatte nur für Niklas aufgeräumt - da müßtest Du Dich also am Besten mit Ihm abstimmen. Meine Baustelle ist nach wie vor die FFT, die ich gerade komplett überarbeite und erweitere (angeregt durch Bruno und die LeCroy Broschüre). Zu Deiner zerschossenen USB-Schnittstelle: Poste das doch noch mal im Hardwarethread, eigentlich müßte doch nur das Flash fur den USB-Controller neu geschrieben werden wenn ich mir das so überlege. Da waren doch schon einige aktiv glaube ich. Und zu guter Letzt finde ich es prima dass Du wieder aktiv dabei bist, nachdem ich einige Zeit nichts mehr von Dir gehört hatte. Gruß Hayo
Hallo, ich würde auch gerne mal Eure neue FW testen, bevor ich allerdings etwas kaputt mache, will ich vorher nochmal kurz nachfragen. Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim nächsten Oszi Start dann wieder weg? Kann ich das unter Windows einfach mit der WelecUpdater.exe machen? Oder muss ich mir vorher nen Perl-Interpreter zulegen, damit ich das mit dem Skript machen kann? Danke! Gruß, Michael
Angehängte Dateien:
-
FFT.gif
9,1 KB
Hayo W. schrieb: > @Daniel > > SFN könnte man natürlich machen, aber ich fand das immer recht zäh und > langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit > eigene Foren einzurichten ist natürlich nicht übel. Ich habe da jetzt einfach mal einen Thread zum Thema screendump aufgemacht. Wenn sich das nicht bewährt, kann ich auch ein Forum bereitstellen. ... > Zum UART: Von meiner Seite her keine Einwände. Ich bin da nicht mehr > zugange, ich hatte nur für Niklas aufgeräumt - da müßtest Du Dich also > am Besten mit Ihm abstimmen. Ok. Ich denke, Niklas hat es mitbekommen. Ich brauche die ISR wahrscheinlich nicht, meine Erweiterung sollte sich in Hardware::Keyboard_Interface einbauen lassen. > Meine Baustelle ist nach wie vor die FFT, > die ich gerade komplett überarbeite und erweitere (angeregt durch Bruno > und die LeCroy Broschüre). Sehr schön. Ich habe mal einen screendump von einer FFT angehängt. Eingang ist der Sonnenschirm als Antenne ;-) > Zu Deiner zerschossenen USB-Schnittstelle: Poste das doch noch mal im > Hardwarethread, eigentlich müßte doch nur das Flash fur den > USB-Controller neu geschrieben werden wenn ich mir das so überlege. Da > waren doch schon einige aktiv glaube ich. Werde ich mal machen. Mit RS232 komme ich aber gut aus. Schneller ist die sowieso... > Und zu guter Letzt finde ich es prima dass Du wieder aktiv dabei bist, > nachdem ich einige Zeit nichts mehr von Dir gehört hatte. Ich habe mich jetzt wieder hineingefunden und werde das Scope eine Weile nicht zum Arbeiten brauchen. Als erste Fleißarbeit habe ich meine neue Baustelle aufgeräumt:
1 | char charTOlMenuKey[]={ |
2 | // 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xA 0xB 0xC 0xD 0xE 0xF
|
3 | -1, -1, -1, -1, -1, -1, -1, -1, -11, -12, -10, -1, -1, -1, -1, -1, |
4 | // 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F
|
5 | -1, -1, -1, -1, -1, -1, -1, -1, -11, -12, -10, -1, -1, -1, -1, -1, |
6 | // ' ' '!' '"' '#' '$' '%' '&' ''' '(' ')' '*' '+' ',' '-' '.' '/'
|
7 | -2, 80, 81, -1, 83, 84, 85, -1, 87, 88, -1, -1, 69, 71, 70, 86, |
8 | // '0' '1' '2' '3' '4' '5' '6' '7' '8' '9' ':' ';' '<' '=' '>' '?'
|
9 | 39, 30, 31, 32, 33, 34, 35, 36, 37, 38, 68, 67,-127, 89,-127,-127, |
10 | // '@' 'A' 'B' 'C' 'D' 'E' 'F' 'G' 'H' 'I' 'J' 'K' 'L' 'M' 'N' 'O'
|
11 | -1, 50, 64, 62, 52, 42, 53, 54, 55, 47, 56, 57, 58, 66, 65, 48, |
12 | // 'P' 'Q' 'R' 'S' 'T' 'U' 'V' 'W' 'X' 'Y' 'Z' '[' '\' ']' '^' '_'
|
13 | 49, 40, 43, 51, 44, 46, 63, 41, 61, 60, 45,-127,-127,-127,-127,-127, |
14 | // '`' 'a' 'b' 'c' 'd' 'e' 'f' 'g' 'h' 'i' 'j' 'k' 'l' 'm' 'n' 'o'
|
15 | -1, 0, 10, 16, 5, 14, 7, 23, 55, 1, 2, 3, 4, 13, 22, 26, |
16 | // 'p' 'q' 'r' 's' 't' 'u' 'v' 'w' 'x' 'y' 'z' '{' '|' '}' '~' DEL
|
17 | 15, 19, 9, 8, 12, 6, 21, 20, 27, 17, 29, -1, -1, -1, -1, -1}; |
Spart fast 100 Zeilen Code. Gruß, Falk
>Sehr schön. Ich habe mal einen screendump von einer FFT angehängt. >Eingang ist der Sonnenschirm als Antenne ;-) Coole Idee ;-) >Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim >nächsten Oszi Start dann wieder weg? Die ist beim nächsten Start wieder weg. Aber trotzdem vorsicht, da die Firmware trotzdem Einstellungen in den Flash speichert. Also vorher auf alle Fälle einen Backup ziehen. Da ist eine Sicherung der Config-Bereichs mit dabei. Ich würde mir Perl installieren. Der WelecUpdater ist schnarch langsam. Ob .ram damit überhaupt geht, hat glaube ich, keiner mehr ausprobiert. Gruß, Stefan
Falk Willberg schrieb: ... > Das diff für den PC-Teil bezieht sich auf die Version 0.2, wenn Niklas > den entsprechend einpflegen könnte? Hier das diff-file für 0.3. Falk
Michael schrieb: > ich würde auch gerne mal Eure neue FW testen, bevor ich allerdings etwas > kaputt mache, will ich vorher nochmal kurz nachfragen. Beides eine gute Idee... allerdings steht eigentlich so ziemlich alles in den Beipackzetteln die ich mit dazugetan habe. Trotzdem hier schnell noch ein Antwort auf Deine Fragen. > Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim > nächsten Oszi Start dann wieder weg? So ist es. Aber wie Stefan schon anmerkte - die neue Version verwaltet die im Flash abgelegten Daten etwas anders. D.h. beim nächsten Start der alten Software kann es merkwürdige Nebenwirkungen geben, die sich jedoch mit Default Setup beheben lassen sollten. Auf jeden Fall solltest Du Dir mit dem Welecupdater ein Backup Deines Flash machen - Anleitung dazu liegt im Doku Ordner der Betaversion. > Kann ich das unter Windows einfach mit der WelecUpdater.exe machen? Nein! Der Welecupdater kann es nicht, und zwar einfach deswegen nicht, weil er die Endung .ram nicht unterstützt. Du müßtest die TomCat.ram einfach nur umbenennen in TomCat.flash (aber nicht mit der Richtigen verwechseln ;-) ), dann sollte es gehen. > Oder muss ich mir vorher nen Perl-Interpreter zulegen, > damit ich das mit dem Skript machen kann? Wenn Du das öfter machen möchtest, kann ich das nur dringend empfehlen, da der Unterschied 20 Minuten zu 3 Minuten doch schon gewaltig ist. Gruß und viel Spaß Hayo
@Falk
> Als erste Fleißarbeit habe ich meine neue Baustelle aufgeräumt:
Sehr schön, wenn wir so weitermachen schrumpft das File noch unter 1,2
MByte trotz neuer Funktionen ;-)
Auf jeden Fall wird der Code langsam immer übersichtlicher und
strukturierter.
Gruß Hayo
Hallo, nachdem ich euren Thread jetzt eine Weile verfolgt habe, habe ich mir auch ein Welec bestellt, das nächste Woche eintrudeln müsste. Zur Zeit bin ich noch im Prüfungsstress, danach möchte ich mich aber auch an der Verbesserung des Gerätes beteiligen. Achja, was mir noch aufgefallen ist: können die Dinger wirklich nur bis zu 5V/div nach oben? Mein jetziges Oszi lässt sich auf bis zu 50V/div schrauben und zumindest 10V/div und 20V/div habe ich auch schon desöfteren benutzt. Mir fehlt noch der Überblick über Hard-/Software des Welec - kann man die Messbereiche noch hinzufügen oder steht dem etwas entgegen? Viele Grüße, Michael
Man nehme einen 10:1 Tastkopf und gut. So machen es auch die Agilents. Man kann im Menü auswählen, was für eine Probe dran ist (auch A/div usw...)
Hayo W. schrieb: > @Daniel > SFN könnte man natürlich machen, aber ich fand das immer recht zäh und > langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit > eigene Foren einzurichten ist natürlich nicht übel. Erstmal gehts ja nur um das Forum. Das ist ein phpBB und entspricht somit wohl dem de-facto-Standard für Forensoftware. Die Antwortzeit ist wesentlich besser als bei diesen Mega-Threads hier im Forum > Zudem bestünde wohl auch die Möglichkeit überlaufende Threads in > regelmäßigen Abständen zu archvieren und zu bereinigen, so dass nicht > immer neue Treads nötig sind. Das können wir bei SF auch. Da gibts vollen Zugriff auf die übliche phpBB-Administration. Allerdings sollte sowas garnicht nötig sein, denn meiner Meinung nach sollte für das, wofür hier Threads verwendet werden, im phpBB ein Unterforum angelegt werden, in dem dann für unterschiedliche Gedankengänge unterschiedliche Threads genutzt werden ;) Aber das ist sicherlich Geschmackssache (des Moderators =) > Ich habe da jetzt einfach mal einen Thread zum Thema screendump > aufgemacht. > Wenn sich das nicht bewährt, kann ich auch ein Forum bereitstellen. Wenn überhaupt sollten wir einfach mal beschließen, das eine oder das andere Board zu benutzen und dann hier "Schilder" aufstellen ähnlich (wie im alten Welec-Thread, dass nun hier und im HW-Thread gepostet werden soll), dass Diskussionen in Zukunft woanders stattfinden sollen. Ich möchte nicht noch eine weitere Aufspaltung auslösen (wie schon mit dem Google Groups Kram).
Angehängte Dateien:
-
dump.jpeg
37 KB
Aktuelles: - Die Option -c <serial-port> geht auch unter Linux - Mit einer kleinen Firmwareänderung wird der Dump vom Programm gestartet - Man kann die Option "-m" für einen monochromen screendump angeben (10s) - Mit "-d" werden die Daten als CSV ausgegeben (7s). - Ohne Optionen -c oder -m wird ein farbiger screendump ausgegeben (30s) Die entsprechenden Patches kommen morgen... Die Grafik zeigt die Ausgabe, die "kst" aus dem CSV-file erzeugt. Falk
Daniel H. schrieb: > Wenn überhaupt sollten wir einfach mal beschließen, das eine oder das > andere Board zu benutzen und dann hier "Schilder" aufstellen ähnlich > (wie im alten Welec-Thread, dass nun hier und im HW-Thread gepostet > werden soll), dass Diskussionen in Zukunft woanders stattfinden sollen. Gute Idee. Ich werde meine Änderungen künftig in SFNET ablegen und hier darauf hinweisen. Dieses Forum ist nicht schlecht, aber mit Themen, Unterthemen etc. ist SFNET einfach besser geeignet. > Ich möchte nicht noch eine weitere Aufspaltung auslösen (wie schon mit > dem Google Groups Kram). Ich werde den Google-Groups-Kram bald zumachen und einen Hinweis hierhin und nach SFNET anbringen (wenn ich herausfinde, wie das geht). Falk
@Stefan Nur kurz zur Abstimmung, ich habe die vertikalen Cursordaten korrigiert, so dass jetzt alle Spannungen korrekt angezeigt werden -> void Display::CALCCURSORDATA(void) Hayo
@Stefan Nochmal kurz zur Abstimmung - ich schmeiße die bei einigen Anzeigefunktionen die sich wiederholenden switch() Anweisungen raus und ersetze sie durch indizierten array fetch. -> Display::MEASURETIME(), CALCCURSORDATA(), CALCPRETRIGGER(), CALCTIMEBASE() Hayo
Angehängte Dateien:
-
kst-fft.jpeg
63 KB
Die Diffs für die Firmware und screenshot-0.3 findet Ihr hier: https://sourceforge.net/apps/phpbb/welecw2000a/download/file.php?id=8 Das Bild ist aus "kst" mit dessen FFT. Statt kHz sollte das MHz heißen...
Niklas O. schrieb: Hallo Niklas, > @Kurt: > [Nicht alle Planes uebertragen] > > Daran hab' ich auch schon gedacht. In der Tat sind ein paar der 16 > Planes ueberhaupt gar nicht benutzt, zudem kann man wie Du beschreibst > noch weitere ausschlieszen. Da das DSO ohnehin da "Ewigkeiten" > pro Plane braucht liesze sich da deutlich Zeit einsparen. Im aktuellen Stand werden ja so weit ich das überblicke sämtliche Planes übertragen und dann auf dem PC genauso wie auf dem Oszi mit Farben versehen und übereinandergelegt. Bei der Übetragung der Planes geht viel Zeit drauf. Wäre folgender Weg nicht besser? Beispiel für drei Planes (A, B, C) wobei A die oberste (dominante) Plane ist: Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der Wert "1" gemerkt/übertragen. Wenn der Pixel in Plane A nicht gesetzt ist wird geprüft, ob der Pixel in Plane B gesetzt ist. Wenn ja, dann erhält dieser Pixel den Wert "2" und wird gemerkt (bzw. übertragen). Wenn der Pixel auch in Plane B nicht gesetzt ist, dann wird Plane C geprüft. Wenn der Pixel hier gesetzt ist, erhält dieser Pixel den Wert "3" wenn nicht, erhält der Pixel den Wert "0" (für transparent bzw. schwarz). Das Bild, das übertragen wird, entspricht dann 1:1 dem auf dem Oszi dargestellten Bild und die zu übertragende Datenmenge reduziert sich auf ein Viertel, da nun pro Pixel (bei 16 Planes) statt bisher 16 Bits (1 pro Plane) nur noch vier Bits (2^4 == 16 Planes) übertragen werden müssen. RLE funktioniert hier natürlich immer noch, da man ja statt einzelner Bits auch 4-Bit Sequenzen zusammenfassen kann. Auch auf dem Oszi dürft sich auch einiges an Laufzeit sparen lassen. Für das Überlagern der Planes im Oszi geht zwar etwas Zeit drauf, aber statistisch müssen nur noch 50% der Plane-Daten gelesen werden, da die "hinteren" Planes nach einem Match gar nicht mehr gelesen werden müssen. Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben, aber schnelle Screenshots sind noch schöner. Gruß, Bernd
Bernd O. schrieb: > > Hallo Niklas, Ich bin zwar nicht Niklas, habe aber seine Routinen bearbeitet. ... > Beispiel für drei Planes (A, B, C) wobei A die oberste (dominante) Plane > ist: > > Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt > ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der > Wert "1" gemerkt/übertragen. Wenn der Pixel in Plane A nicht gesetzt ist > wird geprüft, ob der Pixel in Plane B gesetzt ist. Wenn ja, dann erhält > dieser Pixel den Wert "2" und wird gemerkt (bzw. übertragen). ... Klingt gut! Sollte sich einfach implementieren lassen. > Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben, > aber schnelle Screenshots sind noch schöner. Auf 30s sind wir schon, mit Deinem Vorschlag könnte das noch schneller werden. Ich muß jetzt mal das protected flash zurückspielen :-( aber dann gucke ich mal... Gruß, Falk
Hallo Hayo, die Änderungen gehen klar. Muss ich dadurch was an den QM-Funktionen ändern? Magst du dir mal einen SVN-Client zulegen. Dann würde ein Klick reichen und alle hätten gleich die aktuellste Version. Geht, wenn einmal eingestellt, auch mit SourceForge "relativ" fix. Gruß, Stefan
Hmm, wahrscheinlich oute ich mich jetzt als Trottel, aber was ist SVN? Das VN steht vermutlich für virtual network oder? Gruß Hayo
SubVersioN, Versionsverwaltungstool, müsste unter Linux eigentlich installiert sein, unter Windows ist Tortoise momentan eine gute Wahl... Michel
Danke, ich mach mich da mal schlau und guck mal was sich machen läßt Gruß Hayo
Leider gibt es, meiner Meinung nach, unter Linux keinen wirklich perfekten Client wie z.B. Tortoise unter Windows. Bei mit leistet "eSVN" noch am wenigsten Widerstand. KSVN geht bei mir mit SF nur sehr träge. Gruß, Stefan
Stefan E. schrieb: > Leider gibt es, meiner Meinung nach, unter Linux keinen wirklich > perfekten Client wie z.B. Tortoise unter Windows. Im alltäglichen Umgang braucht man eigentlich nur eine Handvoll Kommandos: svn checkout svn update svn status svn commit svn add damit sind 95% aller Tätigkeiten abgedeckt. Dafür kann man gut, auch als nicht Kommandozeilen-Freund, mit der Kommandozeile leben. Gruß, Günter
Falk Willberg schrieb: > Ich muß jetzt mal das protected flash zurückspielen :-( aber dann gucke > ich mal... Leider hilft ein Flash-Update nicht gegen kalte Lötstellen oder Wackelkontakte. Jedenfalls startet die Firmware nur noch bis
1 | +S80484AA00CD |
2 | beta firmware starting! |
3 | |
4 | - Flash initialization - done |
5 | 2-Channels found Signatur : 98013000 |
6 | Keyboard found |
7 | Setup hardware - done |
8 | HW Version : 8c7 Channels : 2 |
9 | Testing LEDs |
10 | Building trigonometric tables - done |
11 | Setup vars - done |
12 | Setup vars to default values - done |
13 | Flash not loaded - setting standards |
14 | Read config from flash - done |
15 | Read protected config from flash - done |
16 | Recalc vars - done |
17 | - Hardware initialization - done |
18 | ******************************************************************
|
19 | calculating timebase... |
20 | timeoff = Timebase_Offset_Pos * tfactor / 1000000 |
21 | |
22 | Timeoffset = -0.000000300 |
23 | Timebase_Offset_Pos = -300 |
24 | tfactor = 0.00000000100 |
25 | ******************************************************************
|
26 | |
27 | spurious interrupt number: ................. |
Ein wenig ans Gehäuse zu klopfen hat das Problem kurzfristig lösen können. Der GERMS-Monitor funktioniert aber noch. Schön, wenn man drei Jahre Garantie hat :-) Falk
Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ? Einen Logic-Analyzer hab' ich zwar bereits, aber der ist PC-basiert und oft möchte man einfach nur mal kurz einen Datenstrom verifizieren; da würden die 2-4 Kanäle -je nach Protokoll- völlig ausreichen...
@Stefan, Ich habe das gerade im Hardware Thread gepostet =)
Na geil. Ich gebe zu, dass ich mich durch die Anfrage von Hayo inspiriert sah. Die Idee schwirrte mir schon so lange im Kopf rum, dass es wohl einfach nur eines Triggers bedufte.
@Stefan finde ich auch gut :-) @ 0.82 funktioniert bei mir (W2024A) :-) Was mir auch noch aufgefallen ist: Wenn ich "Search Zero Lines" drücke, wandern die Kanäle 3 und4 ein paar Pixel nach unten. ?! erst nach "calibrate DAC" sind sie wieder in der Mitte .. Ist das bei Euch auch so ? Leider schaut das 1kHz Signal bei 1ms/div noch immer so aus wie bei 200ms/div Vielleicht wäre es sinnvoll, dieses Problem voranging zu beheben, damit man damit auch richtig messen kann .( "Quick Meas" zeigt dann 3,84Hz an ) Bei 1ms/div zeigt es mit "Quick Meas" richtig die 1kHz an :-) Und ein Großes Lob und DANKE, an alle die hier so toll mitarbeiten!! l.G. Roberto
@Roberto Was du bemängelst (und misst) ist das typische Antialiasing das bei allen DSO's auftritt. Es ist dem Anwender überlassen die richtige Zeitbasis einzustellen (wenn das Signal nicht bekannt ist einfach mit einer möglichst hohen sample-rate beginnen und runtergehen bis das Signal richtig dargestellt wird). Martin
>Leider schaut das 1kHz Signal bei 1ms/div noch immer so aus wie bei >200ms/div >Vielleicht wäre es sinnvoll, dieses Problem voranging zu beheben, damit >man damit auch richtig messen kann Das ist nur eine "optische Täuschung" (Aliasing), die durch das Abtasten bei zu geringer Frequenz entsteht.
Unter Linux habe ich die besten Erfahrungen mit "rapidsvn" (http://rapidsvn.tigris.org/) gemacht. Ist aber denke ich bei jedem unterschiedlich. Svn selbst ist ziemlich cool, hat aber den Nachteil, dass es auf Client-Seite das doppelte an Speicherplatz für die Sourcen braucht.
PS: "svn diff" als Befehl auf der Kommandozeile ist auch sehr nett. Damit kann mensch eine Projektbetreiber seine Änderungen schicken, wenn mensch selbst keinen Schreibzugriff auf das Repository hat.
Hat eigentlich noch keiner bemerkt, dass das XY-Grid nicht eingeblendet wird bei der 0.82? Macht nichts ist schon gefixed. Hayo
Hab gerade die 1.2.82 eingespielt. Funktioniert leider erstmal gar nicht gut. Im Math Menü habe ich beim FFT-Softkey ein Rufzeichen drinnen. Wen ich in ein anderes Menü wechsle bleibt dieses Rufzeichen erhalten. Zusätzlich im Softkey "1+2" ein paar Artefakte. Das Math-Menü reagiert bei mir gar nicht. Auf keinen Tastendruck. Wenn ich "Quick-Print" drücke hängt sich das Oszi komplett auf. Es geht gar nichts mehr. Die violette Math-Linie, die angezeigt wird sobald der Math-Modus aktiv ist, durchbricht Menüs. Zb das Quick-Measure Menü. Wobei das eher ein Minor Bug ist. Ich denke, das Beste ist wenn ich den Komplett-Dump neu einspiele. lg Robert
@Robert Wenn sich das Problem durch Default Setup, Drehen an der Timebase und Neustart nicht beheben läßt, ist das Einspielen eines Dumps in der Tat die beste Lösung. Bei mir war das auch schon mal nötig, danach ist dann aber alles wieder in Ordnung. Hayo
Robert S. schrieb: ... > Wenn ich "Quick-Print" drücke hängt sich das Oszi komplett auf. Es geht > gar nichts mehr. Das ist normal, sollte aber nach ca. 30s vorbei sein. Falk
@Falk
> spurious interrupt number: .................
die gleiche Fehlermeldung hatte ich beim versehentlichen Überschreiben
des Stacks als ich eine Assemblerroutine mit falschen Parametern
versorgt habe. Bist Du sicher, dass es sich um einen Hardwarefehler
handelt?
Hayo
Hallo, Da ich auf meinem Windowsrechner keinen Platz für ein zweites Betriebssystem habe konnte ich bisher den Source nicht selbst compilieren. Jetzt habe ich jedoch auf dem ftp server von altera die cygwin version des compiler's gefunden! (in der Version 3.2) Mit dem ist es möglich auch unter Windows an der SW Entwicklung mit zu machen. Anbei eine kleine Anleitung in englisch (sicherlich noch verbesserungswürdig). Martin
Hi Martin, das ist cool, dann kann ich auch im Urlaub in Italien weiterentwickeln, mein Lappy hat nämlich nur Windows drauf (meine Frau wird mich steinigen). Ich werde das mal nach Deiner Anleitung versuchen. Gruß Hayo
Wenn deine Frau den ersten Stein aufhebt, dann mach' ihr klar, wie viele arme kleine Wittig User sie ins Unglück stürzen würde. Vielleicht lässt sie dich dann uns zu liebe am Leben und zielt nur auf Körperteile, die nicht zur Firmwareentwicklung benötigt werden...
Hey, trifft sich super. Mach mer doch gleich ne Session in Italien ;-) Gruß, Stefan
Kurze Anfrage zum Organisatorischen: Nachdem jetzt Google.Groups geschlossen ist, wo kann ich außer hier noch das komplette Firmwarepaket hochladen? Gibt es da auf SFN eine Möglichkeit? Hayo
Ja, die gibt es. Ich habe dir mal die Berechtigungen gesetzt, damit du Releases erstellen kannst. Hier ist alles erläutert: http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download Falls es nicht klappen sollte, können wir das ja mal zusammen durchgehen, Skype-Daten von mir sind ja überall zu finden. Bin allerdings erst morgen abend wieder richtig zugegen (Prüfungsstress). Konkrete Fragen kann ich sonst auch hier oder per Mail/PN beantworten.
Hallo werte Gemeinde, ab sofort gibt es die aktuellen Open Source Releases hier: https://sourceforge.net/projects/welecw2000a/files/ Zur Zeit ist noch die 0.82 das aktuelle beta Release, aber das Nächste ist schon in Arbeit und kommt hoffentlich zum Ende der Woche. Gruß Hayo
Hallo, ist ja einiges in den letzten paar Tagen in meiner Abwesenheit passiert :) @Falk: Hab' Deine Patches gesehen und werde die die naechsten Tage migrieren, wohl gar direkt ins SourceForge SVN Repository, wenn ich das richtig sehe das ihr euch entschlossen habt dieses zu nutzen. Schoen das wir jetzt auf 30 Sekunden sind. Wobei sich mir jetzt die Frage stellt, ob da nicht auch die auf 1/8 reduzierten Funktionsaufrufe etwas dazu beigetragen haben (die Komplexitaet ist ja an sich etwas gestiegen). Hast Du schonmal probiert, aus der RLE Funktion ein Makro zu machen? (ich gehe mal ungeprueft davon aus dass der GCC die Funktion nicht inlined) @Bernd: Das was Du beschreibst ist in etwa das was bei dem S/W Dump passiert, nur wird dort dann gleich auch noch die Farbe/dominante Plane mit weg geworfen. Zeitlich waren das trotzdem noch iirc. 10-15 Sekunden allein an Rechenzeit. Ansonsten gebe ich Dir wie Falk auch Recht. Die Frage ist, ob jetzt Falks Verbesserungen plus Planes aussparen (wie Kurt vorschlug) schneller waere oder Dein Neuansatz. Erstere (alte) Loesung waere flexibler und bereits implementiert, von daher wuerde ich, sollte letztere nicht schneller sein, dabei bleiben. @Falk: Hast Du da diesbzgl. in der Zwischenzeit schon weiter gemacht? Niklas
> Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für > typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ? Aber sicher wäre das Klasse!!
Jürgen schrieb: >> Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für >> typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ? > > Aber sicher wäre das Klasse!! Ich finde die Idee auch gut, aber das sollten wir erstmal auf der Wishlist unterbringen und die Realisierung erst dann vornehmen wenn wir vom beta Status weg sind. Gruß Hayo
@Niklas Die diffs von Falk werde ich in die nächste Beta einpatchen. Vielleicht kann ja jemand eine aktuelle Windowsversion (.exe) bereitstellen, da dann die alten Programme nicht mehr kompatibel sind zum Datenformat. Ich werde meine Releases wie gehabt als Komplettpaket bereitstellen nur jetzt mit der SFN Releaseverwaltung Gruß Hayo
Niklas O. schrieb: ... > @Falk: > Hab' Deine Patches gesehen und werde die die naechsten > Tage migrieren, wohl gar direkt ins SourceForge SVN > Repository, wenn ich das richtig sehe das ihr euch > entschlossen habt dieses zu nutzen. > > Schoen das wir jetzt auf 30 Sekunden sind. Wobei sich mir > jetzt die Frage stellt, ob da nicht auch die auf 1/8 reduzierten > Funktionsaufrufe etwas dazu beigetragen haben (die Komplexitaet > ist ja an sich etwas gestiegen). Das frage ich mich auch. Leider habe ich keine Informationen, welche Operationen, wieviel Last erzeugen. Im Standardfall (Sehr viele gleiche Bytes), passiert aber ca. 60.000-mal nicht anderes als ein increment und ein 16-Bit Vergeich. > Hast Du schonmal probiert, > aus der RLE Funktion ein Makro zu machen? (ich gehe mal > ungeprueft davon aus dass der GCC die Funktion nicht inlined) Das dürfte die Code-Größe gewaltig steigern (640*480-mal die RLE-Funktion...) > @Bernd: > Das was Du beschreibst ist in etwa das was bei dem S/W Dump > passiert, nur wird dort dann gleich auch noch die Farbe/dominante > Plane mit weg geworfen. Zeitlich waren das trotzdem noch > iirc. 10-15 Sekunden allein an Rechenzeit. Ansonsten gebe ich Dir > wie Falk auch Recht. Die Frage ist, ob jetzt Falks > Verbesserungen plus Planes aussparen (wie Kurt vorschlug) > schneller waere oder Dein Neuansatz. Wenn ich das richtig sehe, müssen wir einfach die Nummer der ersten Plane mit gesetztem Pixel (4 Bit) statt eines Bits übertragen. Ist simpel zu implementieren. Evtl. muß die Reihenfolge der Planes in der Definition geändert werden. > Erstere (alte) Loesung > waere flexibler und bereits implementiert, von daher wuerde > ich, sollte letztere nicht schneller sein, dabei bleiben. > @Falk: Hast Du da diesbzgl. in der Zwischenzeit schon > weiter gemacht? Leider ist mein Scope defekt. Das geht morgen erstmal zur Reparatur. Ich sage Bescheid, wenn ich weitermachen kann, bis dahin lasse ich den Kram in Ruhe. Inzwischen mache ich mich auch mit SVN vertraut. Vielleicht bastele ich inzwischen ein ppm2splashlogo.pl ;-) Falk P.S.: Ich finde es prima, daß wieder mehr Leute dazu beitragen, ein Scope so zu verbessern, daß Anwenderwünsche direkt berücksichtigt werden können.
Hallo Hayo, > Die diffs von Falk werde ich in die nächste Beta einpatchen. Vielleicht > kann ja jemand eine aktuelle Windowsversion (.exe) bereitstellen, da > dann die alten Programme nicht mehr kompatibel sind zum Datenformat. Ja das werde ich machen. Den Sourcecode fuer die Tools wuerde ich dann unter pc/screenshot/ einpflegen. > Ich werde meine Releases wie gehabt als Komplettpaket bereitstellen > nur jetzt mit der SFN Releaseverwaltung D.h., (noch) nicht den Sourcecode im SVN Repository pflegen? Haette den Vorteil das wir alle direkt Aenderungen committen koennten ohne dass Du die selbst einbauen muesstest. Damit man sich nicht in die Quere kommt koennten wir noch Branches machen, aber im Moment sollten wir auch ohne auskommen. Oben wurden ja schon ein paar SVN-Clients genannt. Ich faend's super wenn wir uns darauf einigen koennten das SVN zu nutzen. Kleine Bugfixes und Verbesserungen wie zuletzt das charTOlMenuKey Array von Falk waeren so sofort eingebaut und auch von allen Interessierten noch vor dem naechsten offiziellen Release getestet. Ich koennte auch etwas wie einen automatischen "Nightly Build" bereit stellen, also eine fertige Firmware die den aktuellen Stand im Repository wiederspiegelt. Niklas
Hallo Falk, >> Hast Du schonmal probiert, >> aus der RLE Funktion ein Makro zu machen? (ich gehe mal >> ungeprueft davon aus dass der GCC die Funktion nicht inlined) > Das dürfte die Code-Größe gewaltig steigern (640*480-mal die > RLE-Funktion...) Stimmt, bloede Idee. (auch wenn man das auf 640*480/8 runter dreht noch...) >> @Bernd: >> Das was Du beschreibst ist in etwa das was bei dem S/W Dump >> passiert, nur wird dort dann gleich auch noch die Farbe/dominante >> Plane mit weg geworfen. Zeitlich waren das trotzdem noch >> iirc. 10-15 Sekunden allein an Rechenzeit. [..] > > Wenn ich das richtig sehe, müssen wir einfach die Nummer der ersten > Plane mit gesetztem Pixel (4 Bit) statt eines Bits übertragen. Ist > simpel zu implementieren. Evtl. muß die Reihenfolge der Planes in der > Definition geändert werden. Ja, stimme ich Dir zu. Waere 'ne simple Modifikation der B/W Funktion, baue ich mal ein. > Leider ist mein Scope defekt. Das geht morgen erstmal zur Reparatur. :/ Bin mal gespannt wie der Service bei Wittig ist. Niklas
Mit SVN muß ich mich erst noch näher auseinander setzen. Da ich momentan einiges zu tun hatte und gleichzeitig am nächsten Release dran war hatte ich da keine Zeit für. Deine Lösung mit dem Nightly Build klingt ganz Interessant, denn mir ging es in erster Linie darum nicht nur die Entwickler mit dem neuesten Stand zu versorgen, sondern auch den Benutzern die Gelegenheit zu geben die aktuellsten Versionen auszuprobieren. Weiterhin möchte ich auch vermeiden meinen Verwaltungsoverhead zu groß werden zu lassen um möglichst viel Zeit für die Entwicklung zu nutzen. Gruß Hayo
Angehängte Dateien:
-
Vinculum.jpg
34 KB
Hallo Zusammen, ich arbeite gerade an einer "Hardwarelösung" für die Screenshots. Die Platine enhällt: ATMega32/644, VNC1L, MAX232, 64kBit FRAM, SUB-D Anschlüsse für Oszi und PC, USB Anschlüsse für Stick und Oszi und eine Pinleiste um den Vinculum das erste mal zu programmieren. Größe ist 80x80mm einseitig mit einigen Brücken. Ich werde noch Layout und Schaltplan etwas überarbeiten und dann hier reinstellen. Allerding befürchte ich, das der Vinculum etwas schwierig zu löten ist. Sollte das Konzept funktionieren kann man aber immer noch auf ein fertiges Modul ausweichen. Der Flaschenhals ist definitiv nicht auf der Platine sondern die lahme RS232 vom Oszi. Mfg, Kurt
Moinsen allerseits, wenn man hier ein paar Tage nicht reinschaut hat man ganz schön was zu lesen. Respekt vor dem Elan mit dem hier gewerkelt wird... Noch eine Tipp zu Subversion-Clients: ich kann jedem nur aller wärmstens eclipse ans Herz legen. Nicht nur, dass es die Entwicklung massiv vereinfacht, es bringt auch einen sehr brauchbaren SVN-Client (Subversive) mit. Viel Spaß weiterhin. Beste Grüße, odic
Hallo Kurt, na deine Platine sieht ja echt gut aus. Vielleicht sollten wir, wenn feststeht das die Schaltung funktioniert, auch dafür eine professionelle Lösung in Betracht ziehen? Bei den meisten dieser "Produkte" drückt eine Herstellung von 30...50 Stck. ganz massiv den Preis. Ich hätte da auf jeden Fall Interesse dran. Gruß, brunowe P.S.: mit Eagle3D gemacht?
Hallo Bruno, ja, mit Eagle 3D. Auch ja zur Professionellen Lösung. Leiterbahnen mit 8mil und Abstände mit 11mil sind nicht für jeden einfach zu ätzen. Außerdem soll die Platine später kleiner und doppelseitig werden damit man die Versorgungsspannungen ordentlich routen kann.
Sehr interessante Erweiterung, die dürfte weggehen wie warme Semmeln (ich bin z.B. ein Doppelabnehmer). Daher denke ich sollte eine größere Auflage zu Gunsten des Preises kein Problem sein. Was Anderes: Um die ToDo-Liste zu komplettieren bin ich mal in Gedanken die wichtigsten Funktionen des DSO durchgegangen, dabei ist mir aufgefallen, dass ich noch nie die Speicherfunktion für die Signale benutzt habe. Hat das schon jemand ausprobiert? Ist das ein Feature das ausnahmsweise mal einfach so funktioniert, oder müssen wir da auch das Baustellenschild aufstellen? Gruß Hayo
Hallo Hayo, die Save/Recall Sachen funktionieren bei der Original-Firmware einigermaszen, habe ich schon oefters benutzt wenn ich z.B. Signale vergleichen wollte. Dummerweise konnte ich die dann allerdings nicht mehr mit der Welec Originalsoftware vom Oszi holen, da wurde einfach eine neue Signalfolge aufgenommen. Auch kann man die Funktion nutzen um Kanal- und Zeitachsen- einstellungen zu sichern, die werden naemlich gleich mit wiederhergestellt. Bei der Beta-Firmware scheint da aber genau gar nichts zu funktionieren. Habe da sehr absurde Effekte. Genau genommen ist wohl Reboot faellig nach einem Save gefolgt von Recall, in benutzbaren Zustand habe ich mein Geraet zumindest nicht wieder versetzt bekommen. Waere schoen wenn wir das zum Laufen bekaemen, habe mich da aber noch nicht umgeschaut. Vermutlich werden die ADC-Daten samt Parameter abgelegt und einfach neu gerendert, oder? Die iirc. 80 Speicherplaetze die da Wittig vorgesehen hat sind aber IMHO etwas uebertrieben. Vllt. koennen wir das auch aufteilen, d.h., Recall Trace und Recal Settings. BTW: Hast Du meine Nachricht auf SF wg. Devel schon gesehen? Niklas
Ich kann da nichts finden, wo muß ich suchen? Hayo
Hallo Hayo, mhm, muesstest egtl. die SF E-Mails an Deine Adresse geforwardet bekommen. Ging nur darum dass Du mich (niklas_olmes auf SF) als Devel zum Projekt hinzufuegst. Geht mit "Project Admin->Membership" eingeloggt unter https://sourceforge.net/projects/welecw2000a/develop Niklas
Ich hab mir die Save/Recall-Geschichte mal angesehen, ich glaube es liegt an den geänderten Parametern die im Flash abgelegt werden, da kann ich bei Gelegenheit mal beigehen. Hayo
Hallo, wenn sich einer dranmacht an der Save/ Recall Funktion rum zu basteln, dann sollte man direkt den Vorschlag von stendres aus der SF Wishlist mit einfließen lassen. Halte ich für nen guten Vorschlag. http://sourceforge.net/apps/trac/welecw2000a/wiki/FWwishlist Gruß, brunowe
Hallo Bruno, ja, das waere in der Tat sehr nuetzlich. Koennte man dazu einfach die (scheinbar) unbenutzten Memory-Planes hernehmen? Sind allerdings nur drei. Wo ich gerade die Wishlist sehe finde ich den ersten Vorschlag von michelwernersen auch wichtig. Da ich (noch) die Original-Firmware im Flash habe und die aktuelle Beta ins RAM lade bin ich staendig am Justieren. Das liesze sich sicher recht einfach realisieren, ich werde da spaeter mal drueber schauen. Niklas
Stefan E. schrieb: > Hallo Hayo, > > die Änderungen gehen klar. Muss ich dadurch was an den QM-Funktionen > ändern? Magst du dir mal einen SVN-Client zulegen. Dann würde ein Klick > reichen und alle hätten gleich die aktuellste Version. Geht, wenn einmal > eingestellt, auch mit SourceForge "relativ" fix. Ich hab's mal ausprobiert:
1 | svn checkout https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/welec/improved/ improved |
Jetzt finde ich in src/ die Sourcen, aber auch src/src und src/quickmeasure.. "make" in src/ übersetzt die "alten" Sourcen und faällt mit
1 | src/hardware_t.cpp:427: invalid types `int[int]' for array subscript |
auf die Nase. Wer kann einem SVN-Anfänger mal das Brett vom Kopf nehmen? Außerdem scheint mir, daß es eine gute Idee wäre, die Dateien weiter aufzuteilen. So könnte der PC-Kommunikationsteil doch in "pc-comms.[cpp|h]" ausgelagert werden. Gruß, Falk
Hallo Falk, die doppelten/dreifachen Sourcen siehst nicht nur Du :) Der letzte committete Stand scheint 0.80 zu sein. Hayo hat selbst ja noch nichts eingepflegt. Mit
1 | $ svn log $file |
kannst Du Dir die Commit Messages der Revisions anschauen, bei der die angegebene Datei betroffen ist. Mit
1 | $ svn diff -r113 src/hardware_t.cpp |
siehst Du die Aenderungen seit Revision 113 (und warum es nicht kompiliert). (Wenn Du die Datei hinten weglaesst siehst Du den ganzen Diff.) Warum da jetzt mehrfach Sourcen rumliegen weisz ich nicht, die Logmessage dazu besagt "creating new brachn for QM". Sieht fuer mich nach nem Unfall aus, da ich sonst aber mit CVS und GIT vertraut bin will ich mich nicht festlegen, kann auch nen Feature sein ;) Wir sollten IMHO erstmal hergehen und den aktuellen Versionsstand (0.82) einmal sauber importieren. Ansonsten, nochmal Kurzeinweisung fuer Falk:
1 | <0>[18:28]niklas@empire:/tmp/improved$ cat > src/newfile |
2 | Inhalt
|
3 | <0>[18:28]niklas@empire:/tmp/improved$ svn add src/newfile |
4 | A src/newfile
|
5 | <0>[18:28]niklas@empire:/tmp/improved$ svn diff |
6 | Index: src/newfile
|
7 | ===================================================================
|
8 | --- src/newfile (revision 0)
|
9 | +++ src/newfile (revision 0)
|
10 | @@ -0,0 +1 @@
|
11 | +Inhalt
|
12 | <0>[18:28]niklas@empire:/tmp/improved$ svn status |
13 | A src/newfile
|
Mit svn commit wuerdest Du den Kram abschicken, wirst dabei noch um eine Logmessage als Beschreibung gebeten. Die restlichen Kommandos erklaert Dir svn help gerne :) Niklas
Hallo, jo der src-Order unter src ist ein Unfall ;-) Muss ich mal versuchen, wieder zu löschen. Der QM-Ordner sollte eigentlich mein Branch werden, in dem ich die QM-Funktion ändere und dann später wieder in die anderen sourcen einpflege. Ich komme selber noch nicht ganz mit svn zurecht. Also net gleich schlagen ;-) Vielleicht gibts ja hier einen, der das mal so aufräumt, wie es sich gehört.
@ Kurt: Falls du einen Prototyp bei LeitOn mach lassen willst, ich habe noch einen 10€ Gutschein. Den kannst du haben.
hat denn schon mal jemand das compilieren unter windows getestet? ich hab es nicht hin bekommen. es kommt folgende meldung ># 2009.07.08.19:37:21 --- Compiling nios-elf-gcc -I ./inc -I ./src -I ./inc >-I . >/inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 >-D_Debug_ > src/TomCat.cpp -o obj/TomCat.cpp.o >process_begin: CreateProcess(NULL, nios-elf-gcc -I ./inc -I ./src -I ./inc >-I .. >/inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 >src/TomCat >.cpp -o obj/TomCat.cpp.o, ...) failed. >make (e=2): Das System kann die angegebene Datei nicht finden. >make: *** [obj/TomCat.cpp.o] Error 2 er findet also die tomcat.cpp.o nicht. kann er auch nicht weil die noch gar nicht existiert. hat jemand einen tip? gruß sunny
Stefan E. schrieb: > Hallo, > > jo der src-Order unter src ist ein Unfall ;-) Muss ich mal versuchen, > wieder zu löschen. Könnte ich mit ksvn vielleicht schaffen. Die Dateien sind sowieso alle identisch. > Der QM-Ordner sollte eigentlich mein Branch werden, in dem ich die > QM-Funktion ändere und dann später wieder in die anderen sourcen > einpflege. > > Ich komme selber noch nicht ganz mit svn zurecht. Also net gleich > schlagen ;-) Schade, hatte den Knüppel gerade geputzt ;-) Stattdessen habe ich Version 0.4 von w2000a-screenshot committed. Vielleicht hat das ja geklappt... Falk
sunny schrieb: > hat denn schon mal jemand das compilieren unter windows getestet? ich > hab es nicht hin bekommen. es kommt folgende meldung ... >>make (e=2): Das System kann die angegebene Datei nicht finden. >>make: *** [obj/TomCat.cpp.o] Error 2 > er findet also die tomcat.cpp.o nicht. kann er auch nicht weil die noch > gar nicht existiert. hat jemand einen tip? Er findet nicht die tomcat.cpp.o nicht (die will er ja gerade erzeugen), sondern die includes unter inc/. Die findest Du da: https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/welec/improved/inc/ Hat mich auch eine Weile gekostet, das herauszufinden. Falk
die .inc datein sind aber da. im \inc verzeichniss. ich habe den kompletten build aus dem svn gezogen und nach c:\build entpackt. dann das makefile geändert und die umgebungsvariablen gesetzt. wie genau (name,wert) hast du denn bei dir die umgebungsvariablen gesetzt? gruß sunny
sunny schrieb: > die .inc datein sind aber da. im \inc verzeichniss. > ich habe den kompletten build aus dem svn gezogen und nach c:\build > entpackt. dann das makefile geändert und die umgebungsvariablen gesetzt. > wie genau (name,wert) hast du denn bei dir die umgebungsvariablen > gesetzt? Ich habe nichts setzen müssen. Ich hatte die gleiche Fehlermeldung wie Du, aber unter Linux. Da mußte ich nur das .../inc besorgen, make eingeben und es lief... Vielleicht meldet sich noch ein Windows-User... Falk
unter linux funktioniert es bei mir auch. ist nur unpraktisch weil ich linux nur af dem satreciver laufen hab. vielleicht hat ja noch jemand einen tip zum compilieren windows. gruß sunny
Hallo sunny, ev. fehlen nur die Standardheader wie stdio.h u.ä. Die müsste die Umgebung liefern und dementsprechend müsste das Makefile geändert oder Umgebungsvariablen gesetzt werden. Das wäre jetzt aber mal wirklich ein Anlass für einen neuen Thread. ;-) Gruß, Guido
>ev. fehlen nur die Standardheader wie stdio.h u.ä. Die müsste die >Umgebung liefern ja, tut sie auch die sind in einem unterverzeichniss >dementsprechend müsste das Makefile geändert >oder Umgebungsvariablen gesetzt werden. da müsste man halt nur wissen wie und wo. >Das wäre jetzt aber mal wirklich ein Anlass für einen neuen Thread. ;-) ach, so wichtig ist es nun auch wieder nicht. hätte ja sein können das es schon einer hinbekommen hat. gruß sunny
Hallo sunny,
suche halt die Standardheader und ergänze im Makefile unter
"INCLUDE_PATHS = \" noch
-I /wo_sind_die Standardheader\
Das musste ich unter Ubuntu auch machen, da war es /usr/include.
Gruß, Guido
Hallo, so, habe gerade zu spaeter Stunde die 0.82 von Hayo sauber in fpga/firmware importiert und Falks letztes Diff eingespielt. Sollte so wie es da liegt und ausgecheckt werden kann kompilieren. Das obj/ Verzeichnis wird automatisch angelegt. fpga/welec/official habe ich entsorgt. Etwaige Aenderungen in fpga/welec/src und/oder fpga/welec/src/src usw. ;) muessten noch manuell uebertragen werden. Z.B. ueber
1 | <0>[23:46]niklas@empire:/tmp/W/welecw2000a/fpga/welec$ diff -u ../firmware/src/ improved/src/ | less |
schauen was noch relevant ist und uebertragen. @Falk: Das diff-Format ist bissl komisch gewesen, wie hast Du das erzeugt? Da fehlten die Header damit patch(1) den Kram alleine ohne manuelle Angabe jeder Datei findet. diff -uNr (u fuer unified, N fuer include new files, ggfls. weglassen, r fuer rekursiv, auch ggfls. weglassen) ist ganz okay. Andere Sache: Wo wir jetzt schon mal das Format fuer die Ausgabe geaendert haben und auch noch Messwerte rausschreiben koennen waere IMHO nen kleiner Header nuetzlich, der besagt was kommt und in welcher Version das ist. Also statt 'S' 0xff am Anfang koennten wir machen 'S' p v 0xff, Rest beibehalten. Wobei p Protokoll/Anwendung ist, z.B. 0x01 fuer Screenshot, 0x02 fuer Messdaten. V waere die Version. Das Ausleseprogramm koennte dann entsprechend handeln. Niklas
Hallo nochmal, @Falk: Den selben Gedanken mit dem Header hattest Du schon sehe ich erst jetzt gerade :) Sorry. Niklas
>so, habe gerade zu spaeter Stunde die 0.82 von Hayo sauber >in fpga/firmware importiert und Falks letztes Diff eingespielt. >Sollte so wie es da liegt und ausgecheckt werden kann kompilieren. Sollte auch davor möglich gewesen sein, die Sourcen zu kompilieren. War eigentlich auf dem aktuellen Stand. Bis auf der zweite src-Ordner, der ein Versehen war. Jetzt liegt es irgendwie bescheuert, da nich klar ist, für welches FPGA-Design die Firmware gedacht ist. Gruß, Stefan
Angehängte Dateien:
-
1kHz_auf_Agilent.jpg
640 KB
Hallo (Martin) >Was du bemängelst (und misst) ist das typische Antialiasing das bei >allen DSO's auftritt. Es ist dem Anwender überlassen die richtige >Zeitbasis einzustellen (wenn das Signal nicht bekannt ist einfach mit >einer möglichst hohen sample-rate beginnen und runtergehen bis das >Signal richtig dargestellt wird). Habe mal einen Freund gebeten, ein 1kHz Signal mit seinem Agilent Infiniium 54831B, 4Kanal, 600Mhz, 4Gsa aufzunehmen... Schaut schon viel besser aus! Bilder : links oben mit 200us/div bis rechts unten mit 500ms/div Vermutlich schaut das durch den grösseren Speicher besser aus?! Versuch gerade das mit der Abtastrate und dem Speicher zu verstehen... Stimmen da meine Rechnungen? Bei 1ms/div = 250kSa/s -> = 12ms pro Bild würde ich auf 3000 Samples kommen? Bei 200us/div = 1MSA/s -> = 2,4mS pro Bild --> 2400 Samples? Hat das Welec DSO nicht 16KB/ Kanal? (oder denke ich da irgendwie falsch?) l.G. Roberto
Hallo Roberto, Ist etwas unfair einen Rolls Royce mit einem Fiat zu vergleichen! Aber zu deiner frage: Die Darstellung hangt von der Samplerate ab, beim Welec (das uebrigens nur 4KB Samplespeicher hat) ist die bei 500ms/div nur 500Samples/Sekunde, bei dieser Samplerate kann ein 1kHz Signal natuerlich nicht mehr richtig dargestellt werden (niquist sagt das die sample rate mindestens doppelt so hoch sein muss wie die hoechste Eingangsfrequenz, und ein Rechtecksignal enthaelt nicht nur die 1kHz sondern auch oberwellen). Das Agilent hat 2MB Samplespeicher und kann daher bei 500ms/div mit 400kSamples/Sekunde samplen! Martin
Niklas O. schrieb: > Hallo, ... > @Falk: > Das diff-Format ist bissl komisch gewesen, wie hast Du das erzeugt? > Da fehlten die Header damit patch(1) den Kram alleine ohne manuelle > Angabe jeder Datei findet. Ich hatte einfach "diff" benutzt und manuell nacheditiert. Mit svn brauchen wir das ja nicht mehr. Ich habe übrigens den PC-Teil nach https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/ hochgeladen und ihn Version 0.4 genannt. Falk
@Roberto Die Sampletiefe ist immer 16k. Aber die real verfügbare Sampletiefe hängt vom Darstellungsfaktor ab. Den Zusammenhang hatte ich weiter oben schon mal im Zusammenhang mit Aliasing erklärt. Die genauen Zusammenhänge entnimmst Du der Timebasetabelle in den Programming Maps, die Du hier findest: http://groups.google.com/group/welec-dso/files Hayo
Angehängte Dateien:
-
dump.png
12 KB
Hayo W. schrieb: > @Roberto > > Die Sampletiefe ist immer 16k. Aber die real verfügbare Sampletiefe > hängt vom Darstellungsfaktor ab. Den Zusammenhang hatte ich weiter oben > schon mal im Zusammenhang mit Aliasing erklärt. Hatte ich nicht verstanden ;-) Für die Dump-Funktion ist es auch nur wichtig, ob es sinnvoll ist, immer die 16KB auszulesen. Mein letzter Dump ist hier zu finden: https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/example.csv.gz Was bei 500MS/s herauszuholen ist, sieht man hier: https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/FFT-from-dump.png Falk
Sag mal Falk, wie machst Du eigentlich diese schicken Bilder? Hast Du da ein Datenauswertungsprogramm das Diagramme erstellt? Hayo
Hayo W. schrieb: > Sag mal Falk, > > wie machst Du eigentlich diese schicken Bilder? Hast Du da ein > Datenauswertungsprogramm das Diagramme erstellt? Ja: http://kst.kde.org/ Damit mache ich die meisten Auswertungen von geloggten Daten. Falk
Falk Willberg schrieb: > Für die Dump-Funktion ist es auch nur wichtig, ob es sinnvoll ist, immer > die 16KB auszulesen. Kommt drauf an was man damit machen will. Für die Rekonstruktion das Bildschirmbildes reicht weniger. Um selbiges zu rekonstruieren muß man verschiedene Parameter kennen: - mit welchem Offset beginnt das aktuelle Memory Window - welcher Faktor wird verwendet (Timebasetabelle) Bsp.: der Offset liegt bei 400, mit dem Faktor 5. Dann müßte die Übertragung beginnend beim 400sten Wert jeden 5. Wert übertragen und zwar so viele wie das Grid breit ist (600 char Werte) D.h. ausgewertet wird der Bereich von 400 - 3400 Ein Sonderfall sind die Ultra Slow Time-Bases, und die interpolierten TB da die Daten hier in separaten Speicherbereichen abgelegt sind und auch ohne Offset mit Faktor 1 ausgewertet werden. Gruß Hayo
Hallo, @Stefan: tut mir Leid, das mit Deiner Namensgebung erschlieszt sich mir erst jetzt mit Deiner Erklaerung. Wobei das irgendwie auch bloed ist, dass da sowohl C Code fuer den Nios Softcore und VHDL vermischt liegt. Koennte man (wenn man nicht wuesste dass Welec das Design nicht hergeben will/kann wegen fremder IP) auch so intepretieren, dass fpga/welec/improved das verbesserte Design enthaelt. Der Pfad sagt ja nicht aus, ob es sich da um Softcore Code oder VHDL-Design handelt. "Firmware" erschien mir da logischer, ohne natuerlich wie Du schon richtig klarstellst zu beachten, dass es ja parallel eine zweite Entwicklungslinie gibt. Ich stelle mal die Frage in den Raum was man da tun sollte. Da die importierte 0.82 Deine (@Stefan) Aenderungen enthaelt kann fpga/firmware/ jetzt als aktuell angesehen werden. doc/ und tools/ von fpga/welec/improved/ kann noch uebernommen werden oder, vllt. besser, die PDFs koennten (wenn nicht schon getan) im Wiki verlinkt werden. @Falk: [PC-Teil] Hab' ich gestern noch gesehen und schon etwas rumgefummelt. Ich hoffe es ist okay das ich Deinen Code insbes. bzgl. Conditionals ungefragt neu eingerueckt habe, da sich die Ebenen fuer mich einfach nicht mehr entschlossen. Was ich noch einbauen wollte war die -l Loop Funktion, angeregt durch das Standard-Verhalten der Windows-Versionen von Kurt, wo automatisch eine neue Datei mit aufsteigender Nummerierung erzeugt wurde. Zudem noch eine kurze deutschsprachige Anleitung. Dann kann Hayo den Sourcecode und die Windows-.EXE ja vllt. kuenftig in seinen Releases direkt mitfuehren. kst ist btw. sieht ja wirklich schick aus, muss ich auch mal ausprobieren. Ich haette jetzt einfach das diesbzgl. unhandlichere gnuplot hergenommen. Niklas
Niklas O. schrieb: > Hallo, ... > @Falk: > [PC-Teil] > Hab' ich gestern noch gesehen und schon etwas rumgefummelt. > Ich hoffe es ist okay das ich Deinen Code insbes. bzgl. > Conditionals ungefragt neu eingerueckt habe, da sich > die Ebenen fuer mich einfach nicht mehr entschlossen. Kein Problem. Schön, daß Du die Fehlerbehandlung eingebaut hast. Ich sollte vielleicht aufhören, nach dem Motto zu verfahren "wenn es kompiliert, gib's frei, wenn es nicht läuft, versuche -Wall" ;-) Falk, derzeit Sope-los...
@Niklas Da die ganze Versionsgeschichte hier im Augenblick etwas unübersichtlich ist eine schnelle Frage: Die Source die Du in SFN abgelegt hast ist schon auf dem neuesten gepatchten Stand, korrekt? D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen, auch korrekt? Nicht dass ich im nächsten Release den falschen Zwischenstand drin hab. Zur Windows .exe - klar, die kann ich mit ins Release-Package tun. Gruß Hayo
@Sunny ich hatte auch solches Problem bei Kompilieren unter Windows. Das Problem war nur falsche cygwin version. Ganze Quartus zu installieren ist ja mühsam nur für richtige cygwin version zum kriegen. Als Anhang ist abgespeckte cygwin von Quartus II 41sp2 und registry patch Gruß Ben
Hallo Hayo, > Die Source die Du in SFN abgelegt hast ist schon auf dem neuesten > gepatchten Stand, korrekt? Ja, genau. Ganz konkret ist's: BlueFlash_Build_0_62.zip + FW1.2.BF.0.82_beta.zip + FW1.2.BF.0.82_beta-dl3daz.diff (aus Beitrag "Screendumps" ) - *~ (vi (u.a.) Backup Files), obj/, WelecUpdater (ist woanders im SVN), usw. (GERMSloader.pl ist jedoch drin, kann Hannes entscheiden ob er das im SVN verwalten will, woanders hinschieben usw.. Bzgl. der WelecUpdater.exe: Die sollte in den Files/Releases Bereich, da sie ja aus den Sourcen erzeugt werden kann und statisch ist. Gleiches fuer die Windows Screenshot.exe. Oder wir sparen das und wir tun sie allein in die Firmware-Releases.) > D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen, > auch korrekt? Ja, genau. Niklas
Da die Screenshot.exe unter Umständen (so wie jetzt) nur zu dem jeweiligen Release passen, ist es eigentlich keine schlechte Idee sie mit ins Paket zu tun, dann gibts keinen Frust wegen inkompatibler Versionen. Hayo
@Falk & Niklas Wenn ich das so richtig mitverfolge, ist ja auch ein reiner Datendownload in Arbeit. Hier hatte ich ja mal die Idee geäußert auf vorhandene PC-Software zurückzugreifen und das Datenformat auf DSO-Seite entsprechend anzupassen. Das hätte den Vorteil, dass man das Rad nicht zweimal erfinden müßte. Ich denke da sowohl an Open Source Programme für verschiedene andere DSOs als auch evtl. Programme von den DSO-Herstellern, sofern das Datenformat bekannt ist. Wie ist denn da Eure Meinung? Bzw. @all Wer kennt denn evtl. entspechende Programme? Hayo
Hallo Hayo, >D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen, auch >korrekt? >Nicht dass ich im nächsten Release den falschen Zwischenstand drin hab. ...und was ist mit dem XY-Grid - Patch? War nach der 0.82! Oder hab ich etwa eine Beta verpasst? Gruß Jürgen
Mal eine Frage an die Experten: Wenn zwei Leute gleichzeitig bspw. die Datei display_t.cpp bearbeiten, kann es doch beim Commit zu Kollisionen kommen. Oder irre ich? Ich denke, wir sollten die gigantischen Monolithen sinnvoll in möglichst kleine Files aufteilen. Ich würde das übernehmen, wenn ich damit nicht hintenherum etwas anderes umwerfe... @Niklas: was hat es mit src/display_t_bak.cpp und src/fft/ auf sich? Beim kompilieren werden die nicht angefasst... @Hayo: Ich halte es für eine gute Idee, das Datenformat für die PC-Kommunikation von einem anderen Scope zu kopieren, wenn es dafür ordentliche Software gibt, die auch unter Linux läuft. Ich habe nur keine Idee, welches geeignet sein könnte. Falk
@Jürgen der XY-Grid Patch ist in der 0.83, die aber noch nicht released ist, da die neu aufgesetzte FFT noch unfertig ist. Mir ging es darum die gepatchte 0.82 mit meiner 0.83 abzugleichen bevor ich die jetzt zum Wochenende raushaue. Vielleicht sollte ich mit dem Abgleich auch noch bis zum Schluß warten falls noch Patches dazukommen. Gruß Hayo
@Falk Mit dem Aufteilen warte mal bis wir auf einem konsolidierten Stand sind, d.h. wenn ich die 0.83 released habe. Dann können wir einen kurzen Entwicklungsstop machen und das Organisatorische klären. Sonst gibt es ein heilloses durcheinander von Versionen, die nicht zueinander passen. Bei solch umfangreichen Änderungen müssen wir einen sauberen Schnitt machen, da ja auch die Versionierung im SFN sonst nicht mehr korrekt ist. Hayo
Moin moin, melde mich von der ersten Klausur des Semesters erfolgreich zurück ;) Bzgl. SVN: Ich hatte hier: https://sourceforge.net/apps/trac/welecw2000a/wiki/Repository mal angefangen, die Struktur des Repositories zu dokumentieren. Ist nicht ganz aktuell wie ich gerade sehe, aber vll könnt ihr euch auch dran halten bzw. eure Zweige dort grob benennen. Die Struktur könnte noch optimiert werden, da es ja mittlerweile euren Branch gibt der auf dem NIOS basiert und auch noch den Kram von Slog, wobei ich bezweifle, dass da mal wieder was passiert... Ach ja, und die Originalsourcen... Was mir aufgefallen ist ist dass der ein oder andere Commit der letzten Tage gut hätte zusammengefasst werden können, statt pro Datei ein Changeset zu machen. Man kann also durchaus mehrere Dateien in einem Rutsch (und mit einer gemeinsamen Lognachricht) einchecken. Aber ich glaube das habt ihr nun auch bemerkt ;) Was die Sache mit dem src/src/ Ordner angeht: Wenn ich die Logs richtig im Kopf habe, sollte das ne "Branch" zum Entwickeln werden. Dazu vielleicht noch ein paar Worte: 1) Wenns geht, würde ich persönlich das Branch&merge gebastel bei SVN lieber vermeiden. Hab schon diversen Kram mit SVNs versioniert und bin auch bei größeren Gruppen nicht in die Verlegenheit gekommen, sowas zu machen. Aber wenn's jemanden gibt, der das Merging am Ende voll drauf hat, nur zu ;) 2) SVN unterscheidet nicht zwischen Branching, Tagging und Kopieren. Alles geschieht mittels svn copy, also sowohl release-tags anlegen als auch branching ist letztlich nix anderes als ne Kopie. Wobei Serverseitig natürlich nix dupliziert wird, solange es keine Änderungen gibt. Das mal im Hinterkopf behalten, wenn gebranched wird. Es empfielt sich also, eine Struktur anzulegen, wie man das in vielen öffentlichen SVN sieht, also "branches/ tags/ trunk/"-Ordner, wobei Trunk natürlich der Hauptentwicklungszweig ist. Da wir hier mehrere parallele Projekte in einem Repo haben, sollte jedes Unterprojekt in seinem Unterprojekt-Ordner sowas anlegen. 3) ... hab ich gerade vergessen. Naja Vortrag beendet ;) LG
Hayo W. schrieb: > @Falk > > Mit dem Aufteilen warte mal bis wir auf einem konsolidierten Stand sind, > d.h. wenn ich die 0.83 released habe. Dann können wir einen kurzen > Entwicklungsstop machen und das Organisatorische klären. Sonst gibt es > ein heilloses durcheinander von Versionen, die nicht zueinander passen. > > Bei solch umfangreichen Änderungen müssen wir einen sauberen Schnitt > machen, da ja auch die Versionierung im SFN sonst nicht mehr korrekt > ist. Ok, ist das sinnvollste. Siehe auch Daniels Beitrag. Falk
Hallo, @Falk: > was hat es mit src/display_t_bak.cpp und src/fft/ auf sich? > Beim kompilieren werden die nicht angefasst... Die stammen offensichtlich aus dem 0.62. fft/ habe ich glatt uebersehen und ist dann wohl die alte FFT Implementation aus der 1.2. Beides kann dann weg. > Wenn zwei Leute gleichzeitig bspw. die Datei display_t.cpp bearbeiten, > kann es doch beim Commit zu Kollisionen kommen. Oder irre ich? Kann es, ja, in der Regel geht das aber gut wenn nicht gerade genau dieselbe Stelle im Code von beiden Bearbeitern modifiziert wird. Wenn die Software das Problem nicht selbst loesen kann (Im Falle von "Bearbeiter haben an verschiedenen auseinander liegenden Stellen was geaendert" kann sie das) wird der commit verweigert und man muss selbst Hand anlegen. Wie das bei SVN konkret ablaeuft kann ich Dir jetzt allerdings nicht sagen. Ich stimme Dir zu dass die Dateien teilweise wirklich gigantische Ausmasze haben und unuebersichtlich sind. Vom Standpunkt der Revisionsverwaltung muss das aber nicht unbedingt zu schweren Kollisionen fuehren wie gerade gesagt. Ich wuerde Deinem Vorhaben, da aufzuraeumen voll zustimmen. Da gerade Hayo aber schon an 0.83 dran war waere es aber sinnvoll, dass Hayo nen Diff zieht und wir (oder er) das direkt einspielen und Du erst dann aufteilst, so dass Hayo da spaeter nicht ein groszes Chaos hat. @Hayo: > Hier hatte ich ja mal die Idee geäußert auf vorhandene PC-Software > zurückzugreifen und das Datenformat auf DSO-Seite entsprechend > anzupassen. Das hätte den Vorteil, dass man das Rad nicht zweimal > erfinden müßte. Ich denke da sowohl an Open Source Programme für > verschiedene andere DSOs als auch evtl. Programme von den > DSO-Herstellern, sofern das Datenformat bekannt ist. Das sehe ich genau wie Falk und Du auch. Ich hatte auch schonmal nach Ausgabeformaten gefragt, leider kam diesbzgl. kein Vorschlag, ist vllt. auch unter gegangen in der Fuelle von Posts. Leider kenne ich keine anderen DSOs bzw. Programme dazu. Jeden Hinweis und Dokumentation gehe ich da gerne nach. Leider komme ich im Moment zeitlich noch nicht dazu die von mir angepeilten Dinge (Auto-Setup/Kalibrierung, -l in Screenshot Programm, usw.) zu realisieren. Wir haben aber ohnehin genug Baustellen. Wie sieht es btw. da nochmal mit einer immer aktuell gehaltenen Liste "wer arbeitet gerade woran" aus? SF Wiki waere da nun die praedestinierte Stelle. (btw: Irgendwie ist das ziemlich unpraktisch, wenn nur Admins die Hauptseite des Wikis aendern duerfen, so kann man nur versteckt in einer vorhanderen Unterseite eine neue Seite verlinken. Kann man das der Software irgendwie abgewoehnen?) Update/Edit: Hab' den Satz in Klammern bzgl. Kollisionen mal ausgeweitet damit klar wird, dass ich dort den automatisch loesbaren Fall meinte. Niklas
@Niklas Der FFT Ordner stammt von mir. Da hatte ich mir mal einige Beispielsourcen reinkopiert und dann den Ordner vergessen zu löschen - kann also weg. Ich hatte mal in der SFN Roadmap einige Entwicklungen eingetragen. Aktueller wärs natürlich wenn jeder seine momentanen Sachen selber einpflegt. Hayo
Niklas O. schrieb: > (btw: Irgendwie ist das ziemlich unpraktisch, wenn nur Admins > die Hauptseite des Wikis aendern duerfen, so kann man nur versteckt > in einer vorhanderen Unterseite eine neue Seite verlinken. > Kann man das der Software irgendwie abgewoehnen?) Kann man, möchte ich aber nicht. Öfter mal bei letzten Projekt scheinbar automatisierten Frontpage-Vandalismus gehabt, deswegen die alte Gewohnheit, die Seite auf Read-Only zu sitzen. Wenn du mir dein Handle sagst, kannste gern die entsprechenden Bearbeitungsrechte bekommen. Wär vll ne gute Gelegenheit, erstmal die Developer-Tabelle im Wiki zu aktualisieren, damit der Überblick erhalten bleibt ;)
Hallo, @Hayo: Roadmap habe ich gefunden :) @Daniel: Merke gerade auch, dass ich manche andere Seiten auch nicht editieren kann (Developers, ...). Mein Handle entspricht meinem vollen Namen. Die Rechte beim Trac Wiki hab' ich noch nicht ganz verstanden. Kann man es so machen, dass alle eingetragenen und aktiven Developer/Members (die ja ohnehin manuell von einem Admin hinzugefuegt werden muesen und damit "geprueft" sind) entsprechende Rechte bekommen? Im Repository konnte ich direkt ohne weiteres "rumfuschen", btw.. Abgesehen davon, geht das nur mir so oder ist das Webinterface bei SF irgendwie ziemlich lahm? (hab' diverse Firefox Plugins (Ad-Blocker, NoScript, ...) die das bei mir ausbremsen koennten, daher frage ich mal) Niklas
SFN ist so lahm! Daher auch mein eher zögerlicher Zuspruch. Teilweise mußte ich pro Seitenaufbau 10s - 20s warten. Hayo
Hayo W. schrieb: > SFN ist so lahm! Daher auch mein eher zögerlicher Zuspruch. Teilweise > mußte ich pro Seitenaufbau 10s - 20s warten. Ist hier auch so... Einerseits gab es mehrere Angebote, einen eigenen Server aufzusetzen, andererseits gefällt mir, daß es nicht so viele verschiedene Orte gibt, an denen das Thema bearbeitet wird. Noch was: Wie wäre es mit Unterverzeichnissen .../FW1.2.BF.0.82/ ../FW1.2.BF.0.84/ etc? Falk
@Niklas: Rechte gesetzt. @Antwortzeit SF: Das schwankt bei mir stark, ist aber im Mittel gerade noch erträglich. Aber der Server bei SF ist unabhängig. Im letzten Projekt war plötzlich der Mensch mit dem Server nicht mehr erreichbar, nachdem kurz vorher alle Daten weg waren und plötzlich kein Backup existierte. Ob er sich geschämt hat? @Falk: Üblich für SVN wäre, wenn ihr in eurem "Hauptverzeichnis" unter trunk/ die jeweils aktuellen Sourcen hättet. Wenn dann ein Release herausgebracht wird, ist der erste Schritt, trunk/* nach tags/FW1.2.BF.0.xy/* zu kopieren. Im tags/ Ordner wird nie editiert, das dient ausschließlich der Konservierung von definierten Ständen. Falls ihr euere Ordnung dahingehend ändern wollt: mit svn move kann man das erledigen, ohne dass History verloren geht.
Daniel H. schrieb: ... > @Falk: Üblich für SVN wäre, wenn ihr in eurem "Hauptverzeichnis" unter > trunk/ die jeweils aktuellen Sourcen hättet. Wenn dann ein Release > herausgebracht wird, ist der erste Schritt, trunk/* nach > tags/FW1.2.BF.0.xy/* zu kopieren. Im tags/ Ordner wird nie editiert, das > dient ausschließlich der Konservierung von definierten Ständen. Falls > ihr euere Ordnung dahingehend ändern wollt: mit svn move kann man das > erledigen, ohne dass History verloren geht. Ich sehe schon, ich werde mich mal näher mit SVN beschäftigen müssen. Da ich derzeit kein Scope habe und anderes zu tun ist, halte ich mich aus der Software ein paar Tage lang heraus. Falk
http://svnbook.red-bean.com/ Edit: Die Antwortzeit von diesem Forum ist auch nicht kürzer als die bei SF.net ;)
@xCometz danke für deine hilfe. leider hat es mich nicht weiter gebracht. ich hatte zuvor selber schon etwas rumprobiert und bekahm daraufhin folgenden fehler # 2009.07.09.19:41:22 --- Compiling nios-elf-gcc -I ./inc -I ./src -I ./inc -I . ./inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 -D_Debug_ src/TomCat.cpp -o obj/TomCat.cpp.o Assembler messages: for reading.open : No such file or directory make: *** [obj/TomCat.cpp.o] Error 1 das einspielen deiner cygwin version hat da auch nichts daran geändert. trotzdem danke. gruß sunny
sunny schrieb: > @xCometz > danke für deine hilfe. leider hat es mich nicht weiter gebracht. > ich hatte zuvor selber schon etwas rumprobiert und bekahm daraufhin > folgenden fehler > # 2009.07.09.19:41:22 --- Compiling nios-elf-gcc -I ./inc -I ./src -I > ./inc -I . > ./inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 > -D_Debug_ > src/TomCat.cpp -o obj/TomCat.cpp.o > Assembler messages: > for reading.open > : No such file or directory Mhhh, irgendwie hätte ich da mehr als ":" erwartet.... Kannst Du mal
1 | nios-elf-gcc -v -I ./inc -I ./src -I ./inc -I ../inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 -D_Debug_ src/TomCat.cpp -o obj/TomCat.cpp.o |
versuchen? Mit "-v" sagst Du dem gcc, daß er mal erzählen soll, was er wirklich treibt. Hier (Linux) sieht das so aus:
1 | Reading specs from /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/specs |
2 | gcc version 2.9-nios-010801-20030923 |
3 | /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/cpp -lang-c++ -v -I ./inc -I ./src -I ./inc -I ../inc -I ../../inc -I ../../../inc -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=9 -D__cplusplus -D__nios__ -D__nios__ -Amachine(nios) -D__EXCEPTIONS -D__OPTIMIZE__ -g2 -W -D__nios32__ -D_Debug_ src/TomCat.cpp /tmp/ccI2Biu1.ii |
4 | GNU CPP version 2.9-nios-010801-20030923 (cpplib) |
5 | (nios) |
6 | ignoring nonexistent directory `../inc' |
7 | ignoring nonexistent directory `../../inc' |
8 | ignoring nonexistent directory `../../../inc' |
9 | ignoring nonexistent directory `/opt/cdk4nios/nios-elf/sys-include' |
10 | ignoring duplicate directory `inc' |
11 | #include "..." search starts here: |
12 | #include <...> search starts here: |
13 | inc
|
14 | src
|
15 | /opt/cdk4nios/include/g++-3 |
16 | /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/include |
17 | /opt/cdk4nios/nios-elf/include |
18 | End of search list. |
19 | /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/cc1plus /tmp/ccI2Biu1.ii -quiet -dumpbase TomCat.cc -mno-zero-extend -m32 -g2 -O2 -W -version -o /tmp/ccIHjI1U.s |
20 | GNU C++ version 2.9-nios-010801-20030923 (nios-elf) compiled by GNU C version 3.3.1 (Mandrake Linux 8.2 3.3.1-4mdk_slz). |
21 | /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/../../../../nios-elf/bin/as -m32 -o obj/TomCat.cpp.o /tmp/ccIHjI1U.s |
Falk P.S.: Wie wär's mit Linux in einer VirtualBox oder eigenen Partition?
hi falk der gcc sagt folgendes Reading specs from /cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-l ib/nios-elf/2.9-nios-010801-20030718/specs gcc version 2.9-nios-010801-20030718 /cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf /2.9-ni os-010801-20030718/cpp.exe -lang-c++ -v -I ./inc -I ./src -I ./inc -I ../inc -I ../../inc -I ../../../inc -iprefix /cygdrive/c/altera/kits/nios/bin/nios-gnupro/ bin/../lib/gcc-lib/nios-elf/2.9-nios-010801-20030718/ -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=9 -D__cplusplus -D__nios__ -D__nios__ -Amachine(nios) -D__EXCEP TIONS -D__OPTIMIZE__ -g2 -W -D__nios32__ -D_Debug_ src/TomCat.cpp /cygdrive/c/DO KUME~1/op/LOKALE~1/Temp/ccMyr3vG.ii GNU CPP version 2.9-nios-010801-20030718 (cpplib) (nios) ignoring nonexistent directory `../inc' ignoring nonexistent directory `../../inc' ignoring nonexistent directory `../../../inc' ignoring nonexistent directory `/cygdrive/c/altera/kits/nios/bin/nios-gnupro/inc lude/g++-3' ignoring nonexistent directory `/cygdrive/c/altera/kits/nios/bin/nios-gnupro/nio s-elf/sys-include' ignoring nonexistent directory `C:/nios_gnu_win32/nios_gnupro_win32_20030718_104 128/nios-gnupro/include/g++-3' ignoring nonexistent directory `C:/nios_gnu_win32/nios_gnupro_win32_20030718_104 128/nios-gnupro/lib/gcc-lib/nios-elf/2.9-nios-010801-20030718/include' ignoring nonexistent directory `C:/nios_gnu_win32/nios_gnupro_win32_20030718_104 128/nios-gnupro/nios-elf/sys-include' ignoring nonexistent directory `C:/nios_gnu_win32/nios_gnupro_win32_20030718_104 128/nios-gnupro/nios-elf/include' #include "..." search starts here: #include <...> search starts here: inc src inc /cygdrive/c/altera/kits/nios/bin/nios-gnupro/lib/gcc-lib/nios-elf/2.9-ni os-0108 01-20030718/include /cygdrive/c/altera/kits/nios/bin/nios-gnupro/nios-elf/include End of search list. /cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf /2.9-ni os-010801-20030718/cc1plus.exe /cygdrive/c/DOKUME~1/op/LOKALE~1/Temp/ccMyr3vG.ii -quiet -dumpbase TomCat.cc -mno-zero-extend -m32 -g2 -O2 -W -version -o /cygdri ve/c/DOKUME~1/op/LOKALE~1/Temp/ccaKz1Xj.s GNU C++ version 2.9-nios-010801-20030718 (nios-elf) compiled by GNU C version 2. 9-cygwin-990830. /cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf /2.9-ni os-010801-20030718/../../../../nios-elf/bin/as.exe Assembler messages: for reading.open : No such file or directory ich glaub aber das führt jetzt hier zu weit. ich dachte es ist nur irgend ein kleines problem. wenn es unter windows nicht geht ist es auch noch so. ich kann ja immer noch meinen satreciever misbrauchen. auf meinem laptop will ich mir kein linux installieren. es reicht mir schon wenn ich mich bei meinem reciever mit diesem linuxmist rumärgern muß. auf jeden fall danke für eure hilfe. gruß sunny
@Sunny Wie viele cygwin hast du im deinem PC? Bist du sicher dass du auf die richtige cygwin gelaufen hast? Es sieht wie falsche cygwin version aus wahrscheinlich einen falsche path search. Schau mal den Anhang Gruß, Ben
Ich habe den Eindruck, das SVN ist schwieriger zu verstehen als die Welec Firmware? @Robert, danke für das Angebot. Aber die Platine ist schon geätzt und bestückt. Es wird aber bestimmt einen zweiten Prototypen geben... Der Vinculum läuft auch schon einigermaßen. Jetzt muss ich mich etwas näher mit dem Befehlssatzt beschäftigen. Sobald die Kommunikation läuft, werden aus dem Schaltplan die letzten Fehler beseitigt und ich laden ihn hier hoch. Ein erstes kleines Beispieprojekt wird es dann auch geben. PS: Später ist auch eine RTC geplant damit die Dateien ein vernünftiges Datum und eine Uhrzeit haben.
@xCometz ich habe jetzt 2 cygwin auf meinem pc. einmal das was bei quartus mit dabei war und dann das von dir. ich hab es jetzt aber hin bekommen. es funktioniert nur wenn ich zuerst cygwin starte, dann in der cygwin konsole in mein build verzeichniss wechsle und make starte. danke noch mal gruß sunny
Angehängte Dateien:
-
Colordemo.jpeg
50 KB
Kurze Info für die Screenshot-Spezis. Im Rahmen einer Fehlersuche habe ich mal schnell eine Colordemo gebastelt. hier zu sehen sind alle angezeigten Planes (13 Stück, UI-Plane 2 ist schwarz). Die Memory-Planes werden in der Tat nicht angezeigt, ebenso wie die Buffer-Planes. Leider sieht man den Fehler den ich gesucht habe hier nicht. Dafür muß man kurz aus dem nächsten Beitrag...
...die TomCat.ram laden. Dann Sieht man den Fehler deutlich. Und zwar hat die UI-Plane 1 eine Macke (hatte Guido ja auch schon vermutet). Die gesamte Plane ist um 32 Pixel nach rechts verschoben, was dazu führt, dass die ersten 32 Pixel nicht gezeichnet werden, aber dafür die letzten 32 Pixel auf der rechten Seite durchgeschoben werden und um eine Zeile nach unten verschoben auf der linken Seite wieder rauskommen. Daher auch die komischen Linien bei dem ganz linken Funktions-Button. Hayo
Nachtrag: Es ist durchaus möglich, das dieser Fehler im VHDL-Design des FPGA liegt. Ich vermute mal, das die alternativen VHDL-Designs dieses Problem nicht haben?? Hayo
Hayo W. schrieb: > Es ist durchaus möglich, das dieser Fehler im VHDL-Design des FPGA > liegt. Ich vermute mal, das die alternativen VHDL-Designs dieses Problem > nicht haben?? Ich sehe keinen Grund, warum diese Plane-Geschichte in HW realisiert sein sollte... Das würde ja bedeuten, dass es sozusagen für jede Plane einen Framebuffern gäbe, also in getrennten Speicherbereichen? Ich hätte jetzt vermutet dass die in Software zusammengeführt werden, habe aber noch nicht in den Source geschaut. Wo steckt denn überhaupt der Framebuffer? Im SRAM oder im FPGA-Blockram? Kann man das evtl. an der Adressaufteilung sehen?
In der Firmware konnte ich den Fehler bislang noch nicht lokalisieren, in dem Bereich ist das Coding auch ziemlich unübersichtlich. Kann gut sein, dass es auch eine reine Softwaresache ist. ich bin noch nicht dazu gekommen zu prüfen ob das Problem auch bei der originalen FW1.4 auftritt. Wenn nicht, wäre die Frage geklärt. Hayo
Hallo, nö, ich glaube nicht, dass das von der Firmware kommt. Hab da ja schon mal länger rumprobiert inkl. Neuschreiben von DrawRoundButton und PixelP. @ Hayo: Wenn es eine Verschiebung wäre, ließe sie sich leicht korrigieren. Die 8, 16 und 32 Bit, waren es, wenn ich mich recht entsinne, aber nicht. Mein Verdacht war eher, dass im VHDL-Code zwei Adressbits für den Framebuffer vertauscht sind. Das war das letzte womit ich rumprobiert habe, denn auch das müsste man korrigieren können. Gru0ß, Guido
Ich hab jetzt erstmal in DrawRoundButton einen Workaround eingebaut, damit nicht die falsche Linie gezeichnet wird. Hayo
Angehängte Dateien:
-
FFT_NEU_03.jpeg
55 KB
So, für alle die um diese Urzeit auch noch vor dem Rechner sitzen ein kurzer Zwischenstand in Sachen FFT-Redesign. Anzubieten hätte ich diese Version...
Angehängte Dateien:
-
FFT_NEU_01.jpeg
62 KB
...oder diese. Welche erregt denn bei Euch mehr Wohlwollen? Die Cursorfunktion geht natürlich bei beiden. Hat jemand Verbesserungsvorschläge oder eine Idee welche Daten z.B. im Bereich Magnitude noch von Interesse wären? Gruß Hayo
DIe erste find ich hübscher. Hat es was zu sagen, dass da oben rechts Blackman und unten Rechteck steht? /Hannes
Einige Zeilen sind noch statisch um die Position richtig einzustellen, also keine Sorge... Hayo
Hallo Hayo, mir gefällt die zweite Version deutlich besser, nicht nur weil sie auch mit übermüdeten Augen noch ablesbar ist ;-), auch das Grid wirkt harmonischer. Magnitude in dBm ist zu ehrgeizig, da der Abschluss ja nicht gewährleistet ist. Besser db mit Bezugspunkt. Wenn aber Mag in dB oder dBm angegeben ist, sollte Delta-Y nicht in mV sein. Ich hoffe doch sehr, demnächst auch mal wieder einen Beitrag leisten zu können, aber es geht wirklich super voran. Gruß, Guido
Hayo W. schrieb: > ...oder diese. Welche erregt denn bei Euch mehr Wohlwollen? ^^^^^^ Diese (#2) erregt ähm, also, genau: mein Wohlwollen ;-) > Die Cursorfunktion geht natürlich bei beiden. Applaus! Falk
Also ich finde die untere vorallem wegen der Lesbarkeit besser. Koennte man denn auch beide kombinieren ?? Also obere Version mit den Farben der unteren. Ich finde das Subtile der schwarzen Version eigentlich auch nicht uebel aber das gelb halte ich fuer praktischer. Form follows function... ;)
Die Skalierung ist noch nicht ganz fertig. Das untere Bild zeigt aber schon die korrekten Cursorwerte in Volt. Die Anzeige im Abschnitt Magnitude ist nur eine statische Zeile für Testzwecke. So jetzt jetzt haben wir schon zwei Meinungen und natürlich genau gegensätzlich. Meine Meinung dazu ist noch etwas schwankend. Die Anzeige im ersten Bild ist etwas technischer gehalten und hat den Vorteil, dass sie in der Helligkeit mit dem Grid zusammen verstellt werden kann. Die zweite Version ist dafür etwas angenehmer abzulesen, weil die schwarze Schrift auf dem hellen Untergrund mehr Kontrast bietet. Nicht einfach zu entscheiden. Gruß Hayo
Oh, in der Zwischenzeit gibt es doch noch mehr Meinungen. Tendenz Richtung Version 2 wie ich feststelle. Hayo
Hallo Hayo, beide Versionen sehen echt gut aus! Top Arbeit. Die Erste ist etwas unaufdringlicher, die Schrift etwas schwer zu lesen- das mag im Original natürlich besser sein. Die zweite Vers. ist dafür einheitlicher. Würde eher zur Version 2 tendieren. Was noch an Info dazu sollte bzw. kann? Evtl. mal bei den renommierten Herstellern nachsehen, so spontan fällt mir nichts ein. Gruß, brunowe
Angehängte Dateien:
-
FFT_Modi.jpg
49 KB
Ja mir fiel so spontan auch nichts mehr ein. Sonst lasse ich das erst mal frei, da kommen bestimmt noch Vorschläge. Angeregt durch Deine Kommentare und die LeCroy Broschüre habe ich auch die FFT-Modi etwas aufgebohrt. Wir wollen ja schließlich nicht hinter LeCroy zurückstehen... ;-) Hayo
Sehr schoen, ich warte schon gespannt auf den naechsten Release und werde dann gruendlich Testen. Jedenfalls wenn ich bin dahin alle meine Pruefungen geschrieben habe. ;)
Hallo, ja Hayo du hast recht, wir sollten uns an der Spitze orientieren. Wenn das nicht klappt, verfahren wir getreu dem Wahlspruch: WO WIR SIND IST VORN... UND WENN WIR EINMAL HINTEN SIND, DANN IST HINTEN VORN! Gruß, brunowe
Das sieht ja wirklich klasse aus! Aufgrund der besseren Lesbarkeit finde ich die zweite Variante auch noch besser als die erste. Gruß,Michael
Es kommt wie es kommen muß: Ich habe beide Varianten dringelassen. Default ist die Variante 2. Über Shift + X kann die Variante 1 ein und ausgeschaltet werden. So kann sich jeder selbst eine Meinung bilden und das dann entsprechend einstellen. Hayo
Hier schon mal der vorläufige Schaltplan des Vinculum Boards. Über eine 3MBaud UART Verbindung zum Vinculum kann man mit ca. 112kByte/s auf den Stick schreiben. Getestet vom PC aus. Allerdings soll später der parallele FIFO zum Einsatz kommen. PS: LED3 und LED4 sind natürlich falschrum drin.
Hallo Kurt, Ich habe mir deinen Schaltplan angeschaut, und habe zwei kleine Anmerkungen: 1. Die last C's des 12MHz Quatz sollten 68pF sein (meiner Erfahrung nach ist der VNC1L hier recht empfiendlich). 2. Wenn du den FIFO mode nutzen willst ist es von Vorteil auch den PIN 45 (DATAREQ# in FIFO und SPI mode) von der CPU aus steuern zu koennen. Martin
Muss es eigentlich sein, dass der Trigger automatisch auf einen anderen Kanal gelegt wird, wenn der momentan den Trigger führende Kanal deaktiviert wird ? Ich finde das mehr als unpraktisch denn: - es kommt vor, dass man auf einen Kanal triggern, diesen aber zwecks Übersichtlichkeit nicht permanent darstellen möchte. Der kleine Bildschirm ist schon so voll genug :\ - triggert man auf Kanal 1 mit einer hohen Impulsfolge und womöglich mit einem hohen Signalpegel, sieht man von den anderen Kanälen nahezu nichts mehr, da das Gelb doch sehr dominant ist. Schaltet man nun Kanal 1 kurz aus, um sich einen Eindruck von den anderen Signalen zu verschaffen, ist sofort der Trigger flöten und man steht erst mal im Regen; bzw. fummelt wieder am Trigger rum bis es passt. Da die Triggermarke, bedingt durch die farbliche Darstellung am Rand, die Triggerquelle auch dann eindeutig anzeigt, wenn der Kanal deaktiviert ist, empfinde ich die Zwangsumschaltung als sehr lästig. Evtl. geht es ja dem einen oder anderen auch so... Stefan
Hallo, echt toll was ihr da Entwickelt. Was mir noch fehlt ist das Umschalten des Sampleverhalten. D.h. es wird immer mit der vollen Samplerate gemessen und im FPGA dann gleich auf die benötigte Samplerate heruntergerechnet. Professionelle Oszis können da: Peak (min und max der ADs wärend eines Erfassungstaktes) HiRes (Mittelwert der ADs wärend eines Erfassungstaktes) Sample (Nur 1. Wert der ADs wärend eines Erfassungstaktes) so ist es jetzt immer Average (HiRes und Mittelwert über mehrere Triger) Mfg Michael
Hallo Martin, die Kondensatorgeschichte scheint sehr abhängig vom Quarz zu sein. Bei mir läuft es mit 10pF ohne Probleme. Ich werde trotzdem im Schaltplan den Wert auf 22pF oder 47pF erhöhen. Wofür brauche ich denn den DATAREQ# Pin? Ich dachte mit dem schaltet man nur zwischen Data und Command Mode um. Kann aber auch angeschlossen werden. Der AVR hat noch genug Pins. Mfg, Kurt
Kurt, Der Kondensator haengt sowohl von dem Quarz als auch von dem Treiber / Eingang des IC's ab. Ich habe mit dem VNC1L boese Erfahrung gemacht, der Prototyp lief mit einem zu kleine C ohne Probleme, aber in der Serie hatte ich dann einige Baugruppen wo der Oszillator nicht immer an lief. Was DATAREQ# betrifft hast du recht wenn du nur den Pendrive verwenden willst ist er nicht noetig (wird fuer di Umschaltung von Kommandomodus in einen reinen Datenmodus verwendet, zum Beispiel fuer die Verbindung zu einem PC). Martin
Michael schrieb: > D.h. es wird immer mit der vollen Samplerate gemessen und im FPGA dann > gleich auf die benötigte Samplerate heruntergerechnet. Nein. es wird nicht immer mit der vollen Samplerate gemessen, sondern mit der angezeigten. Das weitere Herunterrechnen findet dann in der Firmware statt. Hayo
Angehängte Dateien:
-
5V.png
4,9 KB
Ich habe die aktuelle Firmware und das Problem, dass sich -je nach Messbereich- der negative Bereich der gemessenen Spannung verschiebt. Mache ich da etwas falsch oder kann ich dem Scope nicht mehr trauen ? Anbei zwei Bilder, es geht mir um Kanal 4 (Rot, Kanal steht auf DC)
DAC-Abgleich für alle Spannungsstufen (1V, 2V, 5V) einzeln durchgeführt?
Ist nicht Dein Ernst !? Und ich dachte, der DAC-Abgleich erledigt alle Einstellungen in einem Schwung. Aber Danke, das erklärt so manches.
Besteht evtl. die Möglichkeit, dass QuickMeassure im nächsten Update gefixed wird? Die Wahl des QM-Kanals via Menü wird leider erst übernommen, nachdem QM aus- und wieder eingeschaltet wurde. Btw: QM läuft ganz prima - vielen Dank !
Hallo, als frisch gebackener W2024A-Besitzer habe ich heute eure Firmware 0.82beta getestet und gleich eine Frage dazu. Ich habe den Abgleich von ADC bzw. DAC nach Anleitung gemacht, komme aber was den Abgleich der Nullinien angeht nicht zum gewünschten Ergebnis. Ich kann zwar den DAC z.B. für 5V, 2V und 1V kalibrieren, wenn ich dann aber den 500mV Bereich kalibriere verschiebt es den 5V Bereich wieder, bei 200mV den 2V u.s.w. Was mache ich falsch?
>Die Wahl des QM-Kanals via Menü wird leider erst >übernommen, nachdem QM aus- und wieder eingeschaltet wurde. Kann ich so leider nicht nachvollziehen. Bei mir klappt das alles einwandfrei. Mit Ausnahme der weiter oben genannten funktionen. Kannst du genauer beschreiben, was du nacheinander drückst und welche Einstellungen du verwendest? >Btw: QM läuft ganz prima - vielen Dank ! Danke für das Lob! Sollte sich tatsächlich noch ein Fehler in der Kanalwahl herausstellen, werde ich versuchen den noch zu beheben. Ansonsten wird es voraussichtlich erst wieder Mitte August Neuerungen von meiner Seite geben. Bis dahin wollen noch eine Reihe Klausuren bestanden werden und der Computer braucht dann so Anfang August mal zwei Wochen Ruhe ;-) Gruß, Stefan
Andreas schrieb: > Ist nicht Dein Ernst !? > Und ich dachte, der DAC-Abgleich erledigt alle Einstellungen in einem > Schwung. Aber Danke, das erklärt so manches. Im Paket der Beta FW ist eine Beschreibung wie man den Abgleich in der richtigen Reihenfolge macht. Die DAC-Kalibrierung läuft getrennt für die 1er 2er und 5er Bereiche. Hintergrund ist: 1. Ich wollte anfangs eine Möglichkeit haben das getrennt voneinander durchzuführen um nicht schon gut kalibrierte Bereiche wieder zu verschlechtern. 2. Die DAC-Kalibrierung ist als Ergänzung zu der ungenügenden original Kalibrierung zu sehen. 2. Jetzt funktioniert das eigentlich so gut, dass man auch alle in einem Durchgang kalibrieren könnte, hatte aber noch keine Zeit das zu implementieren. Wurde auch schon von anderer Seite angefragt. Werde ich mal mit den Prioritäten der anderen Baustellen abgleichen. Für alle neu Dazugestoßenen - die original FW war leider so schlecht geschrieben, dass es bei den anfänglich geringen Entwicklerkapazitäten nur langsam voran ging. Ich bitte daher noch nicht so perfekt funktionierende Bereiche zu entschuldigen. Dafür geht es jetzt bei der starken Beteiligung hier erheblich zügiger voran. Hayo
Hallo Hayo, kannst du dir erklären, warum bei mir die bereits kalibrierten Kanäle wieder verschoben werden, wenn ich andere kalibriere? Bin genau nach Anleitung vorgegangen, bekomme aber Nullinien die bis zu mehreren DIVs abweichen...
Du brauchst dich doch nicht zu entschuldigen :) Ich habe mir ueberhaupt erst ein solches Scope gekauft als ich gesehen habe was ihr hier veranstaltet. So einen Aufwand kann bei gott keiner erwarten und ich moechte mich nochmal in aller Form bei euch fuer das bis jetzt geleistete bedanken. Ich werde nach den Pruefungen auch sehen wie ich zu dem Projekt Beitragen kann. Leider hab ich noch 0 erfahrung mit Oszi-Programmierung, aber vielleicht kann man ja etwas Learning by Doing betreiben :) Ich schaue jedenfalls jeden Tag hier rein und fast immer wurde irgendwas verbessert. Wirklich super !!!
Ohh! Nein das höre ich zum ersten Mal. Bei meinen Geräten klappt das einwandfrei und auch die Anderen hier hatten das Problem nicht. Du sagst ja, Du hast das nach Anleitung gemacht und vorher alle Eingänge abgezogen oder kurzgeschlossen? Wenn nicht bekommt man nämlich genau diesen Fehler. Am besten macht man erstmal den ADC-Abgleich, da der nur einen relativen Vergleich der Pegel durchführt. Dann den originalen Search Zeros und zum Schluß als Feinschliff den DAC-Abgleich. Ach ja, ganz zu Anfang am Besten noch Default Setup, dann ist man auch gleich in der günstigsten Timebase für den Abgleich. Hayo
>Sollte sich tatsächlich noch ein Fehler in der Kanalwahl herausstellen,
werde ich versuchen den noch zu beheben.
Also wenn QM aktiv ist, kann man ja im dazu gehörigen QM-Menü den Kanal
wählen, den QM auswertet. Wählt man hier während der Messung einen
anderen Kanal, arbeitet QM trotzdem weiter auf dem bisherigen und
wechselt auf die geänderte Einstellung erst, nachdem man QM deaktiviert
und dann wieder aktiviert.
Mist, ich hasse solche Sonderrollen.... Also, - FW 0.82beta (compiliertes HEX-File aus dem Release-Archiv) liegt im Flash - Gerät ist warmgelaufen - alle Probes sind abgezogen Vorgehen: - "Default Settings" im "Edge" Menü => alle Kanäle sind an und im 5V-Bereich - einmal "Calibrate ADC" - einmal "Search Zero Lines" => Abweichungen von max. 0,2DIV in den 5V-Bereichen - "Calibrate DAC" => alles bestens im 5V Bereich - alle Kanäle auf 2V - "Calibrate DAC" => alles bestens im 2V Bereich - alle Kanäle auf 1V - "Calibrate DAC" => alles bestens im 1V Bereich - Kontrolle => alles bestens in den Bereichen 1V, 2V und 5V - selbes Vorgehen für 500mV, 200mV und 100mV => Nullinien der Kanäle sind in den Bereichen 1V, 2V und 5V wieder bis ca. 1 DIV verschoben - selbes Vorgehen für 50mV, 20mV und 10mV => Nullinien der Kanäle sind in den Bereichen 1V, 2V und 5V wieder bis > 8 DIV verschoben Insgesamt sind die Verschiebungen auf Kanal 1+3 nur gering, auf Kanal 2 ausgeprägt und Kanal 4 ist nicht benutzbar (Abweichung > 6 DIV). Habe ich ein Montagsgerät erwischt??
Stefan schrieb: > Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für > typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ? > Einen Logic-Analyzer hab' ich zwar bereits, aber der ist PC-basiert und > oft möchte man einfach nur mal kurz einen Datenstrom verifizieren; da > würden die 2-4 Kanäle -je nach Protokoll- völlig ausreichen... Ich hab' mir mal Gedanken gemacht: https://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=14 Falk, derzeit scopelos
über: http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=14 gehts ohne user / passwort...
Bernhard M. schrieb: > über: > > http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=14 > > gehts ohne user / passwort... Wahrscheinlich nicht. Tip: Freemail-Account für solche Fälle besorgen und anmelden. Falk
>Also wenn QM aktiv ist, kann man ja im dazu gehörigen QM-Menü den Kanal >wählen, den QM auswertet. Wählt man hier während der Messung einen >anderen Kanal, arbeitet QM trotzdem weiter auf dem bisherigen und >wechselt auf die geänderte Einstellung erst, nachdem man QM deaktiviert >und dann wieder aktiviert. Na ja. Du kannst ja unterschiedliche Kanäle gleichzeitig messen und willst nicht für alle Messungen gleichzeitig den Kanal ändern. Ich glaube,das was du meinst ist, dass du einen der drei Mess-Slots auswählen und diesen dann geziehlt bearbeiten (Messfunktion, Kanal) oder gezielt löschen willst. Das wäre auch mein Wunsch an die GUI. Bis jetzt kann man nur alle drei Slots gleichzeitig löschen. Um einen Kanal zu ändern kommt man nicht drum rum alle zu löschen.
@ Odic X, willkommen im Club ;-) Ich mache den DAC-Abgleich nur für 5-, 2- und 1-V-Bereich, für die kleineren stimmt er dann automatisch. Durch die höheren Störpegel in den empfindlicheren Bereichen kann der Abgleich wohl schon ins Schleudern kommen. Also: erst Search-Zero (ev. mehrmals), dann ADC-Abgleich und dann dreimal DAC-Abgleich. Gruß, Guido
@Odic Ahh, verstehe, Du wiederholst die Kalibrierung zig mal bis in alle Unterdivisions. Das ist so nicht gedacht. Es gibt jeweils einen Korrekturfaktor für alle 5er Bereiche, einen für alle 2er Bereiche und einen für alle 1er Bereiche (also nur drei Korrekturfaktoren). Du mußt also nur einmal für 5V, 2V und 1V kalibrieren, dann sollte es stimmen, auch in den kleineren Spannungsbereichen. Hayo
Funktioniert leider bei mir nicht. Wenn ich z.B. Kanal 4 im 5V-Bereich perfekt abgeglichen habe, liegt die Nullinie im 500mV-Bereich 0,5 DIV höher und im 50mV-Bereich 4 DIV höher. Das ist so leider nicht zu gebrauchen....
So, ich habe das Ganze nochmal lediglich in den 1-5V Bereichen durchgespielt. Bei den Kanälen 1 und 3 klappt es. Bei Kanal 2 kann man mit der sich ergebenden Abweichung von 0,3 DIV notfalls leben. Nur bei Kanal 4 funktioniert das Ganze leider überhaupt nicht: 5V: abgeglichen 500mV: +0,2 DIV 50mV: +1,8 DIV 2V: abgeglichen 200mV: +0,5 DIV 20mV: +4,6 DIV 1V: abgeglichen 100mV: +0,9 DIV 10mV: >+8 DIV Wäre es in der Firmware viel Arbeit, die Korrekturwerte für jeden Bereich einzeln ermitteln zu können?
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.