Announcement: there is an English version of this forum on Mischmasch schrieb: > Ansonsten Tektronix WFM, das ist binär und daher kürzer, und viele > kommerzielle Tools können es lesen, weil es eben von Tektronix kommt. Natürlich habe ich einen Link zu einer Spec vergessen :-( http://www.scopeshop.de/File_1499/001137802.pdf
Hallo, danke für die Antworten und das PDF. Gibt es für CSV auch einen Standard für Messdaten oder macht jeder wie er will.Der Nachteil den ich sehe ist, dass wieder dokumentiert werden muss was welche Spalte usw. bedeutet. Der Vorteil ist natürlich das es von jedermann bearbeitet werden kann. Peter
Peter Dreisiebner schrieb: > Gibt es für CSV auch einen Standard für Messdaten Nein. > oder macht jeder wie > er will. Ja. > Der Nachteil den ich sehe ist, dass wieder dokumentiert werden > muss was welche Spalte usw. bedeutet. Jein. Für das Hantek würde ich das CSV-Format nachbauen, dass Hantek zum Speichern von CSV-Dateien auf einem USB-Stick verwendet. Typisch für Hantek ist allerdings, dass das ziemlich scheiße ist. Es enthält fast keine Meta-Informationen über die DSO-Einstellungen. > Der Vorteil ist natürlich das es > von jedermann bearbeitet werden kann. Ja.
das wars, alle remote kommandos die diese DSOs kennen sind dokumentiert: http://www.mikrocontroller.net/articles/Hantek_Protokoll Die debug meldungen : 0x00 FPGA Register lesen 0x42 FPGA Register beschreiben 0x45 Interpolation anpassungen 0x01 FPGA FIFO Inhalt auslesen sind evt. nicht vollständig oder falsch beschrieben. Das liegt daran das bis jetzt Hantek keine informationen zu den debug meldungen rausgerückt hat (ich habe nochmal höfflich angefragt). Denoch, jetzt schon liefern diese meldungen brauchbare daten bzw. reagieren entsprechend auf änderungen. Die FPGA Register sind zwar nicht bekannt (die würde ich gerne von Hantek erfahren), man kann aber mit etwas arbeit die in der fw dissassembly finden (z.b. trigger setzen). Es fehlen auch informationen zu der formatierung von den DSO variablen aus den debug meldungen : 0x02 DSO Firmware Variablen auslesen 0x40 DSO Firmware Variablen schreiben Man kann die evt. selber herausfinden (änderung vornehmen, 15sec warten bis die änderungen gespeichert werden und auslesen/zuordnen). Was ich allerdings weiss ist das genau diee informationen firmware version abhängig sind (diese werte und die eigenen setups werden auch beim fw update gelöscht). Bei gelegenheit (falls Hantek keine informationen zuschickt) werde die alten fw versionen aufspielen, dumps von den variablen machen und vergleichen auf gemeinsamkeiten.
Hallo Thomas, Thomas R. schrieb: > das wars, alle remote kommandos die diese DSOs kennen sind dokumentiert: super, danke! Ich hoffe mein DSO hält solange durch, bis ich das alles vielleicht einmal in dem DSO-Tool umgesetzt habe :-) Peter
Peter Dreisiebner schrieb: > > Ich hoffe mein DSO hält solange durch, bis ich das alles vielleicht > einmal in dem DSO-Tool umgesetzt habe :-) > hardwareseitig ist (eventuell) nur "0x42 FPGA Register beschreiben" mit vorsicht zu benutzen. Alle anderen fehler schiessen evt. ein paar dateien weg, aber die kann man schnell ersetzen :)
Angehängte Dateien:
Hallo Thomas, ich habe jetzt die DSO-Einstellungen nach deiner Excel-Liste erweitert. Nur ist mir jetzt aufgefallen das z. B. die Volt/Div nicht stimmen. In der Liste geht es bis 2 mV runter, das DSO geht nur bis 20 mV und das wäre der Wert 3. Dafür geht das DSO hoch bis 50 V, in der Liste hört es bei 5 V auf. Da ist etwas um 3 Zeilen verschoben, der Wert 10 entspricht 50 V, und 0 dann 20 mV. Ich stelle die neue Version gleich auf meine Seite, vielleicht fallen anderen auch noch Fehler auf. Peter
Hallo Thomas, Blödsinn, das ist doch die 1x und 10x Probeeinstellung. Sorry, ich bin zu dumm. Peter
Hallo, da ich noch an den Sample-Daten herumkaue, anbei ein Abfallprodukt. Die Anzahl der Samples pro Kanal für 1 und 2 aktive Kanäle und alle Speichertiefen. Ich habe die Samples mit meinem DSO-Tool von jeder Einstellung gelesen, funktioniert sehr gut. Nur bei 400 ms und 512k/1M muss schon oft probieren, das DSO reagiert da fast nicht. Peter
Hallo, ich schon wieder, eine Frage zu den Sample-Daten und den Werten die man vom DSO einlesen kann. Ausgangspunkt ist 'Autoset' und Kanal 1 hängt am 'Probe Check'. [HORIZ-WIN-TB] = 15, Window-Timebase ist 200 us, [CONTROL-DISP-MENU] = 1, sichtbar sind 16 DIVs bei Menü ein, gelesen werden 3200 Samples (bei 4 k) Berechnung: 200 us * 16 DIV = 3,2 ms 3,2 ms / 3200 Samples = 1 us 1 us = 1 MHz Wenn das Menü ausgeblendet ist, sind 19,2 DIVs sichtbar, und es werden 3840 Samples gelesen. 200 us * 19,2 DIV = 3,84 ms 3,84 ms / 3840 Samples = 1 us 1 us = 1 MHz Das heißt ich komme nur über die Anzahl der DIVs zur Sample-Frequenz. Erst dann kann man den Zeitpunkt jedes Samples berechnen. Oder geht das auch ohne den DIVs mit einen anderen Wert aus den DSO-Einstellungen? Peter
Hallo, man muss die Main-Timebase [HORIZ-TB] berücksichtigen denke ich, und nicht die Window-Timebase. Aber warum bekommt man eine verschiedene Anzahl der Samples wenn das Menü ein oder aus ist. Bei gleicher Main-Timebase, dann müsste ja mit unterschiedlicher Frequenz gesampled werden? Ich versteh' es im Moment nicht. Peter
Hallo, ich glaube, dass es sich nur um die Anzahl der auf dem Schirm angezeigten Punkte handelt. MfG egonotto
Hallo egonotto, danke, aber die Pixel sind das nicht. Ich denke es stimmt schon so, man kommt um die Anzahl DIVs nicht herum, z.B.: kleinste Main-Timebase = 200 ns Menü Ein = 16 DIVs Window-Timebase 2 ns bis 40 ns gelesen werden 640 Samples 200 ns * 16 DIV = 3,2 us 3,2 us / 640 Samples = 5 ns 5 ns = 200 MHz Menü aus 200 ns * 19,2 DIV = 3,84 us 3,84 us / 768 Samples = 5 ns 5 ns = 200 MHz Mit einer Window-Timebase von 2 ns bis 40 ns kann man sich in der Main-Timebase bewegen, sprich den horizontalen Trigger verschieben. Den horiz. Trigger kann man beim Speichern der Samples berücksichtigen, alle Samples davor haben eine negative Zeit und alle danach sind poisitiv. Wie immer, Kopf schief halten, dann rinnt das Hirn zusammen :-) Peter
Eigentlich sind es nur display punkte die den postprocessed sampled entsprechen (die richtigen sample daten sind MÖGLICHERWEISE per FIFO read auslesbar, die sind afaik aber nciht post-processed, die display samples schon). Die sample rate kannst du daraus sehr schwer bis gar nicht ableiten, dafür braucht man die tatsächlichen daten samples. Beispiel 200ns/div, laut deiner rechnung 200MSs, es sind aber 800. Noch ein beispiel - 8ns/div timebase. Sind immer, unabhängig von der speichertiefe immer 800 "samples", aber die sample rate im 4k modus 1GSs, bei dir (hw 83e9) 500MSs und bei anderen mit hw 83e8 400MSs ;) Übrigens 4k modus, eigentlich benutzt die firmware 20div intern, so ergeben sich auch min 800punkte und maximal 4000punkte beim 4k speicher. Dies gielt auch für andere speichertiefen. Die display samples sind sample rate mehr oder weniger unanbhängig, sieht man auch in deiner xls - die ändern sich natürlich je nach anzahl der DIV auf dem display aber das ist auch so gewollt - weil es display samples (dots) sind. Du kannst ja auch gerne die firmware abfragen - utility, page2/3, sys staus. Da steht auch "display dots" <- dise werte sind aber 20 DIV bezogen. Und ja, es sind maximal 800000 dots, um 1000000 zu bekommen muss die timebase ratio ganz anders aufgebaut. Ich kann dir gerne eine firmware zuschicken (mit 1:2:5 ratio),da bekommt man auch 1M punkte und keine 800k. Das wird aber auch früher oder später bei alles Hantek/Tekway DSOs so sein (ich meine die 1:2:5 ratio). Die möchten nicht mehr verarschen, weder mit sample punkten noch mit sample rate (weil es war eine verarsche zu sagen 1GSs, 500MSs im dual oder long mem während es nur 400MSs sind - eigentlich sollte jder der 83e8 hat update auf 82e9 bekommen ... oder neues gerät kaufen ? K.a. was die so denken.). Für die samplerate braucht man die anzahl der kanäle, die timebase, speichertiefe, FPGA clock werte und firmware version :) Anzale der kanäle ist klar, auch speichertiefe und timebase sind vorhanden in den einstellungen daten. Die firmware version ist wichtig weil die 83e8 modele mit z.b. max 400MS/s in den 40k bis 1M samplen während die 83e9 mit max. 500MS/s. FPGA clock (eigentlich nur die information ob mit 125MHz oder 100MHz sampled wird) braucht man evt. auch (per FPGA register lesen möglicherweise sichtbar), man kann aber auch hardcoden anhand was die aktuelle firmware (auf dem jeweiligen hw model .. evt. als checkbox in der software oder per dso variable auslesen) macht.
Thomas R. schrieb: > Philipp schrieb: >> wozu gibt es bei den dingern platz für ein audio chip? > > benutze suchfunktion in dem trhead gibts nur 2 oder 3 beiträge mti dem wort audio und da steht nichts interesanes
Hallo Thomas, Thomas R. schrieb: > Eigentlich sind es nur display punkte die den postprocessed > ... danke für die Erklärung, ich werde den Kopf jetzt in die andere Richtung schief halten, vielleicht hilfts. Ich bleib dran. Peter
Philipp schrieb: > Thomas R. schrieb: >> Philipp schrieb: >>> wozu gibt es bei den dingern platz für ein audio chip? >> >> benutze suchfunktion > > in dem trhead gibts nur 2 oder 3 beiträge mti dem wort audio und da > steht nichts interesanes Beitrag "Re: TEKWAY DST1xx2B Oszilloskop" Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"
Thomas R. schrieb: > > FPGA clock (eigentlich nur die information ob mit 125MHz oder 100MHz > sampled wird) braucht man evt. auch (per FPGA register lesen > möglicherweise sichtbar), man kann aber auch hardcoden anhand was die > aktuelle firmware (auf dem jeweiligen hw model .. evt. als checkbox in > der software oder per dso variable auslesen) macht. Peter, also den status vom FPGA (125MHz oder 100MHz clocked) kann man auslesen, benutze dafür die die "range" abfrage da die abfrage von einzelnen register irgendiwe nicht das liefert was ich will (deckt sich nicht mit range ausgabe, warum auch immer): 43 05 00 00 01 01 01 4B die antwort für 125MHz: 43 06 00 80 01 00 00 00 CA die antwort für 100MHz: 43 06 00 80 00 00 00 00 C9 Was wir noch wissen ist die feste anzahl der ADCs, beim zwei kanälen immer je 4ADCs, bei einem kanal immer 8 ADCs von 2ns/div bis 800ns/div und 4ADCs ab 2us/DIV bis 40s/div. Das hilft für die samplerate berechnung auch etwas.
vergiss es, da muss wohl ein mapping sein in der fw, ältere versionen liefern bei dem register komplett was anderes.
Hallo Thomas, Thomas R. schrieb: > Was wir noch wissen ist die feste anzahl der ADCs, beim zwei kanälen > immer je 4ADCs, bei einem kanal immer 8 ADCs von 2ns/div bis 800ns/div > und 4ADCs ab 2us/DIV bis 40s/div. > > Das hilft für die samplerate berechnung auch etwas. ich weiß jetzt nicht, wie das mit den Sample-Daten die ich auslesen kann, zusammen paßt. Du sprichst jetzt von den 'echten' Sample-Daten von den ADCs? Ich sende gleich noch ein Posting, wie ich das jetzt verstanden habe und verwenden würde. Peter
Hallo, einmal noch. hier zwei Bespiele wie ich das jetzt vertanden habe und unten wie ich die Sample-Daten als CSV speichern würde. Hardware 83e9 1 Kanal Speicher 4 k Timebase 8 ns/DIV Main-Timebase 200 ns/DIV Info im Menü 'Sys Status': Sample Rate: 1.00 GS/s Sample Dots: 160 (bezogen auf die internen 20 DIVs) Display Dots: 800 (bezogen auf die internen 20 DIVs) Berechnung: 1 GS/s = 1 ns/Sample 8 ns/DIV = 8 Samples je 1 ns 8 Samples/DIV * 20 DIVs = 160 Samples (wie in 'Sys Status') Speicher: Main-Timebase 200 ns/DIV * 20 DIVs = 4000 ns Sample-Zeit bei 1 Sample/ns = 4000 Samples - der 4 k Speicher ist voll. Mit dem horizontalen Trigger kann man jetzt plus/minus 2000 ns scrollen, also den ganzen Speicher anschauen. Die Sample-Daten die ich bei dieser Einstellung auslese, sind hochgerechnete 'Display Dots', von den 160 Samples auf die sichtbaren Pixel, also 640 oder 768 je nachdem ob das Menü sichtbar ist oder nicht. An die 4 k Samples komme ich nicht. Jetzt eine andere Einstellung: 1 Kanal Speicher 1 M Timebase 400 us Main-Timebase 400 us Info im Menü 'Sys Status': Sample Rate: 100 MS/s Sample Dots: 800.000 (bezogen auf die internen 20 DIVs) Display Dots: 800.000 (bezogen auf die internen 20 DIVs) Berechnung: 100 MS/s = 10 ns/Sample 400 us/DIV = 40.000 Samples je 10 ns 40.000 Samples/DIV * 20 DIVs = 800.000 Samples (wie in 'Sys Status') Speicher: Main-Timebase 400 us/DIV * 20 DIVs = 8000 us Sample-Zeit bei 100 Sample/us = 800.000 Samples - der 1 M Speicher ist 'fast' voll. Mit dem horizontalen Trigger kann man nicht scrollen, die Timebase sind ja gleich groß. Die Sample-Daten die ich jetzt auslese sind 768.000 und nicht mehr die erfundenen Bildschirmpunkte, es sind ja genügend Daten vorhanden. Das heißt, die Sample-Daten die ich auslese, beziehen sich immer auf die Window-Timebase und die sichtbaren DIVs, denn die Samples sind ohne sichtbaren Menü mehr. Egal von welcher Hardware die Samples stammen, es gibt jetzt eine Zeit, eine Anzahl Samples und die DIV-Anzahl. Es sind nur nicht mehr die 'echten' Samples von den ADCs. Für das Speichern der Sample-Daten als CSV bedeutet das, z.B. das letzte Beispiel von oben: Timebase 400 us * 19,2 DIVs = 7680 us 768.000 Samples / 7680 us = 100 Samples/us = 1 Sample alle 10 ns Ich kann also für jedes Sample einen Zeitpunkt berechnen und auch den horiz. Trigger berücksichtigen, denn kann man ja auch auslesen. Habe ich das jetzt alles richtig verstanden und würden die CSV-Daten so verwendbar sein? Peter
Thomas R. schrieb: > Thomas R. schrieb: >> >> FPGA clock (eigentlich nur die information ob mit 125MHz oder 100MHz >> sampled wird) braucht man evt. auch (per FPGA register lesen >> möglicherweise sichtbar), man kann aber auch hardcoden anhand was die >> aktuelle firmware (auf dem jeweiligen hw model .. evt. als checkbox in >> der software oder per dso variable auslesen) macht. > > Peter, > > also den status vom FPGA (125MHz oder 100MHz clocked) kann man auslesen, > benutze dafür die die "range" abfrage da die abfrage von einzelnen > register irgendiwe nicht das liefert was ich will (deckt sich nicht mit > range ausgabe, warum auch immer): > > 43 05 00 00 01 01 01 4B > > die antwort für 125MHz: > 43 06 00 80 01 00 00 00 CA > > die antwort für 100MHz: > 43 06 00 80 00 00 00 00 C9 > > > Was wir noch wissen ist die feste anzahl der ADCs, beim zwei kanälen > immer je 4ADCs, bei einem kanal immer 8 ADCs von 2ns/div bis 800ns/div > und 4ADCs ab 2us/DIV bis 40s/div. > > Das hilft für die samplerate berechnung auch etwas. damit es vollständig ist habe alle fw versionen die ich habe mal angetestet um zu prüfen was diese einer register zeigt und ob es richtig ist was er zeigt: bench 2.03.x - nö 2.05.x - nö 2.06.2 - nö 2.06.3 bis 111026.1 - nö und ab da alle geliestetet fw funktionieren 2.06.3 - 111122.0 2.06.3 - 111124.0 2.06.3 - 111202.0 2.06.3 - 111226.1_HanTekway 2.06.3 - 111226.1_Voltcraft 2.06.3 - 120112.0 2.06.3 - 120112.1 2.06.3 - 120112.1_1:2:5_timebase_ratio 2.06.3 - 120224.0 wobei ich habe nur FPGA designs hw0-83e8, hw1005-83e8, hw1007-83e8 und 83e9. Die test version vom verbesserten FPGA design geht nicht, was allerdings zeitlich zu dem passt ab wann die angefangen haben den register für 125/100mhz zu implementieren. Ahja, und handheld geht natürlich keine fw version, warum soll es einfach gehen wenn es kompliziert sein kann :) 2.01.1_(110909.0) - nö 2.01.1_(111014.0) - nö 2.01.1_(111111.1) - nö 2.01.1_(111213.0) - nö
Peter Dreisiebner schrieb: > > Mit dem horizontalen Trigger kann man jetzt plus/minus 2000 ns scrollen, > also den ganzen Speicher anschauen. > bin noch am lesen, aber sofort eine bemerkung - beim plus/minus scrollen immer drauf achten ob das rotes kästchen mit waveform ober in der status anzeige schon link oder rechts an die ende des kästchen angrenzt. Ich kann mich erinner an ein lustiges bug, man konnte viel weiter scrollen als der speicher es erlaubt hat, sah sogar alles gut aus (mit sinus :), die anzegige war aber natürlich nur ein spiegelbild.
Hallo Thomas, Thomas R. schrieb: > Peter Dreisiebner schrieb: > >> >> Mit dem horizontalen Trigger kann man jetzt plus/minus 2000 ns scrollen, >> also den ganzen Speicher anschauen. >> > > bin noch am lesen, aber sofort eine bemerkung - beim plus/minus scrollen > immer drauf achten ob das rotes kästchen mit waveform ober in der status > anzeige schon link oder rechts an die ende des kästchen angrenzt. > Ich kann mich erinner an ein lustiges bug, man konnte viel weiter > scrollen als der speicher es erlaubt hat, sah sogar alles gut aus (mit > sinus :), > die anzegige war aber natürlich nur ein spiegelbild. das hatte ich wirklich probiert, man kurbelt ganz schön lange. Aber bei der minus-Seite kann man nur bis zum Ende scrollen, bei der plus-Seite weiter als Daten vorhanden sind, man sieht aber keine. Peter
Angehängte Dateien:
-
waveform1.png
2,6 KB
Hallo, mal was zum csv-Export. Einstellung: 1 Kanal 40 kSsample 2 ns/Div Signalfrequenz: 25 kHz Man bekommt damit eine Samplerate von 500 MSamples/s (1 GSamples/s geht nur bei 4 k-Speicher) In der csv-Datei sind 40100 Samples. Der Abstand von 2 Samples ist 2 ns Daher umfasst die csv-Datei etwa 80 µs. Das erste Sample und die letzten Samples sind Unsinn. Da ist also noch ein Fehler! Mir ist das DSO-3052C beim Schreiben auf USB-Stick sehr häufig abgestürzt. Wieder ein Fehler! Die Kurvenform und die csv-Datei ist in der Anlage MfG egonotto
ja, deine formel stimmt. Die "0x02 Sample-Daten lesen" werte sind auf 10DIV Vertikal bezogen und gehen von -127 bis +127. Es sind auch definitiv post-processed daten. Schade zwar das man nur der ausschnitt auslesen kann (wenn WTB kleiner als MTB), aber das ist eine nette ergänzung zu den normalen CSV export der raw buffer speichert. Den raw buffer kann man eigentlich mit "0x01 FPGA FIFO Inhalt auslesen", allerdings bekomme ich nicht mehr als 2k ausgelesen (43 04 00 01 00 08 50) ohne einen dso.exe crash. Dazu bin bei dem syntax nicht sicher ob der stimmt. Die daten beim raw sind natürlich nicht mehr display bezogen.
egonotto schrieb: > Das erste Sample und die letzten Samples sind Unsinn. Da ist also noch > ein Fehler! > In der csv-Datei sind 40100 Samples. ja, daran liegts auch, 40100 beim 40000 im speicher ist etwas übertrieben. > > Mir ist das DSO-3052C beim Schreiben auf USB-Stick sehr häufig > abgestürzt. Wieder ein Fehler! > mir nicht, bedeutet aber nix. Je mehr ich mir die letzten beiden firmwares angucke desto mehr bin ich mir sicher das es ein fehler war die zu publizieren. Warum die solche zwischendinger (zwischen 1:2:5 und 2:4:8 tb, und das ist eine GROSSE änderung da fast alles sich dadurch ändert) herusbringen verstehe ich nicht, möglicherweise weil leute wie ich jeden tag nachfragen ob die endlich fertig sind. Und es war schon so chön, nur noch sehr kleine fehlr drin gewesen, aber nein, Hantek musste wieder verschlimmbessern.
Thomas R. schrieb: > Und es war schon so chön, nur > noch sehr kleine fehlr drin gewesen, aber nein, Hantek musste wieder > verschlimmbessern. Welche Version empfiehlst du bzw. welche würdest du also "stable" betiteln?
Lukas P. schrieb: > Welche Version empfiehlst du bzw. welche würdest du also "stable" > betiteln? Ich bin zwar nicht Thomas, aber ich würde mittlerweile die Firmware von Rigol empfehlen. Ok, du brauchst noch ein anderes Oszilloskop dazu. <rant> Mittlerweile habe ich von Hantek die Nase voll. Die Software ist nicht nur ein Haufen Scheiße, die Programmierer sind offensichtlich zu doof sich selbst ein Butterbrot zu schmieren und der Support ist ein Haufen Lügner, wenn sie denn mal antworten. Rigol hat zwar ebenfalls keinen nennenswerten Support und der lügt auch, aber wenigstens funktioniert deren Firmware ansatzweise. Ich mag nicht mehr in dieser Scheiße zu wühlen, die Hantek Software nennt, nur um bei anderen Herstellern selbstverständliche Funktionen ansatzweise und fehlerhaft zu bekommen. Es ist nicht mein Job als Kunde dauerhaft in der Scheiße zu wühlen und von Hantek kommt nichts anderes als Scheiße. Ich habe keine Lust mehr, mühsam Informationen durch Reverse-Engineering zu erraten, die Hantek in ein paar Minuten bereitstellen könnte, wenn man dort nur die faulen, inkompetenten Ärsche hochbekommen würde. </rant>
Hannes Jaeger schrieb: > Ich bin zwar nicht Thomas, aber ich würde mittlerweile die Firmware von > Rigol empfehlen. Ok, du brauchst noch ein anderes Oszilloskop dazu. > > <rant> > Mittlerweile habe ich von Hantek die Nase voll. Die Software ist nicht > nur ein Haufen Scheiße, die Programmierer....... Das war die morgendliche Frust-Entladung....wir habens zur Kenntnis genommen. Hast Du auch etwas konstruktives?
Peter Krengel schrieb: > Hast Du auch etwas konstruktives? Dann schau mal, wer http://www.mikrocontroller.net/articles/Hantek_Protokoll begonnen hat. Dann weißt du auch, warum ich mittlerweile finde, dass Hantek nur einen Haufen Scheiße liefert.
Hannes Jaeger schrieb: > Dann schau mal, wer > http://www.mikrocontroller.net/articles/Hantek_Protokoll begonnen hat. > Dann weißt du auch, warum ich mittlerweile finde, dass Hantek nur einen > Haufen Scheiße liefert. :)))))))))))) Vielleicht schreibt ja irgendwann, mal irgendwer die ganze Software neu..... Gruss Peter
Hannes Jaeger schrieb: > > Ich habe keine Lust mehr, mühsam Informationen durch Reverse-Engineering > zu erraten, die Hantek in ein paar Minuten bereitstellen könnte, es ist nicht so das nach 2 jahren, zig emails, zig mehreren anrufen und mittlerweile sogar bestechungsversuchen die nicht beatwortet hätten .. doch doch, es kamm sogar etwas SDK doku rüber. Damit ist mindestens der "normale meldungen" teil wirklich komplett, es war auch teilweise brauchbar für reversing von debug meldungen. Allerdings bekommen wir keine doku zur debug meldungen, weil es interne sachen sind. Nun, ich war aber fleißig und eigentlich brauchen wir nur noch kleinigkeiten Beitrag "Re: TEKWAY DST1xx2B Oszilloskop" > wenn > man dort nur die faulen, inkompetenten Ärsche hochbekommen würde. > ach, ob diese mädels sind schon fleißig, 99,9999999998% aller versuche die entwickler direkt zu erreichen werden abgeblockt :)
Lukas P. schrieb: > > Welche Version empfiehlst du bzw. welche würdest du also "stable" > betiteln? habe lange aiuf einem DSO die "2.06.3_110923.1" benutzt und fand die stable, davor glaube ich 2.06.3_110531.1, ist aber schon eine weile her. Von den ganz alten war glaube ich 2.05.0_100305.0 nicht schlecht. Von den letzten versionen die auch "83E9" kompatibel sind würde spontan sagen 2.06.3_111202.0 Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"
Angehängte Dateien:
-
screenshot_201203029_sampledata.png
14 KB -
kst-test.png
15 KB -
csv-test-1.png
14 KB
Hallo, ich habe das Speichern der 'Window-Timebase'-Samples als CSV-Datei fertig. Ob die Daten richtig berechnet werden muss ich erst richtig testen. Anbei ein paar Screenshot, schaut vorerst nicht so verkehrt aus. Das DSO-USB-Tool gibts hier: http://www.dreisiebner.at/dso-usb-tool/ Peter
Peter Dreisiebner schrieb: > Das DSO-USB-Tool gibts hier: > http://www.dreisiebner.at/dso-usb-tool/ Hallo Peter, vielen Dank für die unermüdliche Arbeit am TTScope-Nachfolger! Gibt es auch eine Möglichkeit, mal einen Blick in den Code zu werfen, ohne RealStudio zu besitzen - oder würde die kleinste Ausbaustufe (Personal) dafür auch schon ausreichen? Aus der Vergeleichsliste von RealSoftware werde ich nicht so recht schlau. Danke! Thomas
Hallo Thomas, Thomas Sch. schrieb: > Gibt es auch eine Möglichkeit, mal einen Blick in den Code zu werfen, > ohne RealStudio zu besitzen - oder würde die kleinste Ausbaustufe > (Personal) dafür auch schon ausreichen? Aus der Vergeleichsliste von > RealSoftware werde ich nicht so recht schlau. > Danke! Thomas ich habe es nicht ausprobiert, aber ich glaube du kannst den Code mit jeder Version öffnen, nur die Teile für die Professional/Enterprise Version nicht ändern. Das sind die Container-Controls und noch ein paar Objekte wie z.B. IPC-Controls usw. Einen genauen Überblick habe ich nicht, ich kann ja alles benutzen :-) Die Trial-Versionen sind aber unbeschränkt, nur die Laufzeit der Exe ist dann bis 5 Minuten limitiert. Kann man aber immer wieder starten. Peter
falls jemand die "ico" dateien ins png konvertieren möchte http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg101338/#msg101338 und natürlich zurück: http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg101352/#msg101352
Thomas R. schrieb: > Von den letzten versionen die auch "83E9" kompatibel sind > würde spontan sagen 2.06.3_111202.0 Super, danke! Speziell der Hinweis auf die 83e9 war gut! Sonst hätte ich wahrscheinlich die alten benutzt und mich gewundert... ;-)
Peter Dreisiebner schrieb: > ...RealStudio... Bescheidene Frage: Ich kenne RealStudio nicht, aber wäre es damit nicht vielleicht möglich auch eine Mac/Linux Version der Software zu bauen? Das Real-Zeug kann sowas doch angeblich. Benutze seit längerem privat kein Windows mehr... ;-) Edit: Erst denken, dann... Mir fällt gerade der benötigte USB-Treiber wieder ein. Also wohl eher nicht. Wäre ja auch zu einfach gewesen ;-D
Peter Dreisiebner schrieb:
> ...RealStudio...
Wo liegt eigentlich der Vorteil so eine exotische IDE zu benutzen?
VisualStudio Express gibts doch kostenlos.
Schaltplan vom Netzteil: Ich habe EEVBlog, Artikel und die Threads hier durchsucht: gibt es irgendwo ein Schaltplan vom Netzteil?
Ja, tinman hat hier und im EEVblog einen Schaltplan vom gesamten DSO als pdf gepostet. Da ist dann auch der Schaltplan vom Netzteil dabei. Hier der Link: http://www.mikrocontroller.net/attachment/116588/Hantek_Tekway_DSO_v1.03.pdf Mfg
habs ihn nun doch gefunden: Beitrag "Re: TEKWAY DST1xx2B Oszilloskop" Sorry. Der Hitzespender im Netzteil (3,3V) ist doch der "obere" Regler (zum Handgriff), oder ?
Alois Neumann schrieb: > Thomas R. schrieb: >> Falls jemand von euch ein Altera JTAG cable hat und ein Voltcraft DSOs >> oder Hantek/Tekway hw 1007x555583e9 (nicht 83e8!) würde ich mich >> freuen wenn derjeniger einen dump von dem MAX II CPLD machen würde >> (die sind nciht copy protected). > Ich habe die H/W Version 1007x555583e9 und einen "Mini Usb Blaster > Cable For CPLD FPGA NIOS JTAG Altera Programmer". > > Was brauche ich für Software und wie gehe ich vor beim Erstellen des > Dumps? > > Gruss Alois ;) Alois, habe jetzt auch so ein Blaster gekauft und getestet - damit geht es auch. Anbei die Anleitung wie. gruss Thomas
Hallo Thomas, Thomas R. schrieb: > ja, deine formel stimmt. Die "0x02 Sample-Daten lesen" werte sind auf > 10DIV Vertikal bezogen und gehen von -127 bis +127. ich habe mir die Sample-Daten nochmals angeschaut. Kann es sein das nicht 10 DIVs sondern 10,2 DIVs verwendet werden? Umgerechnet wären das 510 Pixel, die kann ich nämlich auch auslesen. Wenn man z. B. auf 2 ns und 1 V/DIV geht und einen Kanal auf GND schaltet, dann hat man eine ziemliche Gerade. Jetzt kann ich bis +5,08 V und -5,08 V 255 unterschiedliche Sample-Daten auslesen, als von +127 bis - 127 plus der Null. Da ergibt dann pro Sample schöne 2 Pixel und genau 40 mV. Bei 10 DIVs wird es unrund mit 39,22 mV. Peter
Hantek hat mir gesagt "1000 punkte" bei der position und "alles position - also vertikal - sind auf die 1000 display points bezogen". Das halte ich aber für unsinn, wird nicht die erste abweichung sein zwischen dem was die programmiert und dokumentiert haben. Ich habe bei den sample daten pi * daum 10DIV am max wert gemessen/gesehen, muss zugeben das war etwas schlampig. Liesst man die raw daten dann entspricht full scale raw daten einer anzeige von ca. ~10,5DIV Es wird also etwas zwischen 10,5 und 10 sein, die 10,2DIV + 2pixel "zero" pixel (also 10,24 gesammt vertikal) klingeln allerdings logisch. Die fehler bei der darstellung auf dem bild (noise mal unten, mitte oder oben beim pos. verschiebung) spricht evt. für glatte 500 (also 10DIV)
Angehängte Dateien:
Hallo, ich habe die live Anzeige der Sample-Daten soweit, dass man was sieht. Die Anzeige ist auch skalierbar und ziemlich vollständig konfigurierbar. Nur fehlt es mir an Wissen, wie man die Samples richtig zur Anzeige zusammenfasst. Wenn also mehr Samples als Pixel vorhanden sind und umgekehrt. Den Mittelwert bilden ist zuwenig denke ich, da gehört ja sowas wie Peak-Detect dazu. Hat jemand vielleicht passende Stichwörter oder einen 'verständlichen' Link? Veröffentlicht habe ich die aktuelle Version noch nicht. Die Anzeige stimmt eben nicht, und ich habe auch oft 'Hänger' im Programm wenn am DSO fleißig gekurbelt wird, während die Daten gelesen werden. Peter
Hallo Peter,
zu
"
Nur fehlt es mir an Wissen, wie man die Samples richtig zur Anzeige
zusammenfasst. Wenn also mehr Samples als Pixel vorhanden sind und
umgekehrt. Den Mittelwert bilden ist zuwenig denke ich, da gehört ja
sowas wie Peak-Detect dazu.
"
Wenn zu wenig Daten vorhanden sind, kann man interpolieren. Die
einfachste Art ist die lineare Interpolation (die Nachbarpunkte mit
einer Strecke verbinden).
Wenn viel mehr Daten verhanden sind, könnte man die Daten in disjunkte
Teile zerlegen und in jedem Teil das Minimum mit dem Maximum verbinden.
Dazu ein Beispiel:
Vorhanden sind 40000 Werte im Zeitintervall [0,1]ms
(y[0],y[1],...,y[39999])
Man möchte 1000 Punkte auf der x-Achse haben (x[0],x[1],...,x[999]).
Nun teilt man die y-Werte:
t0 = {y[0],y[1],...y[39]}
t2 = {y[40],y[41],...y[79]}
t3 = {y[80],y[81],...y[119]}
.
.
.
t999 = {y[39960],...y[39999]}
und bildet min[0] = min(t0); max[0] = max(t0)
und malt alle Punkte (x[0],min[0]),(x[0],min[0]+1),(x[0],min[0]+2),....
...,(x[0],max[0])
.
.
.
und bildet min[999] = min(t999); max[999] = max(t999)
und malt alle Punkte
(x[999],min[999]),(x[999],min[999]+1),(x[999],min[999]+2),.....,(x[999],
max[999])
Noch besser könnte man die Sache vielleich machen, indem man mit
sin(x)/x-Interpolation arbeitet. Dazu müsste man sich aber vorher noch
Gedanken machen, z.B. über die Frequenzbandbegrenzung.
MfG
egonotto
Hallo egonotto, danke, ganz habe ich es nicht kapiert. Bei zuwenig Samples einfach eine Linie zeichnen ist klar, das werde ich vorerst auch so machen. Bei zuvielen Samples die Daten aufteilen pro Pixel, dann pro Teil das Minimum und Maximum ermitteln. Und jetzt kapiere ich das Zeichnen nicht. Zeichne ich dann pro Teil auf derselben x-Koordinate vom Minimum zum Maximum, also eine Senkrechte. Dann von diesem Maximum zur nächsten x-Koordinate und Minimum vom nächsten Teil. Dann wieder eine Senkrechte zum Maximum und weiter zum nächsten x und Minimum und so fort? Bei einem starken Rauschen ergibt das eine dicke horizontale Linie, bei keinem Rauschen eine feine Pixelline, Peaks gehen so auch nicht verloren. Habe ich das so richtig verstanden? Peter
Das Weglassen von Abtastdaten (ob zum Zeichnen oder aus anderen Gründen) ist eine wohldefinierte Technik - Downsampling http://de.wikipedia.org/wiki/Downsampling Nur, wenn es um das Zeichnen von den Sampling-Daten geht, würde ich zu Anfang erst mal drauf verzichten. Statt dessen würde ich einfach die Daten so zeichnen wie sie sind. D.h. jeden Abtastwert als einen (X,Y)-Wert betrachten, der durch lineares Skalieren gefolgt von Runden zu einer Bildschirmposition (x,y) gewandelt wird. Die (x,y)-Positionen werden durch Linien verbunden oder als Punkte gezeichnet. Fertig. Dabei liegen dann Linien oder Punkte übereinander, d.h. man Zeichnet einiges doppelt. Gas ganze entspricht dem Finden des minimalen und maximalen y-Werts für eine x-Position, nur das man diese Werte nicht sucht, sondern alles zeichnet. Das sieht zwar in vielen Fällen bescheiden aus, aber es verbiegt einem kein Downsampling-Tiefpass das Signal zu etwas, was das Oszilloskop gar nicht gemessen hat. Dazu eine horizontale Zoom-Funktion. Damit sieht der User beim Auseinanderziehen schön, wie aus einer vertikalen Linie langsam eine Kurve wird. Zoomen geht auch schneller, wenn man auf das Downsampling verzichtet, ansonsten müsste man nämlich bei jedem Zoom neu downsamplen, entsprechend der für die jeweilige Stufe wegzulassenden Werte.
Hallo Peter, ich würde nur die jeweils senkrechte Linie vom Minimum zum Maximum zeichnen. Die benachbarten x-Werten liegen ja so nah zusammen dass man da nichts malen kann. (es wird ja zwischen x und x+1 gar keine Pixel geben) Ich probier mal das mit Buchstaben. xx xxxx xxxxxx xxxxxxx xxxxxxx xxxxxx xxx x Das könnte ein Teil einer Amplitudenmodulation sein. Man könnte die Sache noch verbessern, indem man auch die y-Werte zu einem x-Wert in Teile zerlegt und damit die Helligkeit steuert. Dann könnte man die Menge der Werte vergrössern, indem man neue Werte mit der sin(x)/x - Interpolation berechnet. Dazu braucht es aber eine Frequenzbandbegrenzung. Und ich weis nicht, ob diese vorhanden ist. Dazu ein Link zu einem mathematisch nicht sauberen Artikel. "http://i.cmpnet.com/planetanalog/2009/02/Sin(x)x_Agilent.pdf"; MfG egonotto
Hallo egonotto und Hannes, danke, ich werde mal schauen wie flott das ganze funktioniert. Jetzt beim einfachen weglassen der Samples ist es schneller als TTscope, also Luft ist noch. Die Sample-Daten sind aber die gefilterten Daten aus dem Bildschirmpuffer vom DSO. Ob man da überhaupt noch was herausholen kann? Peter
Es sind bildspeicher daten, immer mindestens ein punkt pro "DSO display" pixel. Wenn also deine anzeige fest auf 640x512 / 768x512 (oder beim handheld nur 600x512) steht ist alles gut wie es ist - einfach alles malen was gelesen war. Dadurch hast du kein ärger bei skalieren, keine unnötige interpolation. Auch beim zoom wird nur das angezeigt was tatsächlich vom DSO errechnet und angezeit war - auch wenn dann nur unter umständen 1 punkt zu sehen wird.
Hannes Jaeger schrieb: > Peter Dreisiebner schrieb: >> Anbei ein Liste mit einigen Menü-IDs. > > Ich habe die Liste mal ins Wiki gepackt > http://www.mikrocontroller.net/articles/Hantek_Protokoll/Men%C3%BC-IDs Hannes, danke für die "Eindeutschung" des Artikels.
Hannes Jaeger schrieb: > Peter Dreisiebner schrieb: >> Sind die IDs denn über die Firmwareversionen gleich? > > Keine Ahnung. Wenn ich raten müsste, dann würde ich, weil es sich um > Hantek handelt, raten, dass sie es nicht sind. > >> Ich wollte die >> Menünamen schon in das DSO-Tool aufnehmen, hatte aber die Befürchtung >> das die IDs nicht lange gültig sind. > > Ich würde es machen. Lieber für ein DSO richtig, als nichts für alle. > Sollen sich die "Kunden" doch beschweren wenn es nicht stimmt. ich werde (heute später) ein paar fw versionen testet. Ich glaube die alten menus ändern sich nciht, was aber immer wieder dazu kommt sind neue menus.
Angehängte Dateien:
Hallo Thomas, Thomas R. schrieb: > Es sind bildspeicher daten, immer mindestens ein punkt pro > "DSO display" pixel. Wenn also deine anzeige fest auf > 640x512 / 768x512 (oder beim handheld nur 600x512) steht ist > alles gut wie es ist - einfach alles malen was gelesen war. die Anzeige im DSO-Tool passt sich an die Fenstergröße an und an die Größe vom DSO, 16 oder 19 DIV. Und Daten werden ja meist mehr gelesen als Pixel am DSO sind, bei 80 us/DIV sind es ja schon 3840 Samples pro Kanal. Anbei ein Versuch so wie Egonotto es beschrieben hat, es gibt noch Lücken bei den Samples, aber sieht schon gut aus und ist genauso schnell wie vorher bei 3840 Samples. Peter
Angehängte Dateien:
Hallo egonotto, ich habe deinen Vorschlag jetzt umgesetzt, schaut sehr gut aus. Habe der Prozedur fürs Zeichnen deinen Namen gegeben :-) Ein paar Rundungsfehler gibt es noch, aber es wird. Peter
Hallo, eine neue Version vom DSO-USB-Tool steht bereit: http://www.dreisiebner.at/dso-usb-tool/ Die Kurvendarstellung ist noch Baustelle, aber funktioniert. Einen Fehler beim DSO gibt es der sich auswirkt. Es werden manchmal die Daten vom falschen Kanal gesendet ohne das die Kanalnummer in den Datenpaketen angepasst wird. Man kann also nicht feststellen das die Sample-Daten vom anderen Kanal sind. Das merkt man wenn 40 K Speicher oder mehr aktiviert sind. Dann 'springen' die Kurven manchmal. Das Abfragen ist stabiler, ich berücksichtige jetzt auch den Triggerstatus, das hat viel gebracht. Peter
Angehängte Dateien:
-
Protokollfehler-1.png
35 KB -
Protokollfehler-2.png
35 KB
Hallo, ich werde die 2 Prozeduren für die Protokollauswertung mit dem DSO überarbeiten müssen. Die Timeouts beim Programm liegen sicher auf meiner Seite, aber das DSO macht es einem nicht leicht. Anbei zwei kommentierte Screenshots vom USB-Protokoll mit seltsamen Anworten vom DSO. Peter
Angehängte Dateien:
-
Capture.JPG
54 KB
was ich gemerkt habe das z.b. auf dem handheld wo ein anderer usb-char driver läuft (genau wie bei den BM/BMV bench modelen) die übertragung selten sauber läuft ( mit deinem tool ). Z.b. procotol.inf lesen ist schon die datenmenge "zu lang", oder besser gesagt dein tool merkt nicht das zwei pakete empfagen waren - wobei die länge und checksum von beiden einzeln stimm - nur dein tool zeigt es als "ein paket" un dann stimmt natürlich nix mehr. Lese ich kleinere dateien (wie keyprotokol.inf) dann gehts, sende ich kurze kommandos geht auch - nur jeweils wenn es länger oder komplex ist kann die empfangsroutine die pakete nicht teilen/auswerten (als ob du nicht prüfen würdest auf die zu empfangene länge). Hier mal eine raw übersetzung von dem was Hantek gesagt hat: > A host computer reads the waveform data flow > To read the with a PC the DSO waveform data, lock keypad and then > read the memory depth, waveform storage memory to allocate a large > enough space, then the size of the received waveform data to determine > the size of the data to actually receive (if does not receive the data > size, and after to determine the size of the data reception.) finished > size of the data is received, the received waveform data, if the > machine waveform data is not ready, the PC will receive a data command. > Waveform display receives this command, the host computer will retain > the last valid data received and displayed. When data reception is > complete, the PC will receive a completed command to indicate a > waveform receiver is complete, then the host computer to the DSO > unlock the keypad. D.h. die werten die den buffer auf die jeweilige paket länge bevor das paket weiter verarbeitet wird, ich blicke nicht durch ob du es auch so machst.
Auf Linux lese ich Antworten vom Oszilloskop wie folgt: 1. Puffer der Größe wMaxPacketSize aus dem USB-Deskriptor (bei mir 64 Bytes) allozieren. 2. Ein Paket lesen. 3. Diverse Konsistenz-Tests (Kein Timeout? Kein Lesefehler? 0x53 Markierung? Überhaupt genug Daten um mindestens die Längenbytes auszuwerten? Usw.). Wenn Fehler weiter mit Punkt 11. 4. Längenbytes auswerten. 5. Puffer entsprechend Längenbyte vergrößern oder verkleinern 6. Wenn empfangene Daten vollständig, d.h. die Antwort ist komplett im Puffer -> weiter mit Punkt 10. 7. Versuchen Anzahl der noch fehlenden Bytes an einem Stück zu lesen. Das Ergebnis kann weniger Bytes als gewünscht enthalten, wenn das Oszilloskop zu langsam ist. 8. Diverse Tests (Kein Timeout? Kein Lesefehler?) Wenn Fehler -> Weiter mit Punkt 11. 9. Weiter mit Punkt 6. 10. Prüfsumme berechnen. Wenn OK -> Fertig 11. Eventuell gelesene Daten verwerfen. 12. Eingang flushen, falls noch irgendwas vom Oszilloskop kommt 12. Fertig mit Fehlermeldung. Die Ebene drüber sieht sich dann das Kommandobyte in der Antwort an, ob es zur Anfrage passt. Wenn ja, und die jeweilige Antwort hat noch ein Subkommando, dann wird das Subkommando ausgewertet. Z.B. um zu entscheiden, ob weitere Daten gelesen werden müssen. Wenn das so ist, dann gehen die in einen eigenen Puffer, in dem nur die Daten, nicht die ganzen Meldungen, zusammengesetzt werden. Bis die Antwort mit dem Subkommando mit der Datenprüfsumme kommt.
Hallo Thomas und Hannes, also soweit runter wie Hannes geht, kann bzw. muss ich nicht. Ich bekomme per Windows-Funktion 'DeviceIoControl' schon z.B: die 10.000 Byte Pakete bei den Sample-Daten. Ich habe das Problem, wenn ich unpassende Antworten vom DSO bekomme, diese verwerfe und nochmals per 'DeviceIoContrrol' nachfrage ob jetzt vielleicht die gülte Antwort kommt, das Programm hängen bleibt wenn das DSO doch nichts sendet. Wenn ich mich aber streng an das Protokoll halte und bei jeder Unregelmäßigkeit abbreche, bekomme ich fast keine Daten vom DSO. Also z.B: die Bildschirmkopien funktionieren so einfach nicht. Ich werde aber nochmals von vorne beginnen, es sind ja nur zwei Prodzeduren die für das Protokoll zuständig sind. Als Alternative könnte ich mit dem Windows USB-Treiber 'winusb.sys' zugreifen, der kann auch asynchron arbeiten, nur ist der aber erst ab Vista standardmäßig dabei. Peter
Hallo Thomas, Thomas R. schrieb: >> To read the with a PC the DSO waveform data, lock keypad and then >> read the memory depth, waveform storage memory to allocate a large Im Moment sperre ich das Bedienfeld nur während des Auslesens der DSO-Einstellungen. Nicht wenn ich die Sample-Daten lese, darum gibt es auch die Probleme wenn während des Auslesens z.B. der Trigger-Kanal verschoben wird. > D.h. die werten die den buffer auf die jeweilige paket länge > bevor das paket weiter verarbeitet wird, ich blicke nicht > durch ob du es auch so machst. Ich werte eigentlich schon alles aus, die einzelnen Pakete sind nicht das Problem. Eher der Ablauf der Kommunikation wegen dem Protokoll und den unbekannten Antworten. Peter
Hallo Hannes, hast du etwas Quellcode? Vielleicht kann ich mir was abschauen und komme so auf meine Fehler drauf. Peter
Hallo, Peter Dreisiebner schrieb: > Hallo Thomas, > > Thomas R. schrieb: >>> To read the with a PC the DSO waveform data, lock keypad and then >>> read the memory depth, waveform storage memory to allocate a large > > Im Moment sperre ich das Bedienfeld nur während des Auslesens der > DSO-Einstellungen. > Nicht wenn ich die Sample-Daten lese, darum gibt es auch die Probleme > wenn während des Auslesens z.B. der Trigger-Kanal verschoben wird. Es ändert nichts wenn ich das Bedienfeld auch während dem Auslesen der Sample-Daten sperre, ich bekomme leider schnell einen Timeout wenn ich die Kanäle verschiebe. Bei anderen Einstellungen, wie Menü ein/aus, Volt/DIV ändern, Trigger ändern, Kanal ein/aus, gibt es soweit kein Problem. Peter
Angehängte Dateien:
-
Capture1.JPG
260 KB -
Capture2.JPG
260 KB
Peter, anbei bilder von dem was dein tool macht und was eine einfache write und zwei mal read verursachen. Wie gesagt, mit deinem tool kommet ein paket der eigentlich zwei beinhaltet, einfaches write/2xread tut es wie es sein sollte. Wenn ich zwischen jedem write/2xread block 50ms lasse kann ich 100mal hintereinander lesen und jedesmal sind die daten sauber (jedes read saubere paket, checksum ok). Anbei noch log von deinem tool (im debug mode), habe nur gestartet und direkt versucht protocol.inf zu lesen.
Hallo, ich habe eine Testversion bereitgestellt, vielleicht mag sie jemand ausprobieren: http://www.dreisiebner.at/dso-usb-tool/DSO-USB-Tool_Exe_20120408test.zip Ich habe alle Vermutungen beim Protokoll entfernt und halte mich an die Vorgaben. Prüfsumme, Paketgröße, Antwort auf richtige Nachricht usw. wird geprüft, bei Fehler wird abgebrochen. Das Ding funktioniert noch immer, was mich jetzt wundert. Ich habe aber einen Timer eingefügt, der wie TTscope jede halbe Sekunde die DSO-Einstellungen einliest. Der Timer wird bei der Bedienung noch nicht berücksichtigt, man muss also manchmal mehrmals auf eine Schaltfläche klicken bis sie reagiert. Bei der Kurvendarstellung 'Wave' geht auch alles besser, sogar Autoset und Speicher umstellen funktioniert. Nur wenn ich oft und flott die sichtbaren Kanäle im Programm in der vertikalen verschiebe gibt es noch Timeouts. Dann hilft bei mir nur das Programm zu beenden, die USB-Verbindung zu trennen, und die 'dso.exe' am DSO neu starten. Ohne Neustart der 'dso.exe' gibt es auf der Konsole eine Fehlermeldung mit 'rpc' und ungültigen Buffer, habe es mir jetzt nicht genau gemerkt.Will den Fehler gerade provozieren und es gelingt mir nicht :-) Schaut also gut aus. Peter
hehe, wir haben gleichzeitig gepostet gut, teste ich sofort :)
Hallo Thomas, Thomas R. schrieb: > Peter, > > anbei bilder von dem was dein tool macht und was eine > einfache write und zwei mal read verursachen. > Wie gesagt, mit deinem tool kommet ein paket der eigentlich zwei > beinhaltet, einfaches write/2xread tut es wie es sein sollte. > > Wenn ich zwischen jedem write/2xread block 50ms lasse > kann ich 100mal hintereinander lesen und jedesmal sind die daten > sauber (jedes read saubere paket, checksum ok). > > Anbei noch log von deinem tool (im debug mode), habe nur gestartet > und direkt versucht protocol.inf zu lesen. ja, ist eindeutig ein Fehler von mir, wenn ich mir den Code jetzt nach einiger Zeit wieder anschaue, sehe ich die Fehler sofort. Da war ich am Beginn mit dem Protokoll und den vielen Unbekannten überfordert. Theoretisch müsste es mit der Testversion besser sein, wobei ich mir alles nochmals anschauen werde. Peter
Hallo Thomas, Peter Dreisiebner schrieb: > Hallo Thomas, > > Thomas R. schrieb: >> Peter, >> >> anbei bilder von dem was dein tool macht und was eine >> einfache write und zwei mal read verursachen. >> Wie gesagt, mit deinem tool kommet ein paket der eigentlich zwei >> beinhaltet, einfaches write/2xread tut es wie es sein sollte. > > ja, ist eindeutig ein Fehler von mir, wenn ich mir den Code jetzt nach > einiger Zeit wieder anschaue, sehe ich die Fehler sofort. Da war ich am nur zur Klarstellung, ich habe den Fehler gemacht noch Daten vom DSO zu lesen obwohl es keine passende Antwort vom DSO gab, dadurch der Timeout. Aber das zusammengestückelte Paket ist nicht von mir, das kommt so vom USB-Treiber bzw. vom 'DevideIoControl'-Aufruf zurück. Da habe ich keinen Einfluss. Peter
Hallo, jetzt habe ich auch wieder sofort einen Timeout bei der Kurvendarstellung, obwohl ich nichts geändert habe und es gestern so gut funktioniert hat. Aber hier ist die erwähnte Fehlermeldung von der Konsole: usb_recv: RPC for non-existent buffer Ohne Neustart der 'dso.exe' geht dann nichts mehr. Schön langsam glaube ich, ich sollte es bleiben lassen. Peter
Hallo, so einen Versuch noch: http://www.dreisiebner.at/dso-usb-tool/DSO-USB-Tool_Exe_20120408btest.zip Ich lese jetzt die Kanäle getrennt ein, also Bedienfdeld, sperren, DSO-Einstellungen lesen, Sample-Daten für Kanal x lesen, Bedienfeld entsperren, Kurve anzeigen, dann das gleiche für den anderen Kanal. Jetzt geht es wieder ohne Probleme, nur wer weiß wie lange? Bei den anderen Funktionen im Programm gibt es ansont bei mir keine Fehler. Peter
Hallo, sorry, falls ich mit den vielen Postings lästig bin. Ich habe die Exe vom letzten Link nochmals aktualisiert. Die Anzeige der Kurven ist jetzt gleichzeitig, das verwirrt sonst. Getestet habe ich auch unter Windos 7, im Moment lauft es wie es soll. Ich kann am DSO kurbeln wie ich will, kein Hänger. Nur ab 4 ms/DIV wird das Triggern träge, da gibt es Aussetzer, ich lese die Daten bei Triggerstatus Triggered, Auto- und Scan Modus. @Thomas: Warum steht in dem Flussdiagramm nicht bei Triggerstatus Ready triggern? Was bedeutet der Status genau? Peter
Hallo, die aktuelle Version ist mit Code wieder online: http://www.dreisiebner.at/dso-usb-tool/ Peter Edit: Nebenbei lauft das Tool unter Windows 7, und ich ändere immer wieder die Kanäle am DSO, jetzt sind es 8400 Kurven die ohne Fehler in einem Stück gelesen wurden. Sieht man wenn man die 'Debug'-Option anklickt.
Peter Dreisiebner schrieb: > Hallo, > > sorry, falls ich mit den vielen Postings lästig bin. unsinn > Ich habe die Exe vom letzten Link nochmals aktualisiert. Die Anzeige der > Kurven ist jetzt gleichzeitig, das verwirrt sonst. Getestet habe ich > auch unter Windos 7, im Moment lauft es wie es soll. Ich kann am DSO > kurbeln wie ich will, kein Hänger. jo, soweit alles ok auf dem bench. Für handheld leider keine veränderungen sichtbar. > Nur ab 4 ms/DIV wird das Triggern träge, da gibt es Aussetzer, ich lese > die Daten bei Triggerstatus Triggered, Auto- und Scan Modus. > also eigentlich (siehe unten - wobei ob autostop sinn macht weiss ich nicht) genau so wie Hantek. Das es träge wird ist klar. Zwei kleine kosmetische fehler habe entdeckt: - im roll mode wird eine linie gezeichnet zwischen alten/neue daten, da sollte eigentlich nix sein. -im stop mode kann man die letzte wave nicht verschieben, wobei ich denke hier bist du noch gar nicht fertig (wegen zoom usw.) > @Thomas: Warum steht in dem Flussdiagramm nicht bei Triggerstatus Ready > triggern? Was bedeutet der Status genau? > du meinst "DSO state"? Das ist der trigger status (auf chinesich steht eigentlich "status vom DSO zustand ist nicht "stop, armed, ready"). laut diagram wird der nur benutzt um zu sehen ob es noch daten kommen ([TRIG-STATE] = 2,3,4,5) oder (noch)keine mehr ([TRIG-STATE] = 0,1,6). Warum das so ist kann ich dir nicht sagen, gehe davon aus das die Hantek leute es wissen warum (wobei eigentlich wird es nur der ursprungliche Tekway mensch wissen warum).
meine ergebnisse beziehen sich auf xxxx08btest, teste später die 09
Hallo Thomas, Thomas R. schrieb: > jo, soweit alles ok auf dem bench. Für handheld leider keine > veränderungen sichtbar. wenn es dieselben Fehler in den USB-Datenpaketen sind wie du schon gepostet hast, weiß ich im Moment nicht was ich tun kann. > also eigentlich (siehe unten - wobei ob autostop sinn macht weiss > ich nicht) genau so wie Hantek. Mit autostop meinst du 'Single Sequenz'? Jetzt verwende ich Auto (2), Triggered (3) und Scan (4). > - im roll mode wird eine linie gezeichnet zwischen alten/neue daten, > da sollte eigentlich nix sein. Ja, habe ich auch bemerkt, da müsste ich die Daten extra untersuchen, muss ich mir anschauen. > -im stop mode kann man die letzte wave nicht verschieben, wobei ich > denke hier bist du noch gar nicht fertig (wegen zoom usw.) Fertig? Ha, ein Scherz :-) Vor lauter Ideen weiß ich gar nicht wo ich anfangen soll. Ich habe nur keine Erfahrung mit dem verarbeiten und aufbereiten von Messdaten. Ich mache das alles nur weil es mich interessiert, von können ist keine Rede. > meine ergebnisse beziehen sich auf xxxx08btest, teste später die 09 Beim Auslesen hat sich nichts geändert, müsste gleich funktionieren. Peter
Hallo Thomas, Thomas R. schrieb: > Das es träge wird ist klar. Zwei kleine kosmetische fehler habe > entdeckt: > - im roll mode wird eine linie gezeichnet zwischen alten/neue daten, > da sollte eigentlich nix sein. ich habe bemerkt, dass ich um ein Pixel zu weit unten zu zeichnen beginne, ist geändert. Die Daten die ich zeichne bekomme ich so wie dargestellt. Ich habe keinen Anhaltspunkt für alt und neu, zumindest in den Settings finde ich keine passenden Wert dazu. Und wenn Samples auf Null liegen kann ich nicht entscheiden ob die jetzt richtig oder falsch sind. Wenn ich die Samples nicht verbinde, gibt es Lücken in der Darstellung. Peter
Hallo, ich glaube das mit dem Protokoll passt jetzt. Habe auch unter Windows 7 64 bit getestet, lauft ohne Probleme. Es gibt zwar manchmal Timeouts, aber nur wenn man am DSO viel herumschaltet. Übrigens kann man am DSO die FFT- oder XY-Darstellung aktivieren und das Programm zeigt die normalen Kurven, an das habe ich gar nicht gedacht. Wenn das jetzt so stabil bleibt könnte man schon einiges mit den Sample-Daten anfangen. Peter
Angehängte Dateien:
-
Capture1.JPG
97 KB -
Capture2.JPG
89 KB
wegen dem buffer problem beim handheld und BM/BMV modelen: wenn ich die pfDirectUSB auf true setze hängt die app zwar sehr oft dafür aber (wenn die nicht hängt) die übertragung klappt. Einmal sogar kamm die Waveform durch bevor die app hing. Das heisst der fehler muss irgendwo bei den buffern übertragung zwischen main app und dem usb worker. Am besten würde ich dir den handheld für ein paar tage zum testen geben, will/kann ich aber nicht weil der noch verkauft werden muss. Ich habe allerdings noch ein austausch board mit def. FPGA, sollte ich den zum laufen bekomme könnte ich es dann zu dir schicken. Das wäre zwar ohne display und panel, aber zum testen reicht eigentlich.
Hallo Thomas, Thomas R. schrieb: > wegen dem buffer problem beim handheld und BM/BMV modelen: > wenn ich die pfDirectUSB auf true setze hängt die app zwar sehr oft > dafür aber (wenn die nicht hängt) die übertragung klappt. > Einmal sogar kamm die Waveform durch bevor die app hing. da schau her, es funktioniert sogar. > Das heisst der fehler muss irgendwo bei den buffern übertragung > zwischen main app und dem usb worker. Klingt für mich jetzt unlogisch, aber ich schau mir das an. Es funktioniert ja beim Bench-DSO, da ändert sich in der Kommunikation zwischen Tool und USB-Worker ja nichts. > Am besten würde ich dir den handheld für ein paar tage zum testen geben, > will/kann ich aber nicht weil der noch verkauft werden muss. Ich habe > allerdings noch ein austausch board mit def. FPGA, sollte ich den zum > laufen bekomme könnte ich es dann zu dir schicken. Das wäre zwar ohne > display und panel, aber zum testen reicht eigentlich. Ist da ein anderer USB-Teiber am PC notwendig? Kann der auch mit dem Bench-DSO kommunizieren, dann könnte ich den mal installieren zum Testen. Wenn das Protokoll gleich ist, woran soll es sonst liegen? Peter
Hallo Thomas, ich habe gerade das Programm ebenfalls mit pfDirectUSB kompiliert, die Update-Rate ist doppelt so schnell und es lauft ohne Hänger, hätte ich jetzt nicht drauf gewettet. Muss wohl etwas mit dem USB-Treiber anders sein. Peter edit: Ich bau das als Option beim Log-Fenster ein.
Peter Dreisiebner schrieb: > > ich habe gerade das Programm ebenfalls mit pfDirectUSB kompiliert, die > Update-Rate ist doppelt so schnell und es lauft ohne Hänger, hätte ich > jetzt nicht drauf gewettet. am anfang war deine read routine noch etwas anders, jetzt ist sie viel sauberer da mag auch der direkt zugriff besser gehen. Für handheld scheint es die lösung zu sein (teilweise - da manche sachen noch nicht stimmen, das mag aber an den kleinen unterschieden in den settings usw liegen). > > Muss wohl etwas mit dem USB-Treiber anders sein. > nein, der treiber am PC ist der selber. Allerdings die andere seite verwendet ein anderes treiber (nicht nur wegen neueren linux kernel). Dies spielt zwar eine rolle, aber nur mariginal da der treiber sich genau so verhält was die befehle angeht - nur timing mag evt. anders sein. > > > edit: Ich bau das als Option beim Log-Fenster ein. gute idee, danke.
Hallo, >> edit: Ich bau das als Option beim Log-Fenster ein. > > gute idee, danke. ist online aktualisiert. Als Standard wird mit dem USB-Worker gestartet, man kann aber jederzeit umstellen. Hier funktioniert es bis jetzt sehr gut. Bei den 'Wave Options' -> 'Debug' gibt es auch eine Update/sec. Anzeige, da sieht man schön den Unterschied. Peter
Hallo Thomas, ich habe den Code für die direkte Kommunikation jetzt mehrmals gelesen, ein paar Sachen sind mir augefallen. Bei deinen Beitrag mit dem kaputten USB-Paket fällt mir folgendes dazu ein. Beitrag "Re: TEKWAY DST1xx2B Oszilloskop" Das DSO-Paket mit den knapp 4000 Bytes bekomme ich in einem Stück, da habe ich keinen Einfluss. Wenn jetzt zwei Pakete in einem sind, passieren Fehler weil ich von falschen Voraussetzungen ausgegangen bin. Die Prüfsumme stimmt z.B dann nicht, ich lese nur das letzte Byte, aber nicht die Position von der Längenangabe im Protokoll wenn die Daten größer sind, somit wird das Paket verworfen. Das werde ich ändern. Was ich aber mit dem zweiten Paket machen soll weiß ich nicht, das würde einfach verloren gehen. Den in dem Moment wo ich das Paket empfange, erwartet die aufrufende Prozedur ein Paket zurück, die fragt nicht nach ob es noch eins gibt. Wenn das aber so normal ist, muss ich die Logik umbauen, geht sicherlich. Zum Glück sind es nur zwei Prozeduren die sich um die DSO-Pakete kümmern. Peter
wie gesagt, für handheld reicht wenn es ohne die usb worker geht. Wenn es also dabei bleibt das die app entweder ohne worker oder per option abschaltbar bleibt ist alles ok. Klar, es gibt kleine unterschiede bei den DSO settings und dadurch geht alles was von den settings abhängig ist nicht, aber das kriege ich schon hin (und dann sende dir die lösung dafür). Ich bekomme schon bald auch ein bench BMV model, dann kann ich damit auch durchtesten.
Hallo Thomas, Thomas R. schrieb: > wie gesagt, für handheld reicht wenn es ohne die usb worker geht. > Wenn es also dabei bleibt das die app entweder ohne worker oder > per option abschaltbar bleibt ist alles ok. ich gehe über das DSO-Modul nochmal drüber und möchte den USB-Worker dann los werden. Nur mit der Oberfläche muss dann was machen, die wird träge weil die USB-Übertragungen blockieren, das übernimmt ja bis jetzt der USB-Worker. > Klar, es gibt kleine unterschiede bei den DSO settings und dadurch > geht alles was von den settings abhängig ist nicht, aber das kriege > ich schon hin (und dann sende dir die lösung dafür). Wenn du Infos hast, kann ich was einbauen zum Abfragen ob Bench oder Handheld. > Ich bekomme schon bald auch ein bench BMV model, dann kann ich damit > auch durchtesten. ha, und Video schauen :) Peter
Alois Neumann schrieb: > Thomas R. schrieb: >> Falls jemand von euch ein Altera JTAG cable hat und ein Voltcraft DSOs >> oder Hantek/Tekway hw 1007x555583e9 (nicht 83e8!) würde ich mich >> freuen wenn derjeniger einen dump von dem MAX II CPLD machen würde >> (die sind nciht copy protected). Hi Thomas, schau mal in dein Postfach. Gruss Alois ;)
mal eine kurze Zwischenfrage. Habe Probleme eine SPI Verbindung sauber auf dem Oszi darzustellen. Die ganze Kurve zittert bei mir. Trigger ist natürlich richtig gesetzt. Gibt es eine Firmware die das behebt. Verwende noch Version 111124.0 Gruß Christoph
Christoph B. schrieb: > Trigger ist natürlich richtig gesetzt. Berühmte letzte Worte. Wie sollen das jemand überprüfen können, wenn du uns nicht einmal verrätst, wie der Trigger gesetzt ist?
Hallo Christoph, Christoph B. schrieb: > muss er speziell gesetzt werden? da hilft möglicherweise nur das DSO neu einzuschalten. Ich habe hier auch, aber selten, Probleme mit dem Triggern. Da ich das DSO-Tool teste, drücke ich öfters AUTOSET, und habe nur beide Kanäle am Probe Check-Signal hängen. Wenn das DSO dann nicht triggerd, hilft auch kein manuelles nachbessern, nur das aus-/einschalten oder die 'dso.exe' neu starten. Kommt aber wie gesagt sehr selten vor. Peter
Hallo Christoph, Christoph B. schrieb: > Habe das DSO schon neu gestartet. An dem liegt es nicht du könntest auch einen Screenshot senden, wo man das Signal und die Einstellungen sieht, vielleicht kann dann jemand helfen. Peter
das klingt jetzt wirklich blah ... Bei dem DSO gibts kein SPI trigger, also triggerst du auf irgendetwas, der fehler kann also : - am trigger einstellung liegen - trigger implementierung in fw - jitterigen signal mögliche Lösungen: - selbstkaliebrierung durchführen - kanal auf AC, trigger auf AC, triger level auf 0 - auto benutzen - auf pulse länge triggern - auf slope triggern - zoom verkleinern (falls im dual window mode) usw. falls der trigger immer noch spinnt (und das signal nicht jitterig ist) prüfen ob tdc_edge125M, tdc_overtime125M und tdc_pulse125M vorhanden sind <- evt. ist die factory cal falsch. Einfach ls -l im DSO-Tool ausführen und size (so um 1k sollte es sein) und datum (sollten alle vom selben tag sein) prüfen. Und ja, irgendwie muss man öffters autoset bei den letzte fw versionen benutzen, ob es am trigger fehler oder den nicht 100% durchgeführten änderungen in timebase routinen liegt weiss ich nciht.
Angehängte Dateien:
-
dso-tool-protokoll.png
50 KB
Hallo, ich habe eine neue Version online gestellt, es wird jetzt auf den USB-Worker verzichtet: http://www.dreisiebner.at/dso-usb-tool/ Das Tool ist jetzt eigentlich genauso anfällig für das Einfrieren wie vorher, es geht aber ganz gut. Nur bei der Kurvendarstellung hängt es oft wenn man die Kanäle vertikal verschiebt. Ansonst kann man alles machen, unter XP sogar Autoset, dass geht bei Windows 7 nicht. @Thomas und Hannes: Anbei auch ein Screenshot mit meinen Debug-Ausgaben. Wenn bei der Kurvendarstellung die Kanäle verschoben werden bekomme ich die Fehler mit falscher Antwort, und danach hängt das Programm direkt beim Aufruf des USB-Treibers bei 'DeviceIoControl. Nach Ab-/anstecken des USB-Kabels geht es weiter, aber nur kurz, dann kommt meist auf der DSO-Konsole die Meldung 'usb_recv: RPC for non-existent buffer'. Ich weiß nicht wo der Fehler ist oder wie ich damit umgehen soll. Peter
Hallo, Peter Dreisiebner schrieb: > Anbei auch ein Screenshot mit meinen Debug-Ausgaben. Wenn bei der > Kurvendarstellung die Kanäle verschoben werden bekomme ich die Fehler > mit falscher Antwort, und danach hängt das Programm direkt beim Aufruf > des USB-Treibers bei 'DeviceIoControl. also bei TTScope ist es genauso, ein paar mal die Kanäle verschieben und die Anzeige friert ein. Ein Neustart von TTScope zeigt dann einen Verbindungsfehler. Peter
Hallo, so einmal noch, dann gebe ich Ruhe. Die empfangenen DSO-Datenpakete sind vor dem Einfrieren immer kaputt, es fehlt die Prüfsumme. Ich habe jetzt zehnmal hintereinander getestet, immer dasgleiche, auch mit SnoopyPro direkt die USB-Daten angeschaut. Ich empfange z.B.: "53 04 00 82 02 01" als Antwort, die Längenangabe stimmt nicht bzw. die Prüfsumme fehlt. Die Antwort habe ich zuvor aber richtig empfangen, erst bei der nächsten Anfrage für z.B. Bedienfeld sperren kommt der Fehler zurück. Es wird wohl ein Fehler in der Firmware sein denke ich, also heißt es abwarten. Peter
Hallo, ich habe den Fehler möglicherweise gefunden, ich habe das Bedienfeld zweimal hintereinander entsperrt. Ein Testversion gibt es unter folgenden Link, vielleicht mag es wer testen und Rückmeldung geben. Es betrifft nur die Kurvendarstellung 'Wave', alles andere funktioniert eigentlich ohne Probleme. http://www.dreisiebner.at/dso-usb-tool/DSO-USB-Tool_Exe_20120413test.zip Peter
Hallo, ich glaube ich habe einen neuen Fehler beim Alternate-Trigger entdeckt, Firmware 2.06.3(120224.0). Ich kann nicht die vertikale Triggerposition von Kanal 2 ändern, es wird immer nur Kanal 1 verändert. Peter
Hallo Peter, die Triggerposition von Kanal 2 kann man mit V0 einstellen. MfG egonotto
Hallo egonotto, danke, egonotto schrieb: > die Triggerposition von Kanal 2 kann man mit V0 einstellen. peinlich, der Hinweis wird sogar eingeblendet wie jetzt erst sehe. Peter
wie in dem Voltcraft thread schon geschrieben gibt es neue firmware auf Hantek website. Die passt auch für die Tekway http://www.hantek.com/Product/DSO5000Series/DSO5000/DSO5202B_Firmware.rar Es sind erst 5 1/2 von 22 fehler gefixt, mehr dazu hier Beitrag "Re: VOLTCRAFT DSO-3062C 60 MHz = baugleich mit?"
Hallo, mit der neuen Firmware 120423 gibt es keine Ausgaben auf die Konsole im normalen Betrieb, die Bootmeldungen sind auch kürzer. Das fehlt mir jetzt schon etwas. Peter
Peter Dreisiebner schrieb: > Hallo, > > mit der neuen Firmware 120423 gibt es keine Ausgaben auf die Konsole im > normalen Betrieb, die Bootmeldungen sind auch kürzer. > Das fehlt mir jetzt schon etwas. > > Peter ja, leider ist das so. Alle debug, console nachrichten sind weg. Auch die exports sind weg: http://www.mikrocontroller.net/attachment/142149/alt.JPG http://www.mikrocontroller.net/attachment/142150/neu.jpg beacte auch den watchdog Beitrag "Re: VOLTCRAFT DSO-3062C 60 MHz = baugleich mit?"
wen ich save to usb drücke speichert er immer nur bilder, kan ich irgendwie die daten als xml file doer txt file oder so bekommen mit den einzelnen messpunkten? LG Owen
hier ein paar eeprom hack informationen, http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg108309/#msg108309
Zwar haben Hantek und Tekway die GPL download links schon in den jeweiligen user manual angepasst, allerdings auf der jeweiligen produktseite sind die verbogen (Hantek). Anscheinend hat der webadmin etwas falsch verstanden und nur kraut gepostet, solange die nicht geändert sind hier die funktionierende links: Für Hantek DSO5xxxB, und Voltcraft DSO3062C modele: http://www.hantek.com/download/desktop.zip Für Tekway DST1xxxB, DST4xxxB, DST3xxxB modele: http://203.81.29.13:2108/ Die beiden unterscheiden sich eigentlich nicht. Es gibt aber eine neuere version die auch root fs beinhaltet: http://203.81.29.13:8888/desktop.zip Für Hantek Handheld DSO1xxxB/BV modele: http://www.hantek.com/download/handscope.zip oder http://203.81.29.13:8888/handscope.zip Für Hantek DSO5xxxBM/BMV modele: http://www.hantek.com/download/desktop_video.zip oder http://203.81.29.13:8888/desktop_video.zip Für Tekway MST1xxx modele: http://www.hantek.com/download/desktop_logic.zip oder http://203.81.29.13:8888/desktop_logic.zip Alle diese dateien beinhanlten auch die root_fs passend zu jeweiligen kernel. Es lohn alles zu downloaden, logischerweise sind sachen vermischt ... Hantek desktop sources beinhalten kernel 2.6.13 aber root_fs für 2.6.30.4, dafür die desktop_logic sources andersrum :) Es lohnt auch die ersten GPL sources zu laden: http://ftp.gpl-devices.org/pub/vendors/Voltcraft/VOLTCRAFT_dso3000series.zip die beinhalten ein paar tools die wieder entfernt worden sind bei den neueren versionen. Auch die sources von handheld/mixed/video modelen sind interessant, alleine schon wegen kernel/root_fs und drivers - so kann man schon das "B" model auf BM/BMV updaten.
ahja, und hier gibts auch noch kopie von qq2440 dvd http://203.81.29.13:7635/ und nocheinmal nur 2.6.13 root_fs.
wie finde ich das denn? 7,5kbit download bei fast allen Links und dann bricht's auch noch ab, weil Zeitlimit überschritten und das mit einer 16000er Leitung. :-((( Gibt's noch andere Download-Quellen, die mehr hergeben? Gruß Michael
Ein klassischer Fall für einen Torrent! Hat jemand schon alle files und kann diese als Torrent zur Verfügung stellen? Da das alles GPL ist sollte doch nichts dagegen sprechen.
ach was, seit einer stunde 70k durchgehend. Nimm http://www.freedownloadmanager.org/ und gut ist, brauchst kein krampf mit torrents uplink speed (wobei das kann es auch)
Lukas P. schrieb: > Ein klassischer Fall für einen Torrent! Hat jemand schon alle files und > kann diese als Torrent zur Verfügung stellen? Da das alles GPL ist > sollte doch nichts dagegen sprechen. Wie wärs mit http://sourceforge.net/ ? Da gibtz auch gleich ein SVN mit dabei.
Hallo Da ich mir auch ein Oszi kaufen will lese hier schon lange mit und es ist erstaunlich was man hier so leistet. Mich würde das Hantek DSO5062B interesieren. Meine frage währe wo kann ich solches in Österreich oder in Deutschland kaufen. Mfg. team151
Fritz Sch. schrieb: > Meine frage währe wo kann > ich solches in Österreich oder in Deutschland kaufen. Hallo Fritz, am besten mal nach googlen... Beim grossen C sind sie wohl wieder in der 60MHz Version und damit nach 200MHz umbaubar erhältlich, ansonsten wenns ein Original sein soll, gibts auch chinesische Versender in der Bucht. Die sind wohl am günstigsten, obwohl das bezüglich Rechnung, so man denn eine braucht, so seine Tücken hat ;) Auf der anderen Seite: Wegen Garantie muss man sich bei den Chinesen keine Sorgen machen. Ausgetauscht wird problemlos. Gruss Peter
Hi Thomas R. (Ich hoffe, es ist erwünscht) kannst du bitte mal nen neuen Thread aufmachen ? Nach > 730 Beiträgen (Glückwunsch :) benötigen einige Browser schon viel Zeit um diesen interessanten Thread anzuzeigen. Neuer Thread sollte vielleicht Link auf diesen Thread beinhalten und einen Zwischenstand: was geht und was nicht geht... Danke an alle Entwickler und Leser D
yatko schrieb: > Hi Thomas R. > > (Ich hoffe, es ist erwünscht) > > kannst du bitte mal nen neuen Thread aufmachen ? Nach > 730 Beiträgen > (Glückwunsch :) benötigen einige Browser schon viel Zeit um diesen > interessanten Thread anzuzeigen. > unsinn, geht super schnell, benutze einfach "Seitenaufteilung einschalten" funktion. Das geht sogar auf meinem Nokia E90 ohne schmerzen.
> unsinn, geht super schnell, benutze einfach > "Seitenaufteilung abschalten" der Thomas... :-) nein: Mußt natürlich die "Seitenaufteilung einschalten", erst dann gibt's die Häppchen-Seiten. Ich glaube, diese Opztion geht nur, wenn man hier einen Accound hat und angemeldet ist. Gruß Michael
Hallo, mein Tekway DST1062B (1005er Hardware) spinnt auf einmal rum obwohl ich nix verändert hab, Firmware ist 2.06.3 (12011.2.1) und der 2. Kanal geht mal und mal nicht. Geht er nicht, dann muss ich eine Kalibrierung durchführen, ohne die geht der Kanal selbst nach einem Reset nicht. Wenn ich die Position bei dem 2. Kanal wenn er nicht geht (zeigt kein Eingangssignal an, einfach nur ne Spannung) veränder, dann verschiebt sich diese Spannung und wird größer oder kleiner. Nach einer Kalibrierung geht wieder alles einwandfrei. Ist das ein Bug in der Firmware oder ist die Batterie leer? Oder ist das Gerät kaputt und ich muss es einschicken? MFG Johannes
Hi, Johannes R. schrieb: > mein Tekway DST1062B (1005er Hardware) spinnt auf einmal rum obwohl ich > nix verändert hab, Firmware ist 2.06.3 (12011.2.1) und der 2. Kanal geht > mal und mal nicht. Geht er nicht, dann muss ich eine Kalibrierung > durchführen, ohne die geht der Kanal selbst nach einem Sofern mich meine Erinnerung nicht trügt: WENN du noch Gewährleistung hast und der VK im Europäischen Raum sitzt (Versandkosten) würde ich - egal ob es jetzt eine Chance gibt das selbst zu regeln- nicht weiter nach dem Fehler suchen sondern das Gerät schnellstens einsenden. Wie gesagt -vorrausgesetzt ich erinnere mich richtig- war es doch so das die 1005er HW eine schlechte Zwischenversion war die einige Macken und Nachteile aufwies welche die Vorgänger und NAchfolger nicht haben. Bisher wurden die nach den hier zu lesenden Ausssagen dann gegen neuere Boardversionen ausgetauscht. Aber warte am besten noch mal auf Thomas Antwort, der kann sagen ob ich das jetzt richtig im Kopf habe... Gruß Carsten
Johannes R. schrieb: > Hallo, > > mein Tekway DST1062B (1005er Hardware) ich dachte Du hast den schon mal getauscht auf hw1007. Grunsätzlich ein 1005 würde ich nicht haben wollen, die neigen instabil zu sein, mit oder ohne grund (mit der zeit). > spinnt auf einmal rum obwohl ich > nix verändert hab, Firmware ist 2.06.3 (12011.2.1) und der 2. Kanal geht > mal und mal nicht. Geht er nicht, dann muss ich eine Kalibrierung > durchführen, ohne die geht der Kanal selbst nach einem Reset nicht. > > Wenn ich die Position bei dem 2. Kanal wenn er nicht geht (zeigt kein > Eingangssignal an, einfach nur ne Spannung) veränder, dann verschiebt > sich diese Spannung und wird größer oder kleiner. > > Nach einer Kalibrierung geht wieder alles einwandfrei. ja man kann in gewissen grenzen die hardware fehler "wegkalibrieren", dadurch wird aber nix repariert. Ändert sich mal die temperatur verabschiden sich die hw1005 gleich wieder weg. > > Ist das ein Bug in der Firmware oder ist die Batterie leer? Oder ist das > Gerät kaputt und ich muss es einschicken? > wenn du garantie hast dann einschicken. Wenn du pech hast bekommst du restposten-gerät hw1005 (sowas würde ich aber nicht annehmen). Ersatz PCBs für hw1005 gibts es keine mehr, hw1007 past 1:1 rein (für hw0 geräte "auch", allerdings muss stück blech abgesägt werden).
Hallo, das wurde mit der Begründung dass das nur in einem Fall getauscht wird abgelehnt. Werde dann mal morgen telefonieren. Hab keinen Bock das Teil täglich für ne Zweikanalmessung zu kalibrieren. MFG Johannes
ja gut, der händler hat natürlich auch kein leichtes leben, der kann nix für das Hantek/Tekway 3 monate lang schrott produziert haben. Gar nicht lustig ist die tatsache das die hw1005-austauschkosten der händler selber tragen muss (oder den kunden in rechnung stellen, egal wie man dreht ist es viel zu viel geld um es zu akzeptieren). Man bekommt auch keine hw1007 boards auf vorrat - es muss das h1005 eingeschickt werden (66EUR) und hw1007 zurück (66EUR). Es muss auch jemand einbauen und testen (und wehe wenn ersatz PCB DOA war ...), das kostet auch zeit/geld. Die hersteller möchten diese kosten nicht tragen da die PCBs "funktionieren" - zwar muss man bei jedem fw update zittern das die aufhören, aber so ist das schon leben. Es ist zwar bedauerlich das die hw1005 so zickig sind, rein theoretisch sind die aber "voll funktionstüchtig" (mindestens aufgewählte modele beim 22,3° umgebungstemperatur ...) Glaub mir, ob händler oder hersteller - der tag an dem die hw1005 aus der garantie raus sind wird ein guter tag sein. Da ist noch etwas was Hantek/Tekway evt. nicht gemerkt haben, soweit ich es sehen kann die hw1005 melden sich als 83E9 FPGA design (soweit richtig, es war neue version). Dummerweise denkt die firmware das dies hw1007/83E9 sind und schaltet sampling höher (schreibe gleich mehr dazu). So ist jedes hw1005 eine zeitbombe - das hw1005/83e9 design kann nicht schneller getaktet werden und schon gibts noch mehr ärger. Ich würde bei hw1005 keine neure firmwares installieren, 110923.1 dürfte die beste version für die hw1005 sein. -------------------------------------------------------- In deinem fall ist es allerdings einfach, es ist kaputt, da braucht man nicht zu "zaubern". Ein gerät der jede 2 tage ein kanal verliert hat eine macke, man kann es nicht schön reden oder auf hw1005 termische probleme schieben.
Übrigens, falls jemand es noch nicht weisst - sobald die neuesten firmwares ein FPGA design version 83E9 sieht ändern sich die möglichen/maximalen sample rates. Bei 2 kanal betrieb sind es jetzt im long mem mode maximal 500MS/s pro kanal statt 200MS/s wie beim 83E8 design. Bei 1 kanal betrieb sind es jetzt im long mem mode maximal 500MS/s statt 400MS/s. Beim short mem mode unverändert maximal 1GSs bei 1 kanal und 500MS/s bei 2 kanälen. --------------------------------------------------------- Was sind die 83E8, 83E9 ? Im prinzip sind es ausbaustuffen, es gibts z.b. für die langsammen modele (Tekway DST4000, DST3000) FPGA designs markiert als 83ED, 83EE, 83EF, 83F4 und 83F5. Die unterschiede liegen in den maximalen sample rate/speicher verwaltung. So sind auch die Tekway DST1000 als 83E8 und 83E9 verfügbar, und das zwar von anfang an. Leider gabs trigger (oder war das timing?) probleme bei dem allerersten 83E9 design (vom Dez. 2009) so sind alle geräte damals (Feb 2010) zwangupgedated auf die langsamere design vrsion 83E8. Hantek hat dann mit hw1005 mal wieder versucht etwas zu verbessern, allerdings kamm nix gutes daraus. Beim hw1007 ist Hantek/Tekway auf nummer sicher gegangen und direkt mit 83E8 geliefert (auch beim handhelds drauf). Im Nov 2011 haben die endlich geschaft die 83E9 stabiler zu designen. Die ist zwar sehr hart an der grenze (mit 105MHz clock kommt die nicht mehr klar, die 83E8 schaft auch 125MHz - also 1.25GS/s), funktioniert aber auch bei FPGA temperatur änderungen (nicht wie bei hw1005 ...). Auch die firmware sind glaube ich seit Nov/Dez 2011 schneller zu samplen sobald FPGA als 83E9 sich meldet. Und genau hier gibts probleme mit hw1005 (auch hw0 83E9 vom Dez 2009 wird probleme haben, ausser mir hat glaube ich niemand so ein gerät in EU gesehen), die firmware denkt "es ist hw1007/83E9" und schon spinnt ein hw1005 model. Man sieht dann ohne ein signal angelegt zu haben wunderschöne 125MHz sinus auf beiden kanälen. Übrigens, es mag passieren das ein hw1005 trozde sauber läuft, es ist reine glückssache. Übrigens, alle Voltcraft haben die gute 83E9 version drauf. Auch die BM/BMV modele habe es. ---------------------------------------------------------------- Falls jemand es testen möchte, oder was auch immer (z.b. ein hw0/83E8 oder hw1007/83E8 schneller machen) anbei alle FPGA designs die ich raugeben darf: dn_hw0_83E9_date_091201.rbf (erste design version für DST1000B) dn_hw0_83E8_date_100224.rbf (stabile aber langsammere version) dn_hw1005_83E8_date110225.rbf (kompletter Reinfall) dn_hw1005_83E9_date110423.rbf (etwas besser) dn_hw1005_83E9_date110427.rbf (die einzige quasi stabile design für hw1005) dn_hw1007_83E8_date110522.rbf (back to the root) dn_hw1007_83E9_date111122.rbf (das ist die gute 83E9 version) Einfach jeweilge datei rüber auf das DSO kopieren (als /dn.rbf), die /param/sav/run* löschen (oder default setup drucken). Nach dem reboot läuft dann das neue design. ----------------------------------------------------------------- Ich habe auch ein paar neuigkeiten zum thema firmware bugs, werde bei gelegenheit es mehr dazu sagen.
Thomas R. schrieb: > Ich habe auch ein paar neuigkeiten zum thema firmware bugs, Hantek hat ein paar Programmierer gefunden? :-)
Johannes R. schrieb: > das wurde mit der Begründung dass das nur in einem Fall getauscht wird > abgelehnt. @Johannes: Hast Du ein Hochspannungsnetzteil oder irgendwas, das ein paar "KV-chen" mit ein paar µA aber bitte nur in dieser Richtung erzeugen kann? Dann komme mal zufällig damit in die Nähe eines der großen Chips.... Was Du danach machen musst, kannst Du Dir denken :)))))) Nein, die Welt ist nicht schlecht, man muss nur das Beste daraus machen. Gruss Peter
Sonst geht es dir eigentlich noch gut? Wieso sollte ich ein damals funktionstüchtiges Gerät zerstören? Sowas wie ein Sachverständiger kann das feststellen und dann folgt Justizia. Halte dich also in Zukunft mit solchen Ratschlägen zurück. MFG Johannes
Johannes R. schrieb: > Sonst geht es dir eigentlich noch gut? Wieso sollte ich ein damals > funktionstüchtiges Gerät zerstören? > > Sowas wie ein Sachverständiger kann das feststellen und dann folgt > Justizia. > > Halte dich also in Zukunft mit solchen Ratschlägen zurück. Es gibt Leute mein lieber Johannes, mit denen hat man keinen Spass. Die können eine Satire auch nicht von Realität unterscheiden! Und im übrigen, welchen Senf ich wozu gebe, überlasst Du mal schön mir, kapiert? Üben, üben Johannes. Nach einigen Tagen gelingen Dir bestimmt schon die ersten Lächelversuche :))
Hannes Jaeger schrieb: > Thomas R. schrieb: >> Ich habe auch ein paar neuigkeiten zum thema firmware bugs, > > Hantek hat ein paar Programmierer gefunden? :-) fast ... eigentlich war ich mit Hantek am verhandeln, es ging um zusammenarbeit (unter NDA). Das hätte für die zwei vorteile bedeutet - keine hacks mehr von meiner seite (und dummerweise für die habe ich noch einige im petto) und günstige hilfe um die jämmerliche bugs zu beseitigen. Allerdings nach dem Hantek versucht hat mich zu belügen, vorauf ich ein paar "netter wörter" gesagt, herrscht funkstille. Ich bin auch nicht mehr bereit für Hantek die zeit zu invesiteren. Der letzte status war das deren entwickler gestoppt hat die bugs in der aktuellen firmware zu beseitgen und angefangen hat die software komplett umzuschreiben. Es geht natürlich nicht nur um die bekannten bugs aber auch um sachen die nur der entwickler gemerkt hat (wie z.b. keine möglichkeit für 1-2-5 timebase stepping bei den aktuellen fw ohne die hälfte umzuschreiben). Das bedeutet die wollen in den nächsten 2 monaten keine weiter updates rausbringen sondern erst die firmware neu schreiben - ohne bugs natürlich, dann gründlich testen und erst dann veröffentlichen. Ob das am ende eine gute oder schlechte entscheidung war wird sich zeigen. Damit die bugs informationen nicht verlohren gehen habe die die ich kenne in einer pdf gespeichert - siehe anhang. Ich habe bei den workarounds zu den bugs farbig die antworten markiert, das sind meine empfindungen die auch weit von dem was andere denken entfert sein können (für mich ist z.b. AC trigger bug eine kleinigkeit mit der ich locker leben kann, dafür aber der screen refresh bug ein grober schnitzer). Ich werde auch die tage eine patched firmware 2.06.3_120507.x posten wo alles was ich beseitigen konnte beseitig ist. Ich versuche noch die letzten sachen (bugs 20, 22 und 24) zu fixen. Wer nicht warten möchte und die originale 2.06.3_120507.0 installieren möchte kann diese version (nur die dso.exe wird benötigt) aus dem root fs dump (yaffs_2.6.13.bin) extrahieren: http://203.81.29.13:7635/bootloader.zip
wie nett, kaum habe ich auf eevblog gepostet schon kamm eine neue email. Die firmware wird nicht neu gemacht sondern überarbeitet, dabei wird die fehler liste die ich gepostet habe auch abgearbeitet. Nun ja, ich lasse mich überraschen. Das letzte mal wo die 1 monat lang die fehler beseitigen wollten (und davor ein monat lang angeblich mit anderen sachen beschäftigt waren) kamm eine firmware wo alle debug infos / prozeduren entfernt sind. Leider nicht etwas um die firmware zu beschleunigen (was eine gute idee wäre ... aber bitte erst die bugs) sondern um mögliche weitere hacks zu erschweren.
Typisch Fernost... Ich weiß schon warum ich bei so einem Verein seit Jahrzehnten nicht mehr arbeite ;)) Danke übrigens für den Link oben, hat geschlagene 15 Minuten gedauert um die 8MB runterzuladen. Wahrscheinlich sitzt da mal wieder einer auf der Leitung und kontrolliert, zensiert wenn nötig und zählt dann zu guter Letzt nochmal die Bits ;))) Gruss Peter
Also die selben Leute, die seit Monaten nicht richtig weiter kommen, werden in den nächsten zwei Monaten alle Probleme lösen?
Mischmasch schrieb: > Also die selben Leute, die seit Monaten nicht richtig weiter kommen, > werden in den nächsten zwei Monaten alle Probleme lösen? das weiss ich nicht ob es die selben leute sind. Aber auch wenn, es muss nix bedeuten, manchmal sind andere umstände dafür verantwortlich das man keine vernünftige arbeit abliefern kann. Ich mache mir sowieso keine sorgen, habe hier genug ältere firmware versionen die zwar die eine oder andere funktion noch nicht haben, dafür aber weniger/so gut wie keine bugs. Seit Samstag habe sogar den neuen Tekway MST: http://www.mikrocontroller.net/attachment/135049/MST1202B.jpg (die LA/MSO funktionen muss ich erst richtig testen bevor ich was dazu sage,) Drauf ist zwar nur eine frühe beta fw (2.07.1), aber die ist jetzt schon besser als die 2.06.3 auf den bench top modelen (bugs 1,2,3,8,9,10,17,18,24 und 25 nciht vorhanden, bug 6 sieht nochmal stück besser aus, 12 habe selber entfernt). Sollte es Hantek nciht hinkriegen mit den bugs werde ich bei mir backup von dem Tekway MST restoren (und factory cal ausführen). Eventuell stelle ich so ein backup (mit restore anleitung) online, auch die älteren firmwares wollte ich verfügbar machen, es gab schon jede menge nachfrage.
> Seit Samstag habe sogar den neuen Tekway MST: > > http://www.mikrocontroller.net/attachment/135049/MST1202B.jpg > (die LA/MSO funktionen muss ich erst richtig testen bevor ich > was dazu sage,) wie stehen die Chancen eines der bisherigen Geräte um den LA aufzurüsten? Auf den Boards sind ja schon ein paar Vorbereitungen dafür wenn ich das richtig in Erinnerung habe.
Angehängte Dateien:
-
top.jpg
140 KB -
bottom.jpg
160 KB
Gerd E. schrieb: >> Seit Samstag habe sogar den neuen Tekway MST: >> >> http://www.mikrocontroller.net/attachment/135049/MST1202B.jpg >> (die LA/MSO funktionen muss ich erst richtig testen bevor ich >> was dazu sage,) > > wie stehen die Chancen eines der bisherigen Geräte um den LA > aufzurüsten? Auf den Boards sind ja schon ein paar Vorbereitungen dafür > wenn ich das richtig in Erinnerung habe. für die hw0 und hw1005 besitzer keine chance da entweder nicht alle benötigte i/o herausgeführt (hw0) oder "wackelige" hardware (hw1005). für die hw1007 braucht man nur die LA PCB (die kann auch LAN machen, auf dem bild nicht bestückt) und die firmware natürlich. Ich könnte den schaltplan erstellen, sind zwar afaik 8 layer aber alles was ich brauche (JTAG port) ist herausgeführt. Es könnte aber günstiger sein so eine PCB von Tekway zu kaufen als selber machen (es sei den man hat ein kleines EP3C5 board/modul mit allen benötigten i/o schon da). Der rest ist nix wildes: VREF, 12bit DAC, DC/DC converter und opamp für offset und SRAM (IS61LPS51236A-200TQLI) für samples.
Thomas R. schrieb: > wie nett, kaum habe ich auf eevblog gepostet schon kamm eine neue email. > Die firmware wird nicht neu gemacht sondern überarbeitet, dabei wird > die fehler liste die ich gepostet habe auch abgearbeitet. Warum nur glaube ich, dass Hantek lügt, dass sich die Balken biegen? Da sitzt doch wieder irgendwo ein Manager, der nur seinen Arsch retten will, und gut aussehen möchte. > Nun ja, ich lasse mich überraschen. Sogar wenn die jetzt einen neuen Programmierer gefunden haben, wird der mehr als die Zeit brauchen um sich einzuarbeiten, die vorhandene Software zu finden, zu verstehen, wichtige Teile neu zu schreiben, das Ergebnis testen zu lassen(*), usw. (*) Testen lassen, nicht selber testen. Nur würde das bedeuten, dass Hantek in die Qualitätssicherung investieren müsste. Das machen die ums Verrecken nicht.
> Es könnte aber günstiger sein so eine PCB von Tekway zu kaufen als selber machen
Kann man die denn einzeln nachkaufen?
Thomas schrieb: >> Es könnte aber günstiger sein so eine PCB von Tekway zu kaufen als selber machen > Kann man die denn einzeln nachkaufen? Tekway sagt "grundsätzlich ja". Deren grosstes problem dabei ist die tatsache das man wissen muss was man macht, spricht firmware backup und restore. Ich habe zwar den beschrieben dass dies kein problem sein dürfte für die meisten benutzer (da wir sowieso schon backups/restore machen, und auch das tool von Peter Dreisiebner haben was datei kopieren erleichtert) allerdings möchten die erst mit eigenen ingenieuren nächste woche sprechen zu prüfen wie so ein vorgang aussieht. Erst dann werden die mir die preise für das LA module sagen.
Mooooment! Neue harte Ware? Da bin ich doch gleich dabei ,-) Gruß Old-Papa
Angehängte Dateien:
-
SCR-USB-Console-960.jpeg
160 KB
Seit kurzem bin ich nun auch unglücklicher Besitzer eines Hantek DSO5102B. Durch die Diskussionen hier und auf eevblog war ich ja vorgewarnt. Aber daß die aktuelle Software so ein Schrotthaufen ist, hätte ich nicht gedacht. Ich habe mir einfach nicht vorstellen können, daß sich ein Hersteller traut, so ein Gebastel frei zu geben. So, daß mußte raus. Aber das Gerät habe ich ja auch wegen des "hack value"s gekauft. Deshalb habe ich die Kernelsourcen aus allen verfügbaren Quellen installiert. Ich glaube, es müßte möglich sein, über die USB-Device-Schnittselle eine Netzwerk-Verbindung herzustellen. Herausgekommen ist statt dessen erst mal eine serielle Terminalschnittstelle über die USB-Host-Buchse (s. Anhang). Wenn man ein passendes Script über den Update-Mechanismus einspielt, könnte man darüber einen Shell-Zugang bekommen, ohne daß man die UART-Schnittstelle zugänglich machen muß. Also ohne garantiebeendenden Hardware-Eingriff (für mich zu spät :). Die USB-Terminal-Schnittstelle kann aber auch zusätzlich zur UART-S ganz nützlich sein, da letztere durch /dev/console belegt ist, und die shell-job-control dort nicht ohne Verrenkungen funktioniert (http://www.busybox.net/FAQ.html#job_control). Bei Interesse stelle ich das PL2303-Modul für den 2.6.13 Kernel gerne zur Verfügung. Ich kann auch Module für andere Adapter (z.B. ftdi) compilieren, aber leider nicht testen. Leider habe ich mit der Kernelsource auch noch (mindestens) ein Problem: "make menuconfig" hängt sich im Menü 'Device Drivers/USB support' auf. Wahrscheinlich weil Tekway/Hantek dort ihre eigenen Treiber reingemurkst haben. Oder gibt es jemanden, der den Fehler nicht hat, bzw. behoben hat? Die Konfiguration mit "make config" funktioniert, ist natürlich aber sehr mühsam. Und dann noch vielen Dank an Peter Dreisiebner für das dso-usb-tool. Und zwar für die Linux-Version. Hier ist meine dazu passende udev-Regel
1 | SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="049f", ATTRS{idProduct}=="505a", MODE="660", GROUP="dialout"
|
Wer's gebrauchen kann, kopiert diese Zeile in eine passende bestehende oder neue Datei in '/etc/udev/rules.d'. Statt 'dialout' kann man natürlich eine andere Gruppe nehmen (z.B. 'users').
Da das andere Posting schon lang genug war jetzt extra: Großes Danke an Thomas R. Danke aber auch an die vielen anderen, die hier und anderswo zum Mehrwert der Geräte bei(ge)tragen (haben). Besonderer Dank, Thomas, daß Du Dich um die Fehler in der aktuellen Software kümmerst (Liste). 2 Fehler habe ich auf der Liste aber noch nicht gefunden: Alternate Trigger. Hier scheint überhaupt nichts richtig zu funktionieren. Insbesondere kann man den Level von Ch 2 nicht einstellen. Da 'Alternate Trigger' aber weder im Handbuch noch im Hilfesystem vorkommt, könnte man natürlich sagen, das daß ja garnicht zum Funktionieren gedacht ist. Vielleicht gehts mit der bestehenden Hardware ja auch gar nicht. Aber dann sollte Hantek die Funktion doch einfach wieder raus nehmen. Oder braucht jemand (bei einem DSO) alternate Trigger? Zeitversatz der Kanäle. Wenn man auf beide Kanäle das gleiche Signal gibt, werden die Kurven auf dem Bildschirm um ca. 1ns versetzt angezeigt (Ch2 nach Ch1). Bei 4 ns/div (max. beim ungehackten 5102B) deutlich zu sehen. Der Fehler wurde auch auf eevblog diskutiert.
Hallo Leo, Leo C. schrieb: > Alternate Trigger. > Hier scheint überhaupt nichts richtig zu funktionieren. Insbesondere > kann man den Level von Ch 2 nicht einstellen. so blind war ich auch schon einmal :-) Beitrag "Re: TEKWAY DST1xx2B Oszilloskop" Peter
Leo C. schrieb: > Ich glaube, es müßte möglich sein, über die USB-Device-Schnittselle eine > Netzwerk-Verbindung herzustellen. Das hat schon mal jemand gemacht: http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg83370/?topicseen#msg83370
Peter Dreisiebner schrieb: > so blind war ich auch schon einmal :-) > Beitrag "Re: TEKWAY DST1xx2B Oszilloskop" Oh je, was ich da alles ausprobiert habe... Aber in dem Modus sind noch mehr Fehler drin. Mit der vorinstallierten Software (120224.0) ist die Kiste öfters abgestürtzt, wenn ich am Trigger-Level gedreht habe. Zur Zt. habe ich eine ältere Version installiert. Mischmasch schrieb: >> über die USB-Device-Schnittselle eine Netzwerk-Verbindung herzustellen. > > Das hat schon mal jemand gemacht: > > http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg83370/?topicseen#msg83370 Der macht das über die Host-Schnittstelle mit einem Adapter. Was ich meine, ist aber ein Posting weiter unten beschrieben. Zur Zeit versuche ich den Kernel zu finden, den Tekway als Basis genommen hat. 2.6.13 ist es nicht. Der heißt auch "Woozy Numbat". Im Makefile steht aber "Affluent Albatross", und das wäre 2.6.14. Der ist's aber auch nicht, sondern irgendwas dazwischen. Die QQ2440-DVD tröpfelt gerade herein. Nur noch knapp 11 Stunden...
> Zur Zeit versuche ich den Kernel zu finden, den Tekway als Basis > genommen hat. 2.6.13 ist es nicht. natürlich ist es 2.6.13 Download links siehe (die Fußnoten) http://www.mikrocontroller.net/articles/Hantek_Protokoll
bong schrieb: > natürlich ist es 2.6.13 Eben nicht. Jedenfalls nicht der "offizielle" 2.6.13, der am 29.8.2005 released wurde[1]. Die DSO- bzw. QQ2440-Entwickler haben irgend einen Stand zwischen dem 29.8. [2] und dem 13.9.2005 [3] gesaugt. > Download links siehe (die Fußnoten) > http://www.mikrocontroller.net/articles/Hantek_Protokoll Danke, aber davon rede ich ja. [1]http://www.kernel.org/pub/linux/kernel/v2.6/ [2]http://www.mail-archive.com/git-commits-head@vger.kernel.org/msg00684.html [3]http://err.no/cgi-bin/gitweb.cgi?p=linux-2.6;a=commitdiff;h=refs/tags/v2.6.14-rc1
Leo C. schrieb: > bong schrieb: >> natürlich ist es 2.6.13 > > Eben nicht. Jedenfalls nicht der "offizielle" 2.6.13, der am 29.8.2005 > released wurde[1]. > > Die DSO- bzw. QQ2440-Entwickler haben irgend einen Stand zwischen dem > 29.8. [2] und dem 13.9.2005 [3] gesaugt. > dürfte denoch halb so schlim sein. Übrigens, hier findest Du ein paar interessante downloads: http://203.81.29.13:7635/ z.b. http://203.81.29.13:7635/dso_bench_120620.zip
Angehängte Dateien:
-
skew.png
10 KB
Leo C. schrieb: > Besonderer Dank, Thomas, daß Du Dich um die Fehler in der aktuellen > Software kümmerst (Liste). > > Zeitversatz der Kanäle. > Wenn man auf beide Kanäle das gleiche Signal gibt, werden die Kurven auf > dem Bildschirm um ca. 1ns versetzt angezeigt (Ch2 nach Ch1). Bei 4 > ns/div (max. beim ungehackten 5102B) deutlich zu sehen. Der Fehler wurde > auch auf eevblog diskutiert. dieser fehler ist eigentlich auch (fast) keiner, die 500ps sind auch als "trigger abweichung" in dem datenblatt angegeben. Ist natürlich unschön dass statt den 500ps je nach model etwas mehr sind. Ich habe hier gerade den Tekway MST, da sind es 800ps (nicht wundern über die 500ps/DIV timebase, ich patche die firmware je nach bedürfnis). Man sieht auf dem bild noch etwas, der trigger ist verschoben um 1250ps, das ist auch model/factory cal und frequenz abhängig. Bei dem MST passt es zimlich genau beim 50Mhz zu messenden signal (was auch sinn macht für ein 100MHz gerät). Nochmal zu den zeitversatz zwischen den kanälen, ich habe testweise eine delay line von Murata (LDH65500PAAA-400) am CH1 eingang eingebaut. http://www.digchip.com/datasheets/parts/datasheet/314/LDH65500PAAA-400.php Leider habe keine 800ps hier (nur 500 und 1000ps), damit komme ich auf 300ps zeitversatz. Das ist natürlich keine dauerlösung da die delay lines nur 100mA vertragen. Zwischen dem R01_30 und dem AD8370 ist eventuell auch keine gute idee wegen den self-cal, habe aber nicht getestet. Ich habe auch am trigger mux getestet, das ist dem DSO völlig egal, es ist also kein trigger zeitversatz sondern FPGA design bedingt. Damit muss also die delay line irgendwo zwischen eingang und dem LMH6552 ausgang (spätestens, damit der trigger nocht verschoben ist zum signal). Eigentlich wäre besser wenn das FPGA design so angepasst wäre das der zeitversatz zwischen den kanälen ohne delay lines auch passt. EDIT: nur jetzt blos keine sammelbestellung für delay lines, diese methode ist eigentlich nicht die beste und ungetestet.
Hmpf, das was ich hier so lese, hört sich ja alles sehr sehr positiv an. Bekome ja schon fast lust so ein Teil mir zuzulegen, wenn da nicht meine Probleme mit den anderen Hantek Produckte währen. Ich selbst habe von Hantek einen LA5034 34 Kanal Logicana mit 500MSa/s (Dieser kann leider nur schöne Linien und Zeitdiagramme zeichnen, die dekodierung von I2c SPI oder ähnlich geht mal garnicht, also nutzlos). Ein tolles DDS-3005 USB Funktionsgenerator mit Zähler und co (Läuft kein Stück, das beste was man bei ihm rausbekommen hat, ist ein Sinus mit einem Selbstgeschriebenen Programm, die Soft von HAntek geht kein Stück) Ein tot schickes DSO-5200A (USB Oszi). Man kann mit messen, und dan ist schon gut. Den unten beschriebenen Zeitfehler, hab ich hier noch nicht getestet. Und das beste natürlich zum Schluss, ein DSO 1060 Handhald Scope. Mit dem war ich auch sehr sehr zufrieden, bis eines tages der Tag kam, an dem ich nen fießen Firmwarebug gefunden habe, mich würde es nicht wundern, wenn der noch immer vorhanden ist und das auch in anderen Scopes von denen. Wenn man mal sehr langsamme Signale beobachten will, so im bereich von 1/10 Herz also alle 10 Sekunden einen Impuls oder so, stimmt die Zeitbasis vorne und hinten nicht. Je nach dem wo man ist, sind Zeitfehler von 33% und mehr möglich. Firmware oder Softwareupdates kommen für die oben genannten Produkte schon seit einem jahr nicht mehr raus.
Jdelphi schrieb: > Ich selbst habe von Hantek einen LA5034 34 Kanal Logicana mit 500MSa/s > (Dieser kann leider nur schöne Linien und Zeitdiagramme zeichnen, die > dekodierung von I2c SPI oder ähnlich geht mal garnicht, also nutzlos). Ebenfalls Hmpf (was immer das heißen mag ;)), das Teil ist auch kein Messgerät sondern ein Spielzeug. Wenn Du was Gescheites willst, musst Du zumindest eines von denen hier kaufen: http://www.tech-tools.com/dv_main.htm Damit arbeite ich seit einiger Zeit professionell... Wenn Du nichts mit Highspeed Applicationen zu tun hast (was in der Regel nicht der Fall sein wird..) reicht die 100MHz Ausführung. Ohne hier die Werbetrommel zu rühren (davon habe ich nichts): Die Software ist erste Sahne und die Hardware sowieso. Die Software gibt oben zum Ausprobieren und anschauen nebst ausführlicher Beschreibung kostenlos zum Download ;) Gruss Peter
Peter Krengel schrieb: > das Teil ist auch kein Messgerät sondern ein Spielzeug. Was für technische Gründe hast du für diese Behauptung? Das ist keine rhetorische Frage oder so, ich bin wirklich an den Kritikpunkten interessiert. > Wenn Du was Gescheites willst, musst Du zumindest eines von denen hier > kaufen: > > http://www.tech-tools.com/dv_main.htm ... > Die Software ist erste Sahne und die Hardware sowieso. Und welche Punkte genau bringen dich zu dieser Aussage, im Vergleich zu deinem negativen Punkten beim DS05200A? Die Software sieht ja nett aus und so, aber ich persönlich finde z.B. die USBee Suite vom User Interface her intuitiver und netter.
Angehängte Dateien:
-
DSO1060.png
42 KB
Anbei das Bilt mit dem Zeitfehler. Deutlich sieht man es vor und nach dem Triggern. der Teil nach dem Triger stimmt :-) vorher ist es für die Tonne. Als LA hab ich jetzt den Open Workbench Logic Sniffer, bekommt man bei http://www.watterott.com/ für nur runde 45 Teuro, er unterstütz auch so ziemlich alles was ich kenne, bis auf NIM und ECL signale. Passend dazu gibt es noch den Bus Pirate, mit dem kann man ganz gut schalten und walten. Ebenfals hat er einen kleinen LA eingebaut. Der is so das schweizer Taschenmesser was Digitaltechnik angeht. Aber gut das gehört ja eigentlich alles nicht hier her.
Jdelphi schrieb: > Hmpf > ... > Probleme mit den anderen Hantek Produckte währen. > Hantek ist auch eine seltsame firma. Die meisten sachen die die verkaufen sind irgendwie dazu gekauft (abgesehen von den ersten USB DSOs und ich glaube sogar einem LA model). Das mag ja auch "ok" für das management sein, bringt aber ein paar nachteile mit sich da: - irgendwann wird ein mitarbeiter der sich mal so ein dazu gekauftes ding angeguckt hat auch ein fahrad kaufen wollen (und job wechseln) - support erschwert durch zu viele platformen - bug fixes verlangsammt durch zu viele platformen (jedesmal undenken) - bei fremdgeräten ist oft weiterentwicklung = neu entwicklung > Ich selbst habe von Hantek einen LA5034 34 Kanal Logicana mit 500MSa/s > (Dieser kann leider nur schöne Linien und Zeitdiagramme zeichnen, die > dekodierung von I2c SPI oder ähnlich geht mal garnicht, also nutzlos). ja, der war gar nicht soo schlecht (eigentlich direktes konkurent seit 5 jahren für LogicPort) - bis auf die software. Leider ist auch gute hardware nix wert wenn die software nix taugt. Ich sag "war" weil diese platform (wie auch LogicPort) mittlerweile veraltet sind. Mittlerweile bekommt man auch LAs die schnell samplen UND auch etwas/deutlich mehr speicher haben. Wegen der protokol dekodierung, sicher das es kein benutzer fehler ist? Mir hat mal jemand gesagt das die etwas "scheisse implementiert aber funktionsfähig ist" > > Ein tolles DDS-3005 > > Ein tot schickes DSO-5200A > > ein DSO 1060 Handhald Scope ja genau .. eigentlich (rein hardwareseitig) sind diese geräte ok, die probleme sind zur 99% bei der firmware/software und zur 99,5% bei dem support. Das war einer der grunde warum direkt nach dem rauskamm das Hantek die Tekway DSOs produzieren/verkaufen wird ich sofort Tekway versucht habe zu warnen. Leider hatte ich keine alternative: Tekway wollte expandieren und Hantek hat nach einem Benchtop DSO gesucht. > ein DSO 1060 Handhald Scope noch vor einem jahr hat Hantek für diese (und 1200/8060) geworben, mittlerweile verkaufen die nur noch lagerreste. Die nachfolger modele sind alle auf den Benchtop DSO basierend (DSO1xxxB) > Ein tot schickes DSO-5200A auch bei den USB DSOs könnte Hantek glänzen (ein DSO3704A mit 700MHz bw 5GS/s und 4ch ist schon ein gutes stück hardware für ein USB scope) leider wieder ist die software nicht gut genug (bis jetzt). Allgemein gesagt baut Hantek keine schnlecht dinger (wobei manchmal hauen die mich um, beispiel 20 cent netzteil beim DSO1060/8060/1200 UND DSO1062B/1102B/1202B : geeignet zum laden aber eine 20% fehlerquelle für DMM - gut, man muss nicht laden und messen, schön ist es aber nicht). Tekway DSOs waren viel besser, jetzt passen die "perfekt" zum Hantek, leider im negativen sinne. Ich denke die meisten benutzer würde auf Bode funktion und (nicht dokumentierte) Hantek eigenes .hws format mit export/import für waveforms verzichten aber dafür ein/zwei weniger dumme bugs haben (wie z.b. artefakte beim long mem, <400ns/DIV und dual window).
Peter schrieb: > Was für technische Gründe hast du für diese Behauptung? Das ist keine > rhetorische Frage oder so, ich bin wirklich an den Kritikpunkten > interessiert. Die Frage beantwortet sich von allein, wenn Du mit beiden Geräten arbeitest. Während Du mit dem Scope wie Du selbst sagst, nicht einmal simple Protokolle decodieren kannst, geschweige denn exakte Timing Analysen durchzuführen, ist dies mit dem DigiView problemlos und äußerst exakt möglich. Zudem kannst Du mit dem Digiview eigene Analysetools in die Software einbinden, sprich eigene Protokolle und/oder, es gibt da eine Art Library, die anderer mit einbinden. Dafür gibt es ein extra Tool, das man auch kostenlos runterladen kann. ----------------- Mit dem Scope schaust Du nette Rechtecke an, während Du mit dem Analysetool dann das machst, wofür es entwickelt wurde: Ernsthafte Analyse von Codes/Protokollen und Timings. Was ich meine, siehst Du z.B. u.a. am Triggerversatz, wenn Du mehrere Kanäle darstellen musst (und das geht mit DigiView....nein ich bekomme keine Verkaufsprovision!!... auf 16 Kanälen gleichzeitig und mit voller Speed.) der mit dem Scope eine Analyse unmöglich macht. Zur Software: Ich glaube kaum dass Du die Funktionen der Software in ein, zwei Stunden erfasst hast (oder ich bin der Doofe) Allein das Handbuch durchzuarbeiten dauert Tage... Ein Scope mit D-Funktion ist wie ein Multimeter, man kann alles mit sehen, aber nichts genaues weiss man nicht... Prof. Geräte haben halt ihren Preis... Mit einem 10,- Radio kann ich auch gucken, welche Sender da sind, um deren Signal aber zu analysieren, brauche ich schon etwas besseres ;) Ob man die Funktionen echter Analysetools braucht und nutzt, muss jeder für sich selbst entscheiden. Gruss Peter
Kein komentar zu dem Bild oben, mit dem Timingproblem vor und nach dem Triger. Schade. Könnte das villeicht mal jemand mit nem anderen Scope testen. Naja, passend zu dem Theard, hab ich nochmal das DDS-3005 ausgekramt. Nachdem ich wieder mittels Delphi ein 1kHz signal rausholen konnte, ging es nicht mehr. Beim neu anschließen kam immer, USB Gerät nicht erkannt.
Hi, Peter schrieb: > Die Software sieht ja nett aus und so, aber ich persönlich finde z.B. > die USBee Suite vom User Interface her intuitiver und netter. Wobei die USB Suite halt auch einfach fast keine Funktionen bietet. Das alleine macht es es natürlich schon deutlich einfacher. Davoin abgesehen ist der USBee einfach nur ein kleines Spielzeug das man gut nehmen kann wenn man einfache RS232/SPI/ oder I2C mit langsamer Geschwindigkeit länger mitschneiden will. Aber ansonsten... Wenn man dann die Originalhardware betrachtet gnadenlos überteuert! (Über den RX kann ich nichts sagen, aber fast 2000 Euro für ein 16Kanal Gerät...) ICh habe mit dem Dingen experimentiert, nur Probleme gehabt. Mehr als 16Mhz SamplingFrequenz habe ich so gut wie nie erreicht. Und überhaupt: mit Maximalgeschwindigkeit zuverlässig Samplen wie man es für ein Mitschneiden von LowSpeed USB braucht hat im gesamten Bekanntenkreis niemand dauerhaft hinbekommen, mal ein paar Sekunden nach X Versuchen... Es ist für so einige Sachen ok wenn man die NAchbauhardware benutzt. Materialwert 5 Euro, mehr ist im Original ja auch nicht drin.! Wobei die nutzung mit der Saleae Software da Sinnvoller ist, die lief damals gefühlt stabiler (Keine wie es jetzt aussieht) und das was angegeben war hat auch funktioniert. Peter Krengel schrieb: > Prof. Geräte haben halt ihren Preis... > > Mit einem 10,- Radio kann ich auch gucken, welche Sender da sind, > um deren Signal aber zu analysieren, brauche ich schon etwas besseres ;) Das stimmt definitiv, wobei das ja nicht nur Weiß und Schwarz gibt. Um mal bei den Radiobeispielen zu bleiben: Für viele Messungen die man machen will braucht man aber da auch nicht sofrt den R&S ESAI-D oder (wie er hier bei mir steht) den HP85940A-UFPR wie die BNATZA es mal eine ZEitlang in den Wagen hatte. Es gab beispielsweise ja lange ZEit auch "Messempfänger" derDEUTLICH unter 5000DM Klasse, sowohl für Radio als auch TV, die einiges an Analysefunktionen boten. Gedacht waren die für R&F TEchniker die auch Antennenbau machten in einer Zeit als die Signale noch lange nicht so stark waren das ein feuchter Finger an der Antennenbuchse reichte sondern eine Vernüftige Ausrichtung und einpegelung der gesamten, teilweise aus mehreren zusammengechalteten Antennen bestehenden HAusanlage in vielen Regionen unerlässlich war. (Wobei wir bezogen auf die terrestrische Versorgung in ländlichen Gebieten wieder in diese Zeit zurückgefallen sind. Glücklicherweise interessiert das dank Sat-Analge kaum noch ein Schwein. Nur wenn man mal den TV im Garten -z.B. weil man da mit Freunden beim Grillen und gemütlichen Biertrinken in großer Runde das mheutige EM Spiel sehen möchte, dann stört es doch. "Früher" haben wir den TV einfach rausgetragen, in eine schattige Ecke gestellt und mit einem Stück draht dann den Sender empfangen. Heute muss man erst einmal Zig meter Koaxkabel durchs halbe Haus ziehen...) Worauf ich raus wollte: Auch solche einfachen Messempfänger boten schon viele Möglichkeiten und man könnte einiges damit machen. Manche hatten sogar einen internen Panoramabildschirm! Aber halt nicht alles was dann der für den Laboreinsatz gedachte "echte" Messempfänger der 10 00 - 50 000 DM klasse konnte. Im Bezug auf die LOGIK Analyzer würde ich als günstige aber wirklich brauchbare Lösung mal die ZEroplus LAP-C in den kleineren Versionen ins Spiel bringen... Der Lap C 16032 als kleinstes Modell mit 16 Kanälen kostet etwa 100 Euro und ist durch ein einfaches Software-Update auf das Modell 16128 erweiterbar, wo der LA dann pro Kanal 128kb Sample Speicher hat (gleich 2MB gesamt) und bis zu 200Mhz Sampletakt. Insgesamt bekommt man dazu fast 40 ProtokollanalyzerPlugins, von denen eine kleine ZAhl (glaube 7 oder 8, müsste nachsehen) grundsätzlich frei sind und man sich dann 30 weitere aus einem Gesamtpool von etwa 70 möglichen zusätzlich kostenlos auswählen kann. Die darstellung und Protokollanalyse funktioniert ganz passabel, die Software hat von der Bedienung bei den tieferen Funktionen so auch mal ihre Eigeneheiten, aber nicht gravierend. Natürlich sind bei einem solchen LowCost Gerät dann bestimmte Funktionen nicht so Ausgeprägt wie bei den teureren, insbesondere erweiterte Analysefunktionen bzogen auf das Physikalische Signal, untypische oder USerdefinierbare Schaltschwellen oder aber auch sehr komplexe Triggerfunktion hat er nicht... Aber alles was ich bisher damit machen wollte hat bisher problemlos geklappt. Und wenn man das dann mit dem etwas gleichteurem "kleinstem" USBee oder dem Saleae vergleicht sind das einfach welten! Aber zum Thema LA gibt es genug andere Threads, Insbesondere zu den Zeroplus (gerade vor zwei Tagen wieder aktuelle gewesen) dem Logiport und den beiden Cypress 8051 basierenden SAleae sowie Usbee. Das einzige was ich dazu abschließend noch sagen möchte ist, das ich zwar auch Jahrelang mit der Technik des "BitZählen" ganz gut zurecht gekommen bin, heute aber für mich das Fehlen ein evtl. von mir später häufiger benutzten Protokollanalyse-Plugins und erst recht das nichtfunktionieren der analyse gängiger Protokolle ein definitives KO Kriterium sind. Natürlich sollte ein LA weit mehr sein als nur ein Werkzeug zum Mitlesen der Datenströme, aber wenn man ehrlich ist so ist das in der Heutigen ZEit doch wohl bei jedem der absolute Löwenanteil der Anwendung... Und die schönste Analyse des Signalverhaltens und die tollsten einstellbaren Spannungspegel usw. nützen mir nicht viel wenn ich die vielleicht einml alle 6 Monate brauche, ich aber mindestens jede Woche mal mitlesen Muss was so zwischen meinen Baugruppen hin und her läuft. Da schaut man einmal kurz ob es physikalisch passt, dnach interessiert nur noch der dekodierte Inhalt! Gruß Carsten
Peter Krengel schrieb: > Die Frage beantwortet sich von allein, wenn > Du mit beiden Geräten arbeitest. > > Während Du mit dem Scope wie Du selbst sagst, > nicht einmal simple Protokolle decodieren kannst, > geschweige denn exakte Timing Analysen durchzuführen, > ist dies mit dem DigiView problemlos und äußerst > exakt möglich. Hm, ich glaube da gab es wohl ein Missverständnis. Ich hatte den Eindruck mit "Spielzeug" hättest du den Hantek LA5034 Logic-Analyzer gemeint (nicht das TEKWAY DST1xx2B Scope). Mich hatten eher die Kritikpunkte/Nachteile vom LA5034 gegenüber dem DigiView interessiert.
Hallo Carsten, Hallo Thomas! Carsten Sch. schrieb: > Der Lap C 16032 als kleinstes Modell mit 16 Kanälen kostet etwa 100 Euro Wo find ich den um 100 EUR? Thomas R. schrieb: > für die hw1007 braucht man nur die LA PCB Wie funktionirt den das? Ich habe ein Voltcraft, würde ich mir dann mit der LA PCB den Lap C 16032 sparen? Wenn ich die PCB einbaue brauch ich ja eine software. Robert
Robert Walli schrieb: > Thomas R. schrieb: >> für die hw1007 braucht man nur die LA PCB > > Wie funktionirt den das? Ich habe ein Voltcraft, würde ich mir dann mit > der LA PCB den Lap C 16032 sparen? > Wenn ich die PCB einbaue brauch ich ja eine software. > > im prinzip braucht man so eine LA PCB und die software (firmware). Eigene DSO PCB muss man dann ausbauen, eine i/o header (1.27mm pitch) löten, die LA PCB draufstecken und dann die DSO PCB wieder einbauen. Dann die eigene firmware über mein backup tools sichern, falls man zeit sparren möchte (oder keine ausstattung hat) die werks kalibrierung auf USB stick kopieren und schon kann man anfangen mit MST firmware flashen (UART/USB oder JTAG). Nach dem flashen DSO rebooten, USB stick wieder rein und die werkkalibrierung rüber kopieren (damit die MST firmware auch sauber mit deiner DSO PCB wieder läuft). Das wars dann schon ... fast :) Man muss dummerweise loch in der gehäuse machen um die LA buchse einzubauen - das ist etwas was ich versuche zu ersparren. Eventuell könnte Tekway die ganzen front teile mitliefern (was kann so stück plastik mit aufklebern kosten, 5EUR?). Möglicherweise wird auch Tekway sagen "nein es muss händler xyz oder jemand der mit uns ein entsprechendes vertrag unterschrieben hat einbauen damit die garantie für DSO PCB waeiterhin besteht", wie du siehst sind da einige themen die ich mit Tekway diskutieren muss. Für mich persönlich wäre es egal, ich kann selber ein loch machen und LA einbauen - ich brauche auch keine garantie für DSO. Das gilt aber für mich, die meisten werden garantiert die beste lösung wollen: - günstig - mit garantie - nix selber machen - keine wartezeit :)
Thomas R. schrieb: > anfangen mit MST firmware flashen Verstehe, die firmware wird mit der PCB mitverkauft. Klingt ja gut! d.h ich brauche den PC nicht mehr. Und die MST firmware bringt ungefähr das selbe wie das "Lap C 16032"? Mit allen gängigen Protokollen? Weiss man ganz ungefähr in welchem Preisbereich sich das bewegen wird? Robert
Thomas R. schrieb: >> Jedenfalls nicht der "offizielle" 2.6.13, der am 29.8.2005 > > dürfte denoch halb so schlim sein. Vielleicht wäre es dann einfacher, das kaputte menuconfig zu reparieren. Inzwischen editiere ich .config direkt, mit anschließendem 'make oldconfig'. > Übrigens, hier findest Du ein paar interessante downloads: > z.b. > http://203.81.29.13:7635/dso_bench_120620.zip Danke für den Hinweis. Von diesem Server hatte ich schon einiges herunter geladen, aber diese Datei war ganz neu und wäre mir sicherlich entgangen. Es gibt bei Hantek also doch jemanden, der sich bemüht, den Sourcecode vollständig zusammen zu bekommen und zu veröffentlichen.
Obwohl das Interesse am Shell-Zugang über USB-Seriell-Adapter am Host-USB auf der Frontplatte (Beitrag "Re: TEKWAY DST1xx2B Oszilloskop") nicht gerade "überwältigend" (Euphemismus ;) war, habe ich dazu mal ein Paket zusammen gestellt, das per Firmware-Update installiert werden kann. Achtung : Das ist das erste Mal, das ich ein solches Paket gebaut habe. Obwohl es bei mir wie gewünscht funktioniert, könnte es noch Fehler enthalten und im schlimmsten Fall dazu führen, daß das DSO nicht mehr bootet. Deshalb kann ich das Paket vorläufig nur Leuten empfehlen, die genau wissen was sie tun, und ggf. in der Lage sind, ihr DSO per Backup wiederherzustellen. Im Paket sind nur Module für FTDI- und PL2303-Adapter. Mit anderen Adaptern kann es also (noch) nicht funktionieren. Außerdem habe ich nur mit PL2303-Adaptern getestet, weil ich keinen FTDI hier habe. Vielleicht mag ja mal jemand drüber schauen, der sich auskennt. (Thomas?) Über Kommentare würde ich mich freuen.
Hallo Leo? Leo C. schrieb: > Obwohl das Interesse am Shell-Zugang über USB-Seriell-Adapter am > Host-USB auf der Frontplatte > (Beitrag "Re: TEKWAY DST1xx2B Oszilloskop") nicht > gerade "überwältigend" (Euphemismus ;) war, habe ich dazu mal ein Paket > zusammen gestellt, das per Firmware-Update installiert werden kann. > Das Interesse ist schon da nur ich hab's nicht ganz kapiert. Brauch ich da einen PL2303-Adapter für das Oszi und einen für den Computer verbunden mit einen Null-Modem-kabel? Robert
Robert Walli schrieb: > Brauch ich da einen PL2303-Adapter für das Oszi und einen für den > Computer verbunden mit einen Null-Modem-kabel? Für's Oszi einen PL2303-Adapter. FTDI geht wahrscheinlich auch, und für andere Adapter müßte man noch das Kernelmodul compilieren. Für die andere Seite brauchst Du ein Terminal mit serieller Schnittstelle. Wenn das ein PC sein soll und dieser keine (freie) serielle Schnittstelle hat, brauchst Du noch einen (beliebigen) USB-Seriell-Adapter und ein passendes Kreuz-/Nullmodem-Kabel bzw. -Adapter. Kurze Antwort: ja.
Hallo Leo, ich habe dein Paket eingespielt und mit einem PL2303 getestet, funktioniert einwandfrei. Einen FTDI-Adapter habe ich auch hier, nur passen die Pegel nicht zusammen, das kann ich im Moment nicht testen. Ich verstehe das "install.sh"-Skript nicht, kenne mich mit Linux und Shell-Skripten aber auch nicht aus. Wo änderst du die rcS-Datei, oder machst du das gar nicht. Der BEGIN/END-Block verwirrt mich, und die letzte Zeile ist auskommentiert, oder? Peter Edit: Die rcS-Datei wird verändert, nur das wie habe ich nicht kapiert.
Hallo Peter, da ist nichts auskommentiert. Das ist ja kein GW-Basic oder so. ;-) Die Änderung von rcS macht ein awk-Script. Das Script wird zwischen den beiden ' auf der Befehlszeile an awk übergeben. Es kopiert zeilenweise von rcS nach rcS.new. Dabei werden Zeilen, die von einer eventuellen früheren Installation stammen, heraus gefiltert, und an einer (imho) passenden Stelle einige Zeilen (neu) eingefügt. Die printline-Funktion brauche ich, um aufeinander folgende Leerzeilen zu filtern. Sonst würden bei mehrfacher Ausführung des Scripts immer mehr Leerzeilen in rcS kopiert. Wenn das awk-Script erfolgreich beendet wurde, und die Zugriffsrechte von rcS.new geändert werden konnten, wird rcS.new nach rcS umbenannt, und damit das alte Script gelöscht. Peter Dreisiebner schrieb: ... > Der BEGIN/END-Block verwirrt mich, und die > letzte Zeile ist auskommentiert, oder? $man awk Danke fürs Testen.
Leo C. schrieb: > > Im Paket sind nur Module für FTDI- und PL2303-Adapter. Mit anderen > Adaptern kann es also (noch) nicht funktionieren. Außerdem habe ich nur > mit PL2303-Adaptern getestet, weil ich keinen FTDI hier habe. > > Ich kann auch Module für andere Adapter (z.B. ftdi) > compilieren, aber leider nicht testen. kannst du bitte auch für CP210x compilieren?
Hallo, übrigens, eine Toolchain für das Handheld-DSO und Windows habe ich hier gefunden: https://sourcery.mentor.com/sgpp/portal/release845 Ich musste nur folgende Dateien im selben Verzeichnis kopieren: ..\ARM-2009q1\arm-none-linux-gnueabi\libc\armv4t\lib\libgcc_s.so.1 nach libgcc_s.so ..\ARM-2009q1\arm-none-linux-gnueabi\libc\armv4t\lib\libc-2.8.so nach libc.so.6 Kompiliert habe ich mit folgenden Parametern: arm-none-linux-gnueabi-gcc.exe -msoft-float -mcpu=arm920t -mtune=arm920t -march=armv4t -o hello hello.c 'Hello World', Math-Test, Framebufferzugriff und Watchdog-Einstellung auslesen hat funktioniert. Für das Bench-DSO habe ich leider nichts einfaches für Windows gefunden bzw. habe ich mit meinen Versuchen nichts zusammengebracht. Peter
Hallo Leo, Leo C. schrieb: > Die Änderung von rcS macht ein awk-Script. danke, Sachen gibt es - kommt mir so vor wie 'warum einfach wenn es auch kompliziert geht' ;-) > Wenn das awk-Script erfolgreich beendet wurde, und die > Zugriffsrechte von rcS.new geändert werden konnten, wird rcS.new nach > rcS umbenannt, und damit das alte Script gelöscht. Vielleicht solltest du die original rcS-Datei nicht löschen, sondern nur umbenennen und aufheben. Könnte bei einem Fehler hilfreich sein zum wiederherstellen oder vergleichen. Peter
Noch eine kleine Bemerkung zum Loch in der Frontplatte fuer die LA-Buchse: bei meinem Voltcraft ist das schon drin, nur mit einem Aufkleber zugepappt, der natürlich an der Stelle auch nicht richtig hält und sich deswegen immer ablöst. Gruss Micha
Peter Dreisiebner schrieb: > danke, Sachen gibt es - kommt mir so vor wie 'warum einfach wenn es auch > kompliziert geht' ;-) Und ich dachte, ich hätte es einfach gemacht. Ok, statt awk hätte ich auch sed verwenden können, aber das liegt mir nicht. Bitte mach einen Vorschlag, wie es noch einfacher geht, und ich baue das Installationsscript gerne um. > Vielleicht solltest du die original rcS-Datei nicht löschen, sondern nur > umbenennen und aufheben. Könnte man machen. Allerdings gibts schon eine Backup-Datei (rcS~), die in der Regel mit aktueller rcS identisch ist, weil sie vom Hersteller-Update-Script gleich mit installiert wird. > Könnte bei einem Fehler hilfreich sein zum > wiederherstellen oder vergleichen. Bei einem Fehler ist zum Vergleichen aber möglicherweise nichts da, weil das root Dateisystem nicht mehr gemountet werden kann, und man dann nicht mal mehr über die UART-Schnittstelle rein kommt. Gut, man könnte über JTAG oder VIVI vor dem Restore die kaputte root-Partition sichern und danach analysieren...
Micha schrieb: > Noch eine kleine Bemerkung zum Loch in der Frontplatte fuer die > LA-Buchse: > > bei meinem Voltcraft ist das schon drin, nur mit einem Aufkleber > zugepappt, der natürlich an der Stelle auch nicht richtig hält und sich > deswegen immer ablöst. Bei meinem Hantek löste sich die Folie auch immer ab, weil sie etwas zu lang ist, und deshalb am rechten Rand der Vertiefung anstieß und etwas unter Spannung stand. Ich habe sie nach ein paar Tagen von der Mitte her so angedrückt, daß sie rechts über den Rand hinaus steht. Bisher hält sie so, und es fällt kaum auf. Die Alternative wäre, die Folie um 1-2 mm zu kürzen.
Nein, die Länge stimmt bei mir. Sie hält nicht, weil darunter das große Loch fuer die LA-Buchse ist und wahrscheinlich für die Steifheit der Folie die Klebefläche zu klein ist Gruss Micha
rs232 schrieb: > kannst du bitte auch für CP210x compilieren? cp210x gibts wohl erst bei späteren Kernels. Würde es das cp2101-Modul auch tun?
1 | Say Y here if you want to use a CP2101/CP2102 based USB to RS232 |
2 | module will be called cp2101. |
Neues Paket, auf besonderen Wunsch einer einzlnen Schnittstelle. ;-) Gegenüber der letzten Version ist nur das Modul cp2101.ko hinzu gekommen. Wer keinen CP2101 Adapter hat, braucht es also nicht. Das Modul wird geladen, aber ob es funktioniert, kann ich mangels passender Hardware nicht testen.
Thomas R. schrieb: > Robert Walli schrieb: > >> Thomas R. schrieb: >>> für die hw1007 braucht man nur die LA PCB >> >> Wie funktionirt den das? Ich habe ein Voltcraft, würde ich mir dann mit >> der LA PCB den Lap C 16032 sparen? >> Wenn ich die PCB einbaue brauch ich ja eine software. >> > im prinzip braucht man so eine LA PCB und die software (firmware). > Eigene DSO PCB muss man dann ausbauen, eine i/o header (1.27mm pitch) > löten, die LA PCB draufstecken und dann die DSO PCB wieder einbauen. Hallo Thomas, hast Du zur LA-Erweiterung schon neue Infos? Danke, Thomas
Thomas Sch. schrieb: > > Hallo Thomas, > > hast Du zur LA-Erweiterung schon neue Infos? > > Danke, Thomas ja, leider (ich schreibe morgen warum das).
Thomas R. schrieb: > ja, leider Lass mich mal raten: Der LA-Zusatz wird nicht an Endkunden verkauft oder nur in Neugeräte eingebaut. :(
anbei neueste firmware für Tekway/Hantek/Voltcraft Beseitigt sind bugs 1,2,3,9,10,11,12,17 Man kann sehen das am bug 4 wird gearbeitet, filter geht jetzt bis 495MHz statt 249MHz (funktion ist aber noch aus). Bug 14 habe nicht getestet. Nicht erschrecken, die main window scala zeigt manchmal falschen wert beim einschalten von F7 - hat aber kein einfluss auf funtion/stabilität - es korrigiert sich von alleine wenn man timebase oder andere controls umschaltet. Bug 1 habe nicht überall getestet, die hilfe datei ist aber deutlich grösser - kann also sein das wirklic alle topic funktionieren.
Thomas R. schrieb: > anbei neueste firmware für Tekway/Hantek/Voltcraft Danke. > Bug 1 habe nicht überall getestet, die hilfe datei ist aber deutlich > grösser - kann also sein das wirklic alle topic funktionieren. Jetzt auch portugiesische Hilfe. Vorher gabs English und Chinesisch.
1 | sqlite> select * from sqlite_master; |
2 | table|tb_en|tb_en|2|CREATE TABLE tb_en(id integer primary key,nindex varchar(100),alias varchar(100) null,topic varchar(100),content varchar(2500)) |
3 | table|tb_cn|tb_cn|453|CREATE TABLE tb_cn(id integer primary key,nindex varchar(100),alias varchar(100) null,topic varchar(100),content varchar(2500)) |
4 | table|tb_por|tb_por|889|CREATE TABLE tb_por(id integer primary key,nindex varchar(100),alias varchar(100) null,topic varchar(100),content varchar(2500)) |
5 | |
6 | sqlite> select content from tb_por where id=2; |
7 | Você pode usar o menu AQUISIÇÃO para controlar como o osciloscópio adquire os dados da forma de onda. Opções: |
8 | ◆^34<Amostragem> (padrão): representa com mais exatidão as formas de onda. |
9 | ◆^35<Detecção de Pico>: detecta falhas e reduz a possibilidade de falhas <serrilhado>. |
10 | ◆^36<Média>: reduz o ruído aleatório (não relacionados ao trigger). |
11 | Para usar o menu AQUISIÇÃO pressione o botão ACQUIRE. |
12 | ... |
wo findet man denn die erwähnte bug liste ? und danke für die neue version
Yatko Jaens schrieb: > wo findet man denn die erwähnte bug liste ? Etwas weiter oben: Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"
habe die neueste FW Version jetzt oben und ich finde das das Oszi etwas besser und schneller reagiert. Vieleicht ist es aber auch Einbildung ;-) Neu ist auch das das Oszi automatisch nach dem FW Update neu startet. Auch funktioniert nun die Refresh Rate im Menü ;-)
Thomas R. schrieb: > Thomas R. (tinman) Datum: 11.07.2012 18:28 > dst1kb_2.06.3_15202b_fact_120625.0_.up (2,7 MB, 35 Downloads) > anbei neueste firmware für Tekway/Hantek/Voltcraft > > Beseitigt sind bugs 1,2,3,9,10,11,12,17 > > Man kann sehen das am bug 4 wird gearbeitet, filter geht jetzt > bis 495MHz statt 249MHz (funktion ist aber noch aus). Hallo Thomas, Vielen Dank dafür!
Hi, darf ich fragen woher die FW kommt? Gibt es sie irgendwo offiziell? Hast Du sie selbst modifiziert? Gruß, Klaus
Klaus D. schrieb: > Hi, > > darf ich fragen woher die FW kommt? hersteller > Gibt es sie irgendwo offiziell? ja hier > Hast Du sie selbst modifiziert? > nein
Thomas R. schrieb: > ja, leider (ich schreibe morgen warum das). Jetzt spannst du uns aber ganz schön auf die Folter :-D Spaß beiseite, was gibts denn für Neuigkeiten? Entschuldige, dass ich nochmal frage, aber ich bin so gespannt ;-)
Ich setze 10 Euro darauf, dass Hantek, Tekway das alles nicht so gemeint hat, es sich anders überlegt hat, vorgibt nie so etwas vorgehabt zu haben, dass alle Ansprechpartner gewechselt haben, man von irgendwelchen Absprachen nichts mehr weiß, usw. usw. Der ganz normale Chinesische Wahnsinn eben.
Hallo Thomas, Betrifft Firmware 120625: Thomas R. schrieb: > Beseitigt sind bugs 1,2,3,9,10,11,12,17 > ... > Bug 14 habe nicht getestet. also den Bug 14 kann ich nicht mehr feststellen, dürfte wirklich beseitigt sein. Peter
Angehängte Dateien:
-
DSO3062_200.png
44 KB
Habe da mal was gebastelt, damit die Beschriftung zu den erweiterten Innereien passt... Farbton des Hintergrunds passt noch nicht 100%, ohne farbkalibrierten Scanner/Drucker ist das schwer zu treffen. Falls Interesse besteht kann ich es wenns fertig ist als PDF oder Corel Draw posten.
Hallo, Betrifft Firmware 120625: Wenn man das Menü ein/ausblendet, pendelt sich das Signal erst wieder nach kurzer Zeit zum horizontalen Trigger ein. Bei der 120423 Firmware geht das sofort. Stört nicht, fällt aber auf. Irgendwie kommt mir die Signaldarstellung weicher/flüßiger vor. Bei FFT wird das Gitter jetzt so angezeigt wie im Displaymenü ausgewählt, also nicht mehr nur die Linien. Bei höheren Frequenzen, so ab 20 MHz ist die FFT-Darstellung schon um einiges anders, vorallem bei Sinussignalen, bei Rechteck sehe ich nicht soviel Unterschied. Peter
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.