mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik TEKWAY DST1xx2B Oszilloskop


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Lukas K. (carrotindustries)


Bewertung
0 lesenswert
nicht lesenswert
Wozu braucht ein Oszilloskop einen Kopfhörerausgang? Zum Vorlesen der 
Hilfetexte, TTs der Measure-Funktion? Oder ist das nur von einem 
Referenzdesign übrig geblieben?

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Lukas K. schrieb:
> Wozu braucht ein Oszilloskop einen Kopfhörerausgang?

Kopfhörer sind besser als Lautsprecher, machen weniger krach -
nicht nur beim p0rnos gucken (früher gabs PC und boss taste,
heute china DSO :P )


> Oder ist das nur von einem Referenzdesign übrig geblieben?

das dachte ich auch am anfang, ala "nette entwickler", Hantek wollte
auch nix dazu sagen (muss man nicht verstehen).

Der grund war aber was ganz einfaches - der integrierter video player
der als video hilfe, aufgaben board o.ä. benutzt werden kann.
(stick rein, per knopf viedo rüberscheiben oder abspielen, aufgaben
erledigen, ergebnisse speichern und dem lehrer mailen)

Auf der HK Fair waren die Inder/Chinesen (vor allem Bildungswesen)
schwer begeistert, in Deutschland "glücklicherweise" wird sowas
nie gebraucht, hier wird keine Schule neue DSOs kaufen.

von Alex (Gast)


Bewertung
0 lesenswert
nicht lesenswert
was aus denkbar wäre aber bestimmt nicht so kommen wird, ist die ausgabe 
einer nf über die kophörerbuchse um zb das signal in einen verstärker 
einzuspeisen und dort das signal zu verfolgen.
da braucht man für die fehlersuche in einem verstärker nicht immer extra 
einen nf generator

von Patrick (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich finde einen Videoplayer in einem DSO einfach nur hohl.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Patrick schrieb:
> Ich finde einen Videoplayer in einem DSO einfach nur hohl.

ja, das Education Kit in Agilent DSOX finden auch viele als hohl/unsinn,
andere wiederum freuen sich das die schüler/studenten/senile mitarbeiter
auf eine einfache art geschult/"refreshed" werden können.

Ich mag weder videplayer in DSOs, noch mp3 format und def. keine
clicki bunti smartphones .. trotzdem gibts die und auch eine
nachfrage ist vorhanden. Die generation "nach Tschernobyl/nach 
Mauerfall"
braucht sowas, ob die generation "nach 9/11" noch schlimmer sein weiss
noch niemand, wobei erste anzeichen sind schon vorhanden.

von Yatko J. (denim)


Bewertung
0 lesenswert
nicht lesenswert
Guten Abend zusammen, ich habe mir auch einen Tekway dst1062B gegönnt, 
da dieser ja auf 200MHz "einstellbar" sein soll und weil dieser relativ 
günstig war :)

Meine aktuelle Firmware: 2.06.3(111202.0)

ich habe zwar den Thread ein wenig gelesen, aber kann mal jemand bitte 
so nett sein und kurz zusammenfassen wo wir stehen?

- Gibt es eine alternative Firmware?
- Wenn ja, was ist besser und sollte man diese draufhauen?
- Ist meine Firmware noch OK oder längst überholt mit neuen Features und 
mehr Stabilität? Leider allein heute 3 Abstürze gehabt und Hänger...
- wie kann man am besten die 200MHz freischalten? Anleitung hier im 
Thread zu finden?
- gibt es einen win7 x64 usb treiber dafür ?

Danke und sorry für den kurzen und knappen Beitrag..
D

von Yatko J. (denim)


Bewertung
0 lesenswert
nicht lesenswert
zwei Fragen kann ich inzwischen selber beantworten, falls es jemanden 
noch interessieren sollte:

> - wie kann man am besten die 200MHz freischalten? Anleitung hier im
> Thread zu finden?
Geht über nur UART oder einer Soft auf eev blog / forum zu finden. Ich 
habs mit UART gemacht, geht relativ easy. Max3233 Konverter benötigt. 
Ein paar files ändern. siehe 
http://www.eevblog.com/forum/index.php?topic=1571.0

> - gibt es einen win7 x64 usb treiber dafür ?
Ja, diesen hier nehmen: ha te te pe : doppelSLASH www.hantek.com.cn 
SLASH Product SLASH 64Driver SLASH DSO5000.rar

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
und alt. firmware, bzw letztee firmware

ist hier

Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

und hier steht was neu (wobei die fehler sind beseitigt)

Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"


was hackes/infos/updates angeht, ich poste aber vor allem auf eevblog
(abgesehen von firmwares da hotfile nervt und eevblog zu kleine att.
erlaubt)

von Nils S. (kruemeltee) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Yatko Jaens schrieb:
> Ja, diesen hier nehmen: ha te te pe : doppelSLASH www.hantek.com.cn
> SLASH Product SLASH 64Driver SLASH DSO5000.rar

Spamschutz für rar Dateien?!

von Yatko J. (denim)


Bewertung
0 lesenswert
nicht lesenswert
> Spamschutz für rar Dateien?!

ah, kann sein. musste es halt so schmutzig schreiben :)

von Yatko J. (denim)


Bewertung
0 lesenswert
nicht lesenswert
@ Thomas R.

Danke erstmal für Deine großartige Arbeit ! Wirklich bemerkenswert wie 
viel Arbeit man doch in sowas reinstecken kann  :)

Ich habe jetzt alles draufgemacht, letzte FW und 200MHz. Alles supi 
jetzt.

Macht es Sinn hierfür einen FT232RL reinzuhauen und irgendwo UART mit 
ner USB Buchse auszuführen? An dem Pin sind ja 5V auch vorhanden, damit 
könnte man den FT232RL füttern. Man bräuchte dann nicht immer das Gerät 
aufzuschrauben. Könnte ne Eagle Datei fertig machen. Die andere Lösung 
(über USB Befehle an das Dingen schicken) ist auch nicht schlecht, aber 
scheint mir nicht ganz so sicher zu sein, da es vom Betrieb des Gerätes 
abhängt.

Grüße
D

PS: Welchen USB Sniffer nutzt Du eigentlich ?

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Yatko Jaens schrieb:
> Wirklich bemerkenswert wie viel Arbeit man doch in sowas
> reinstecken kann  :)

die motivation zu finden ist am schwersten, zeit habe ich
sowieso keine allerdings arbeit macht frei, daher mache ich weiter.

Leider zu viele baustellen gleichzeitig, die information ist zwar
dadurch nciht verlohren allerdings verzögert sowas die vollendung
von einigen wichtigen punkten (z.b. LAN)

Yatko Jaens schrieb:
> Macht es Sinn hierfür einen FT232RL reinzuhauen und irgendwo UART mit
> ner USB Buchse auszuführen?

ja, kann man machen, wobei der S3C2440 mag nicht wenn die
leitungen zu lag sind und der bootloader neigt zu stoppen
falls da schon irgendwas im RXD buffer steht.
Was gut funktioniert sind optocoup. und externe versorgung für
ftdi.

Was auch geht ist natürlich lan.

>
> PS: Welchen USB Sniffer nutzt Du eigentlich ?

bis jetzt USBlyzer von usblyzer.com, irgendwann wenn die jungs fertig
sind und wir schon usb5.0 haben werde wohl openvizsla benutzen

von Nils S. (kruemeltee) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> S3C2440 mag nicht wenn die
> leitungen zu lag sind

Ich hab an einem meiner s3c2440-Boards einen FTDI mit ca. 15cm 
Flachbandkabel hängen, gar keine Probleme.
Belegung des Kabels:
VCC,GND,GND,Rx,GND,Tx,GND,GND,VCC

von Roland (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi leute,

ich habe das problem, dass mein Hantek dso 5102B nach dem einschalten 
zwar bootet und mir den bildschirm mit dem raster anzeigt, aber danach 
tut sich nix mehr. ich wüsste net dass ich was falsches gedrückt habe 
oder sonst was. war auf einma nach dem einschalten so...

kennt das jemand?

gruß roland

von Yatko J. (denim)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Roland, ungefähr das selbe hatte ich auch gehabt, Thomas R. hat 
mir hier hilfreiche Tipps gegeben, leider musste ich aufschrauben, 
danach ging es wieder ;)
siehe eevblog  ab Reply #1054
http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/1050

viel Erfolg
D

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eine warnung : Tekway hat auf deren chinesischen website
"neueste" firmware gestellt.

Leider ist e nciht die neueste (steht zwar 2.06.3 [2012-2-1] drin
ist aber eine version vom Nov 2011).

Dazu sind es versionen die NUR chinesisch unterstüzen,
sprich die englis/deutsch usw. language text files sind
in diesen firmwares nciht drin.

Da die text files versionsabhängig sind werden die beim update gelöscht,
d.h. nach dem update hat man nur chinesisch.

Ich habe es Tekway gemeldet, mal sehen ob die wieder wochen
brauchen um die links / content anzupassen.

von Pascal H. (pase-h)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Ich wollte nur mal fragen, wie es zurzeit mit der LCD2VGA+LAN Platine 
aussieht?
Steht ein ungefährer Preis schon fest?

Mfg
Pascal

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
kann dir leider nix sagen ausser das der preis noch nicht fest steht.

Es läuft etwas schleppend, alleine zwei wochen gebraucht um zu
erfahren das der hersteller von VGA2LCD mir auf einmal doch
keine FPGAs verkaufen will, warum auch immer (denke wohl wegen gewinn,
ich will aber keine 10EUR extra bezahlen für SDRAM und PCB -
klar SRDAM brauche ich zwar auch aber ich muss die PCB fläche
nicht doppelt bezahlen).

Habe gestern jemanden entdeckt der ähnliche module produziert
und sofort sample bestellt (der wäre bis jetzt mindestens
bereit nur FPGAs zu verkaufen).

Wie ich schon gesagt habe, der "rest" hängt dann von der gesamtmenge,
bis jetzt sind es 12 vorbestellt.

von Horst (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> Leider ist e nciht die neueste (steht zwar 2.06.3 [2012-2-1] drin
> ist aber eine version vom Nov 2011).
>
> Dazu sind es versionen die NUR chinesisch unterstüzen,
> sprich die englis/deutsch usw. language text files sind
> in diesen firmwares nciht drin.
Hat das ein Chinese geschrieben?

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Horst,

welchen teil meiner aussage hast du nicht verstanden?
So schwer ist die deutsche sprache nicht, wenn du es denoch nicht
verstehst kann ich gerne in 14 anderen sprachen schreiben, irgendeine
davon wirst du hoffentlich verstehen.

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:

> Habe auf die schnelle etwas gebaut, DSO über USB an PC anschliessen,
> die DSOReset.exe starten und reset button drucken. Nach dem reboot
> (sollte es automatisch, tut es nciht sofort dann einfach DSO
> abschalten und wieder einschalten, der auto reboot hängt manchmal)
> wird dein scope mit default einstellungen starten.

Ich hab leider genau das gleiche Problem! Das Oszilloskop habe ich seit 
heute und nach 1h macht es leider schon mucken. Das Tool von dir 
funktioniert leider nicht bei mir. Mit welchem UART Tool vollzieht ihr 
den Zugriff?

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

Tim R. schrieb:
> Ich hab leider genau das gleiche Problem! Das Oszilloskop habe ich seit
> heute und nach 1h macht es leider schon mucken. Das Tool von dir
> funktioniert leider nicht bei mir. Mit welchem UART Tool vollzieht ihr
> den Zugriff?

Die letzten FirmwareVersionen scheinen in der Tat etwas "instabil" zu 
sein.
Im Moment denke ich ernsthaft darüber nach wieder ein paar Schritte 
zurück zu gehen.
Da ist es echt ein Manko von Hantek. Prinzipiell finde ich die 
WEiterentwicklung und funktionserweiterungen gut. Aber es sollte bei 
denen einer Trennung zwischen Beta Release und Stable Version geben.
Die haben ha zwischendurch durchaus echt brauchbare Versionen 
herausgebracht die für den durchschnittsanwender keine wirklich 
relevanten BUGs hatten.
Es wäre wirklich schön wenn Versionen die sich nach einer Testphase als 
voll Funktionsfähig erweisen dann ausdrücklich als STABLE gekennzeichnet 
werden würde und auch zumindest die letzte davon weiterhin zum Download 
zur Verfügung stünden. Neuere Versionen sollten dann halt BETA sein und 
es sollte immer ein "zurück" ohne Aufwand auf die letzte Stable möglich 
sein.

Aber zum Ursprünglichen Fehler hier:
Das die Anzeige nach AUS- und wiedereinschalten abhängig von der 
Einstellung beim wiedereinschalten spinnt habe ich mit der aktuell bei 
mir vorhandenen Version auch (ist glaube ich die vorletzte).
Allerdings wird bei mir mit Druck auf default der Pegel wieder 
angezeigt.
Alles ausser DEfault zeigt so lange keine Wirkung.
Eine völlige Bedienungsunfähigkeit habe ich aber noch nicht gehabt. 
Liegt das evtl. an "Pfuschahften" Flashen der Chinaverkäufer ?
(@TE wo hast du das Gerät gekauft, war es geflasht)

Ansonsten: Thomas Anleitung Wortgenau eingehalten? Mit den Zeiten fürs 
ein- und Ausschalten muss du es relativ genau nehmen!

Allgemein kann ich aber nur wiederholen das ein wechsel ein paar 
Schritte zurück in der FW Historie im Moment sicher den Gebrauchswert 
deutlich erhöht, man damit ein voll Einsatzfähiges Skope erhält was es 
momentan leider nicht mehr ist. Evtl. macht thomas ja mal eine 
Spezialversion fertig,denn einmfach so kann man ja keine ältere Version 
aufspielen, dazu muss man schon von innen ran.

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
@Carsten Sch.

Danke für deine lange Antwort. Da ich nur die Windows 7 64 Bit Version 
benutze musste ich auch den Treiber von der Webseite zurückgreifen. Es 
kann leider vorkommen, dass ich durch schnelles ausschalten des 
Oszilloskope tatsächlich den PC im bluescreen bekomme. Bis jetzt war der 
PC völlig bugfrei. Ich schaue gerade, ob ich nicht einen 32Bit Rechner 
hier habe, vielleicht kann ich dadurch das Oszilloskope testen.

Im Prinzip sehe ich auf dem Screen das Menü von CH1 und kein Messsignal. 
Die Tasten CH1 MENU, AUTO SET und RUN/STOP (in grün) leuchten dauerhaft. 
Default Setup ruft keine Reaktion hervor.

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
Hat leider nicht funktioniert. Ich bin mit meinem Latein am Ende. Das 
Gerät habe ich übrigens direkt aus China bestellt über den Ebay-Händler 
lotusdechine2006

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
hmmm, leider habe keine Probleme mit aktuellen Firmware.
Ich weiss zwar das da grundsätzlich ein Problem auftauchen kann
wenn die Einstellungen kaputt gespeichert werden, allerdings
wie gesagt habe bei den aktuellen Firmware keine solche Probleme
(bzw. nicht öffters als sonst) gehabt.

Wobei ich halte mich auch an eigene Vorgaben - das DSO nicht
abschalten falls änderungen in letzten 15sek gemacht waren.
Und falls doch etwas kaputt geht, einmal die "Default Setup" Taste 
drucken
hat immer geholfen, das mit dem löschung von /param/sav/run*
ist lediglich Maßnahme FALLS die "Defualt Setup" Taste nicht 
funktioniert.

von P. K. (dg4ek)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

schaut mal ein ganzes Stück weiter oben. Thomas hat dort eine
Version eingespielt mit Hilfe derer ihr die Versionsnummer
voll zurücksetzen könnt und damit nach dem Rücksetzen in der Lage seid, 
JEDE beliebige Version einzuspielen.

Bei mir läuft Thomas letzte Version übrigens problemlos!
Das einzige was ich noch als störend empfinde sind die
Stops bei der Anzeige (Anzeige friert kurz ein). Diese kommen
durch Fehlermeldungen die man aber nur sieht, wenn man
auf die Linuxebene zugreift. Da es wohl sehr viele sind
(Debug-Meldungen), ist es sehr aufwendig, alle zu entfernen.

Eigentlich und wirklich ist das Hantek Job...(wie so vieles
was noch nicht korrigiert ist). Ich bin froh dass Thomas
sich derart hineingekniet hat, ansonsten ich die Kiste schon
längst in hohem Boden nach China geschleudert hätte...

Anderseits ist das Teil eine wirklich schöne Kiste (für das kleine Geld) 
und man kann auch froh sein, dass alles mehr oder
weniger "offen" ist. Versucht mal ein Schaltbild von einem
anderen Gerät zu bekommen oder Änderungen in der Firmware
selbst machen zu können! Ausichtslos!

Meine Meinung: besser ein Skop was von Zeit zu Zeit
verbessert wird, als endlose Hin- und Herschickerei
und das auch noch nach China ;)

In dem Sinne
beste Grüße
Peter

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Tim R. schrieb:
> Das Tool von dir funktioniert leider nicht bei mir.

dann nimm das hier ^, wenn dein scope erkannt wird, wird
das button auch aktiv (damit weisst man schon das die kommunikation
mit DSO geht).

Es mag sein das beim reboot das DSO stehen bleibt, liegt nicht an
dem tool sondern an dem 2.6.13 kernel. Falls das so ist,
einfach abschalten und einschalten, hauptsache das tool hat
die einstellungen gelöscht und reboot ausgelöst.

> Mit welchem UART Tool vollzieht ihr den Zugriff?
egal was für eins (z.b. putty), 8n1, 115200 und gut ist.

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> dann nimm das hier ^, wenn dein scope erkannt wird, wird
> das button auch aktiv (damit weisst man schon das die kommunikation
> mit DSO geht).

Uhhh vielen Dank. Die Vorversion deiner Reset-SW habe ich bereits 
genutzt und konnte auch auf den Button drücken. Leider bringt diese 
Version auch nicht. Schade. Ich bekomme vom dem DSO reset tool erst eine 
Reaktion, wenn ich nach 5 Sekunden das Scope ausschalte. Die Message: 
Success! Your scope should now reboot with default setting.
Als Plattform nehme ich kein Windows 7, sondern eine 32bit Version von 
XP. Hätte ja eine Fehlerursache sein können.
Wie gesagt, ich kann wirklich nichts am DSO5102B bedienen. Weder ein 
Menü noch irgendwas anderes, als würde das ganze Oszilloskop hängen.

Vielleicht habe ich auch nur ein Montagsgerät.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
kann bitte jemand das tool kurz testen ?

Also hier geht es auf zwei DSOs, beide haben unterschiedliches
root fs allerdings die neueste firmware, abgesehen vom reboot
fehler bei einem DSO ist alles so wie es sein soll - nach
dem reboot sind die settings wieder auf default (erkennt man an der
ui farbe - die ist dann blau  es macht also sinn die zu ändern auf
was auch immer falls man blau hat ...)

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> (erkennt man an der
> ui farbe - die ist dann blau  es macht also sinn die zu ändern auf
> was auch immer falls man blau hat ...)

Wo du gerade UI-Farbe sagst. Da ich das Scope ja neu hatte habe ich mich 
durch die Menüs geklickt und die UI Farbe auf Grau gestellt. Die 
UI-Farbe ist nach einem "angeblichen" Reset (ich drücke das einfach mal 
so aus) weiterhin grau.
Über UART kann ich zurzeit keinen Reset durchführen, da ich schlichtweg 
keinen UART Transceiver hier besitze. Zwar habe ich auf einigen 
EVO-Board etwas ähnliches, aber die schaffen nicht 115200 Baud.

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
Aus Langeweile und Frust habe ich mir nochmals einige Beiträge 
durchgelesen. Dabei bin ich auf die Funktion "Bode Assistent" gestoßen. 
Wie bei Dirk (08.01.2012) ist genau an diesem Punkt mir das Oszilloskop 
hängen geblieben und seitdem habe ich das Problem.

von Carsten S. (dg3ycs)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> kann bitte jemand das tool kurz testen ?

Gerade geschehen...
Bei mir läuft das TOOL genau wie es soll. Reset wird durchgeführt und 
danach sind alle Einstellungen wieder wie im Auslieferzustand.
Der BOOTZähler wird aber nicht zurückgesetzt.

Tim R. schrieb:
> Aus Langeweile und Frust habe ich mir nochmals einige Beiträge
> durchgelesen. Dabei bin ich auf die Funktion "Bode Assistent" gestoßen.
> Wie bei Dirk (08.01.2012) ist genau an diesem Punkt mir das Oszilloskop
> hängen geblieben und seitdem habe ich das Problem.

Ich habe gerade mal versucht das Nachzustellen, bei mir, obwohl selbe 
Firmwareversion, passiert gar nichts...
Evtl. liegt es an anderen Einstellungen? Welche Sprache und welche UI 
Farbe hattest du denn eingestellt.

Ansonsten kann ich den Frust durchaus Nachvollziehen. ICh würde dann 
jetzt versuchen Morgen entweder an einen älteren Computer zu kommen oder 
entweder eine PCI Schnittstellenkarte mit COM oder aber einen USB-COM 
Wandler zu besorgen und damit zuerst die "raue" Resetmethode und wenn 
das auch nicht hilft einfach alles Überzubügeln ausprobieren.
(ISt zwar nervig, die Komponennten sind aber zum Glück günstig zu 
bekommen. (Wenn Steckplatz vorhanden würde ich die PCI Lösung 
vorziehen)Damit sollte wirklich jedes SW Problem in den Griff zu 
bekommen sein.
Wenn das dann auch nicht hilft bleibt leider nur entweder die 
Kontakaufnahme zum Händler oder als zweite Lösungsmöglichkeit die 
Inanspruchnahme der Werksgarantie bei einem zur Garantiereparatur 
authorisierten europäischen Hantek Vertragspartner.

Ach ja:
Ich habe mal ein Screenshot von meinen Systeminformationen angehangen:

Gruß
Carsten

von P. K. (dg4ek)


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Thomas R. schrieb:
>> kann bitte jemand das tool kurz testen ?
>
> Gerade geschehen...
> Bei mir läuft das TOOL genau wie es soll. Reset wird durchgeführt und
> danach sind alle Einstellungen wieder wie im Auslieferzustand.
> Der BOOTZähler wird aber nicht zurückgesetzt.

Kann ich auch bestätigen, einwandfrei ohne Probleme.
Ob bei den beiden Problemfällen eine Änderung in der Hardware
vorhanden ist? Alles sehr seltsam...

Gruss
Peter

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Danke für die tests!

Habe jetzt gut eine stunde lang im bode assist alles gemacht
was so üblicherweise böse sein kann - cursor umgeschaltet, wild
herugedreht, timebase geändert - gleichzeitig im bode assis daten
aktualisiert (V0), und mit "dritter hand" noch die volt/div geändert,
random sachen gemacht, puuh, long mem forced mitten drin im bode -
und egal was ich gemacht habe passierte nix böses.

Tut mir leid, aber ich brauche etwas was man reproduzieren kann,
random fehler ist nix womit man arbeiten kann (auch wenn es
sehr ärgerlich ist, nciht falsch verstehen)

von Yatko J. (denim)


Bewertung
0 lesenswert
nicht lesenswert
vielleicht haben wir verschiedene boards? ich habe die 7er soweit ich 
mich erinnere ( hab das dingen verliehen zur zeit )
ich habe auch diese abstürze und das vorletzte USB reset tool ging bei 
mir auch nicht.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich habe hw0 und hw1007, Carsten hw0, Peter hw1007 - das macht
je zwei exemplare von jeweiligen hw release die getestet waren.

Du müsstest schon hw1005 haben um "anders" zu sein, hast du aber nicht.

Vom board seite wird also kein unterschied sein, was noch sein
kann ist FPGA design. Welche version drauf ist kann man
einfach prüfen, System info-> hw version zeile

AAAAAxBBBBCCCC

AAAAA is 0, 1005 oder 1007 und steht für mainboard version
BBBB ist afaik immer 5555
CCCC ist FPGA design version, wobei

83e8 ist hw0, hw1007, handheld hw1.01, hw1007 beta design von Tekway
83e9 ist hw1005

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

gestern Abend habe ich noch das Oszilloskop geöffnet und könnte dir 
evtl. auch alle relevanten Informationen zukommen lassen.

-Die Seriennummer fängt mit T120... an.
-Ein kleiner weißer aufkleber mit roter Schrift: CJH5
-grüne Platine

Meine bekannten Einstellungen:
-graues Menü und Zeit eingestellt

Mehr Informationen habe ich nicht gefunden. Gegen Abend bin ich wieder 
zu Hause.

von Tim R. (mugen)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das Oszilloskope läuft wieder :D

Ich bin gerade total happy und genieße gerade mein Belohnungs-Bier. Ich 
hatte eigentlich nichts zur Verfügung als ein Max232, ein MSP430 
Evo-Board als Spannungsquelle, Lackdraht und Flachbandkabel. Und konnte 
mich durch einen recht bedenklichen Aufbau über Putty und mit der 
Linux-Konsole verbinden. Ich wusste bis zu diesem Zeitpunkt nicht, dass 
Linux als OS verwendet wird. Die Datei /param/sav/run1kb* habe ich dann 
gelöscht. Das Scope funktionierte nach einem Neustart wieder 
einwandfrei.

Vielen Dank nochmal!

SW Version: 2.06.3(111226.1)
HW Version: 10070x5555k3e9

Den Aufbau habe ich mal als Bild angehängt.

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Tim R. schrieb:
> Das Oszilloskope läuft wieder :D
>
> Ich hatte eigentlich nichts zur Verfügung als ein Max232, ein MSP430
> Evo-Board als Spannungsquelle, Lackdraht und Flachbandkabel. Und konnte
> mich durch einen recht bedenklichen Aufbau über Putty und mit der
> Linux-Konsole verbinden.

Na, das zeichnet doch gerade den "guten" Elektroniker aus. Die 
Möglichkeit zur Improvisation. Und wenn es denn dann noch erfolgreich 
ist.

> Das Scope funktionierte nach einem Neustart wieder einwandfrei.
Prima, da lässt sich alles weitere gleich viel lockerer angehen. ;-)
Wobei es für ein Messgerät natürlich besser währe wenn man auf solche 
Dinge gar nicht angewiesen ist solange man es nicht bewusst riskiert.
(Siehe meinen Beitrag oben: Kennzeichnung Beta vs. stable Version)

Aber davon abgeshen ist der Aufbau des Skopes verbunden mit Thomas 
Fachwissen schon ein gewaltiger Vorteil.
ICh betreue neben meinem privaten Skope noch Gerätre die wir im 
Studentenlabor der FH (für freies Arbeiten im Rahmen von Hobby und auch 
kleinen Projekten, hat nichts mit dem REgulären Lernbetrieb zu tun) 
haben.
Da mache ich das schon so, das ich dort nur SW Versionen aufspiele die 
sich bei mir Privat schon einige Wochen bewährt haben.

Dadurch habe ich zu den Skopes dort bisher aber nur positive 
Rückmeldungen ;-)

@Thomas

Du schriebst das durch die Verwendung von Schaltwandlern anstelle der 
3,3V LDO die Wärmeentwicklung bedeutend reduziert werden kann.
Hast du zufällig im Kopf ob dazu die Schaltwandler von der 
Signalaufbereitung aus den Mobilfunk BTS mit den drei FPGA geeignet sind 
wo ich dir eine von geschickt habe?

Gruß
Carsten

von Johannes R. (johannes_r29)


Bewertung
0 lesenswert
nicht lesenswert
Liefert das Launchpad nicht RX/TX für "RS232" mit 3V3?

MFG Johannes

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
Johannes R. schrieb:
> Liefert das Launchpad nicht RX/TX für "RS232" mit 3V3?

Wenn die Frage für mich gemeint war, dann liefert das EvoBoard wirklich 
nur die 5V Supply vom USB-Port. DAs EVO-Board selber hat eine 
Limitierung der Bautrate bis zu 9600. Das war übrigens der Grund warum 
ich mir endlich ein Oszilloskop gekauft habe um dieses Problem mit dem 
EVo-Board wirklich zu verifizieren. Ich hätte ja nie gedacht, dass ich 
eine UART Schnittstelle späte selbst für das Oszilloskope brauche. Das 
ist wie mit der Henne und das Ei. Ich fühlte mich schon etwas 
verschaukelt vom Leben ;)

@Carsten Sch.

Ich bin auch wirklich sehr froh über diesen guten Support in diesem 
Forum. Das war auch einer der Gründe warum ich mir dieses Oszilloskope 
gekauft habe. Bis jetzt finde ich es wesentlich besser als einige 2000er 
Oszilloskope von Tek die wir auf Arbeit haben. Schnell und flott ist es 
dazu auch noch.

von Johannes R. (johannes_r29)


Bewertung
0 lesenswert
nicht lesenswert
Naja, man kann sowas ja auch noch mit nem LA machen, die Chinesen haben 
da ganz nette für 14$ mit 8 Kanälen und 24MHz maximaler Samplingrate, 
zwar haben die keinen verbauten Speicher, aber das ist nicht all zu 
schlimm.

9600 BAUD sind in der Tat arg wenig, da mich das CA42 mit dem fixen 3V3 
Pegel nervt hab ich mir aber schon einen UART Adapter mit 5V/3V3 
Umschalter aus China für rund 2€ bestellt, dann kann man nicht nur 3V3 
Geschichten wie hier bearbeiten.

PS: Es gab im eevblog eine "Modsoftware" mithilfe derer man ohne das 
Öffnen des Gehäuses die Bandbreite ändern kann.

MFG Johannes

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Du schriebst das durch die Verwendung von Schaltwandlern anstelle der
> 3,3V LDO die Wärmeentwicklung bedeutend reduziert werden kann.
> Hast du zufällig im Kopf ob dazu die Schaltwandler ... geeignet sind

leider nciht weil die ADCs auch dadran hängen, da muss schon ripple
faktor 6-10 kleiner sein, sowas wie Micrel HELDO oder der TI DC
(hab die bezeichnung gerade nciht im kopf) läuft sehr gut.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tim R. schrieb:
> Vielen Dank nochmal!

aber doch gerne.

>
> SW Version: 2.06.3(111226.1)
> HW Version: 10070x5555k3e9
>

aha, das ist was ich gestern nicht schreiben wollte,
FPGA design ist xxx9 und nicht xxx8, d.h. du hast
neues FPGA design drin /(was unter umständen fehler erklären kann!!!)

Wenn dir nix ausmacht kopiere die /dn.rbf vom DSO rüber auf
stick (wird automounted ins /mnt, evt. /mnt/udisk falls du eine
neueste root fs hast - und falls ja dann würde ich gerade backup
von ganzen NAND/fw haben) und schicke mir zu.

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
@Thomas R.

Email ist raus.

@Johannes R.

Gestern habe ich sicherheitshalber über Ebay drei UART Module mit 3v3 
und 5v bestellt. Die werden wohl irgendwann in 4 Wochen ankommen. =)

von Pascal H. (pase-h)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Ich hätte mal eine Frage:
Kann man das Speicherverhalten vom Hantek ändern, sodass für jeden 
Screenshot nicht immer ein neuer Ordner angelegt wird?

Mfg
Pascal

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
übrigens, so sieht ein neuer Tekway (mit LA)

Den würde ich gerne dumpen und mir den LA angucken, ist
aber leider z.zt. nur in China verfügbar.

Im vergleich sehen die 4ch Hanteks einfach nur "edel"

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
Uiii - So ein LogicAnalyser wäre schon was feines.

von Yatko J. (denim)


Bewertung
0 lesenswert
nicht lesenswert
sieht irgendwie aus wie der Rigol DS1052D
ist denn hier die FW für den Rigol nicht verfügbar?
zusätzlich LA wäre traumhaft :)

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eigentlich ist es ein MSO, laut den datenblatt 16 digitale kanäle,
max 500MSs sampled, max 512k samples und 100MHz analog bw.
Logischerweise auch trigerung auf LA pattern möglich.
Vorläufiges preisunterschied ist beim 250-300EUR, für ein
MSO durchaus verständlich.

Interessant das es 16 kanäle sind, die neuen 4 kanal DSOs von Hantek
(Tekway wird die auch rausbrngen) werden nur 8 digitale kanäle haben.

Man muss aber beachten das weder die 4kanal MSOs von Hantek noch der
2kanal von Tekway verfügbar sind. Es sind lediglich bilder und
datenbläter - die können sich noch ändern. Es wird auch dauern bis
die verfügbar sind, üblicherweise so um die 3 monate von ankündigung
bis verfügbarkeit.

von Pascal H. (pase-h)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
die folgende Seite könnte für manche interessant sein:
https://github.com/sobomax/hantek_dso_kernel

Darauf ist der Kernel vom Hantek DSO.

Mfg

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ehm, das ist 2.6.13 kernel vom qq2440 board - das ist eigentlich was
die Tekway leute org. zum testen genommen haben, es ist aber nicht
DAS kernel vom Hantek/Tekway. Beachte, da gibts keine treiber für
die DSO hardware!

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Da immer wieder irgendwelche Fehler aufgetaucht sind bei den
Geräten hw10070x555583e9 habe ich eine Bitte.

Falls jemand von euch hw1007 5555x83e9 hat (Hantek/Tekway/Voltcraft)
und verfügt über Altera JTAG Kabel dann bitte read back von dem MAX II
CPLD machen und hier posten/mir zuschicken.

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> Falls jemand von euch hw1007 5555x83e9 hat (Hantek/Tekway/Voltcraft)
> und verfügt über Altera JTAG Kabel dann bitte read back von dem MAX II
> CPLD machen und hier posten/mir zuschicken.

Würde es auch mit ein anderes JTAG Modul gehen? Allerdings bezweifle ich 
es, dass das CPLD so ohne weiteres ausgelesen werden kann.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tim R. schrieb:
> Würde es auch mit ein anderes JTAG Modul gehen?

naja, es müsste schon eins sein der MAX II lesen kann.

> Allerdings bezweifle ich
> es, dass das CPLD so ohne weiteres ausgelesen werden kann.

bis jetzt waren die CPLDs nicht protected, weder beim bench noch beim
handheld scopes.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hier ein Weg, wie man das DSO zum kompletten Absturz bekommt. Betrifft 
das Voltcraft DSO-3062C, das jetzt ein Hantek DSO5202B ist, mehr dazu 
siehe Thread:
Beitrag "VOLTCRAFT DSO-3062C 60 MHz = baugleich mit?"

Firmware: 2.06.3 (120112.1)
Hardware: 10070x555583e9
Seriennr: T 1G/01200xxxx

Vorgang: Time Base auf 80 ms und Trigger auf 'Auto' für den 'Scroll/Roll 
Mode'. Dann bei 'Acquire' die 'Mem Depth' von 4K auf 40K setzen, und aus 
is'. Egal ob ein oder beide Kanäle aktiviert sind.
Ob die Einstellungen Sinn ergeben ist eine andere Frage - mir ist es 
passiert beim Durcharbeiten des Handbuchs.

Ich habe vorher hier und im EEVblog-Forum nach 'Srcoll/Roll Mode' 
gesucht, aber nichts dazu gefunden. Vielleicht kann jemand damit etwas 
anfangen bzw. ist davor gewarnt.

Es hilft dann kein "Default Setup" oder aus- und einschalten mehr, nur 
das Löschen der Datei "/param/sav/run1kb*" per Konsole über UART. Das 
DSO-Reset-Tool von Thomas R. hilft leider, hier unter Windows XP Pro, 
auch nicht weiter.

Peter

von Mike (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe ein 100 mhz Hantek der frühen stunde ausgegraben,

Undzwar ein
HW: 0x555583e8,
SW: 2.06.2


Prinzipell scheint es stabil zu laufen, einen Frquenz hack brauche ich 
nicht unbedingt.

Frage in dem Gewirr an FW, welche FW ist aktuell und kann man 
bedenkenlos per USB-stick installieren?


Ich vermute der 200mhz HACK geht nur per Uart oder?

lg Michael

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mike schrieb:
> Hallo,
>
> Ich habe ein 100 mhz Hantek der frühen stunde ausgegraben,
>
> Undzwar ein
> HW: 0x555583e8,
> SW: 2.06.2

>
> Frage in dem Gewirr an FW, welche FW ist aktuell und kann man
> bedenkenlos per USB-stick installieren?
>

ui, 2.06.2, da wird du unter umständen probleme bekommen beim
updaten auf neueste firmware, und zwar jedesmal beim entpacken
von dso.exe wird die alte firmware fehler melden.
Kannst versuchen, falls da bei dir auch der fall ist kann ich ein
firmwaer update bauen der es umgehen kann (im prinzip muss man nur von
hand dso.exe rüber kopieren nach dem update fehlgeschlagen ist und
danach nochmal drüber updaten damit nix fehlt ... super oder?)
Wobei warte, ich muss so ein update schon ferti haben ..


>
> Ich vermute der 200mhz HACK geht nur per Uart oder?
>
> lg Michael

es gibt auch ein tool der über USB den hack macht, 
siehehttp://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg91877/#msg91877

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also Mike (und alle anderen die firmware älter also
2.03.3 April 2011 haben)

den anhang auf leeres usb stick entpacken, es werden zwei
dateien sein:

dst1kb_2.06.3_uni(111202.0).up
dso.exe

stick rein, firmware update ausführen.
Danach wird dein DSO auch die neuesten firmwares akzeptieren,
die letzte stabile version ist die hier:

Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"
http://www.mikrocontroller.net/attachment/131453/dst1kb_2.06.3_15202b_fact_120112.1_.up

von Mike (Gast)


Bewertung
0 lesenswert
nicht lesenswert
UFF: THX, das ging aber schnell,

Hat funktioniert, läuft nun mit 2.06.3(120112.1),

Eine Frage habe ich noch, haben neuere HW Revisionen Vorteile bezüglich 
der Sampletiefe bei höheren Abtastrate? (Oder sonstige Mussthaves?)

Das Hantek MSO hab ich schon gesehen, sieht interessant aus allerdings 
erwarte ich mir davon nicht all zu viel...


Nochmals vielen dank an Tinman für die tolle Hilfe. (Besorg dir einen 
Flattr button ;)

lg Michael

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe zwar das selbe schon im "Voltcraft" thread gepostet,
aber eigentlich ist es hier besser ausgehoben.

Habe die letzten firmware/hardware kombinationen getestet
und doch die 3 bugs gefunden/nachsimuliert bekommen:


timebase von 4ns/div auf 2ns/div ändern beim aktivierten
equ mode und ausgeblendeten menu bringt die dso.exe
zum absturz, neustart von DSO möglich.
- workaround - menu nicht abschalten oder real time
sampling benutzen (was eh mehr sinn macht bei einem
1GSs DSO mit max 480MHz bandbreite), mit avg mode
wenn sein muss, bringt eh mehr als equ mode.


sample speicher änderung von 4k auf 40k, 1M auf 4k, 4k auf 8k
(passiert versteckt beim umschalten von real time auf equ
mode sampling) bring die dso.exe zum absturz wenn 80ms/div
aktiviert sind, trigger steht auf auto und roll mode. Erneut
einschalten hilft nicht, absturz versaut die setup datei
(/param/sav/run1kb_******). Nur manuelles löschen hilft.
- workaround - siehe weiter unten


sporadische fehler bei der 111226.1 (werksfirmware)
und meiner 120112.1 bei den hw10070x555583e9 geräten.
Ergebniss ist wieder kaputte setup datei (/param/sav/run1kb_****** ). 
Wieder nur manuelles löschen hilft.
- workaround - siehe weiter unten


Diese o.g. fehler tauschen bei folgenden fw:
- Voltcraft 2.06.3 - 111226.1
- HanTekway 2.06.3 - 120112.1

Die fw von Hantek website (auch 111226.1) ist nicht betrofen,
aber wie wir schon wissen hat ein paar andere ugly bug, daher hat
HanTekway die 120112.0 und tag später 120112.1 rausgebracht
(und ich freundlicherweise von debug messages befreit habe)



Der absturz bug beim timebase wechseln ist unabhängig von der
FPGA design version, also vorhanden auf 83e8 und 83e9 geräten.
Die zwei anderen bei den 83e9 geräten ind viel schlimmer und müssen
beseitigt werden.


Diese artifakten übrigens kommen von irgendeinen buffer overflow
(bild speicher alelrdings) man sieht es wunderbar mit älteren fw
die mit 2ns/div nicht abstürzen. Ich würde es als halb so wild
bezeichnen (wer bitte benutzte equ mode bei einem 1GSs gerät
der eh max 480MHz bandbreite hat?) schön ist es trotzdem nciht
und kommt auf HanTekway "to do liste".



Man mag sich fragen woher auf einmal diese fehler kommen, die
gabs vorhin nicht. Der grund ist die lange fehler liste, ein von
den fehlern der von anfang an war ist die unglücklich gewählen teiler,
mal 8:4:2, mal 8:2.5:1 usw. Die letzten firmware versionen haben komplet
überarbeitete timebase steuerung - und natürlich dadurch hier und da
irgendwelche überlauf fehler. Nicht schön, aber "notwendig" in den
zwischenversionen ... (ja ich weiss, ich beschütze die wieder mal).



Als workaround habe ein firmware patch erstellt, der verändert die rcS.
Sollte ein absturz passieren und die setup datei weggeschossen sein
(sprich DSO reagiert auf gar nix nach dem einschalten) muss man 
lediglich
USB stick reinstecken (mit einer datei reset.me - grösse/inhalte egal)
und den scope neu starten - und schon wird rcS diekaputte
/param/sav/run1kb_****** löschen und der scope mit default einstelungen
startet.

In der rcS werden lediglich ein paar zeilen hinzugefügt:

sleep 3
mount /dev/sda1 /mnt
sleep 1
if [ -f /mnt/reset.me ]; then
   rm -f /param/sav/run1kb*
fi
sleep 1
umount /mnt
sleep 1

also nix wildes. Leider ist der usb agent wenig inteligent, ein usb
stick wird zwar direkt beim boot erkannt aber nicht gemoutet
obwohl der autoagent es machen sollte. Ist wurscht, manueles mount in
der rcS geht auch (mit etwas sleep). Habe mehrere male das ganze 
versucht,
mit 4 usb sticks, es hat immer funktioniert, sollte also bei den meisten
von euch auch laufen.

Um den patch aktivieren bitte die datei setfix.zip aus dem anhang auf
leeres usb stick kopieren, stick ins DSO und firmware update starten.
Nach dem update ist alles bereit. Ich weiss man kann das etwas
inteligenter lösen,z.b. tastenabfrage beim booten - falls taste
gedruckt /param/sav/run1kb* wird gelöscht aber ehrlich gesagt sollte
das nciht unsere sondern HanTekway/Conrad aufgabe sein.

Sollten die irgendwann auch verstaden haben das defualt button beim
booten sinvoll ist und eine lösung implementiert haben im form
von was auch immer (extra app im rcS, oder direkt die ersten init zeilen
im dso.exe) kann man den fw patch wieder deinstallieren.

Dafür einfach die unfix.zip entpacken auf ein leeres usb stick, stick
ins DSO und wieder mal firmware update starten. Damit wird die org. rcS
wiederhergestellt.

von Christoph B. (christoph_b)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas

Ist es sinnvoll die setfix Datei profilaktisch auf dem Scope 
auszuführen?? oder gibt es keinen Grund dafür.

Habe momentan die Firmware 111124.0 am laufen.

von Mike (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

Laut Beschreibung ist es nötig wenn du eine HW-Revision e9 und die 
aktuelle FW besetzt, da dies der einfachste Weg ist das Oszi zu reseten 
solltest du es mit oben genante prozedzuren geschrottet haben.


Hast du die runlkb erstmal wie oben Beschrieben zersört hilft dir dieses 
Update nichts mehr da du es wohl nicht mehr einspielen kannst.

lg Michael

von Christoph B. (christoph_b)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe HW Version e8. Das Oszi läuft auch bis jetzt problemlos.
Selten mal hängt es sich auf.

von Pustekuchen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christoph B. schrieb:
> Ist es sinnvoll die setfix Datei profilaktisch auf dem Scope
> auszuführen?? oder gibt es keinen Grund dafür.

Bei mir läuft noch die org. Firmware; testweise hatte ich es hiermit 
abgeschossen:
> Vorgang: Time Base auf 80 ms und Trigger auf 'Auto' für den 'Scroll/Roll
> Mode'. Dann bei 'Acquire' die 'Mem Depth' von 4K auf 40K setzen, und aus
> is'.

Nach Reparatur per UART und Einspielen von 'setfix', konnte ich das 
Scope abschiessen aber allein mit Aus-/Einschalten ohne 'reset.me' 
wieder aufwecken.
Auch mit 200ms und 4K -> 40K bleibt es hängen und AUS-EIN weckt es 
wieder auf.

Daher lieber 'setfix' rechtzeitig einspielen, als im Fall des Falles 
wieder einen Rechner anzustöpseln. Meine Meinung.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

seit dem 'setfix' geht es bei mir auch ohne 'reset-me'-Datei. Gerade 
nochmals einen Absturz provoziert, aus/einschalten ohne USB-Stick 
genügt.

Auf der Konsole sind das die letzten Zeilen beim Absturz:
...
...
init_hardware_io......arrow position is (0)
FPGA acq counter acq=508 delay=0 armed=524
arrow position is (0)
IsPauseDispWave..
out-IsPauseDispWave..
dispmult-used=1
acqmult -used=1
clr auto acq mult ok
throw wave
out do TB key
Killed

Please press Enter to activate this console.
-

Firmware: 2.06.3 (120112.1)
Hardware: 10070x555583e9

Peter

von Christoph B. (christoph_b)


Bewertung
0 lesenswert
nicht lesenswert
ihr habt einfach das setfix File auf den USB Stick kopiert und dann das 
Firmware update ausgeführt. Richtig?

Bekomme meinen UART Adapter erst in ca 3 Wochen.

Kann jemand vieleicht ein Bild posten wie man den UART Adapter 
anschließen muss?

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph B. schrieb:
> Ich habe HW Version e8. Das Oszi läuft auch bis jetzt problemlos.
> Selten mal hängt es sich auf.

> Habe momentan die Firmware 111124.0 am laufen.

> Bekomme meinen UART Adapter erst in ca 3 Wochen


da du keine UART möglichkeit hast ist das letzte was ich fragen würde
zur testen ob deine firmware auch so böse abstürzt dass die
/param/sav/run1kb* kaputt geht.

Soweit ich weiss nicht, aber das muss nix bedeuten. Theoretisch
ist setfix nicht irgendwas wildes und kann im prinzip auf jedem DSO
installiert sein, bei deiner firmware als firmware updated beim
viel äleren manuel im form von geändertem linux startup script.

Dieses fix wird auch nicht für immer sein, es kommt eine zusätzliche
binary datei die wärend des bootvorgands die "Default Taste" abfragen
wird (entweder von Hantek oder mir).

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Christoph B.,

> Kann jemand vieleicht ein Bild posten wie man den UART Adapter
> anschließen muss?

UART-Beschreibung ist fast ganz oben , hier auf Seite 3 für HW1007:
Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

oder EEVblog erster Thread unten:
Hantek - Tekway - DSO hack - get 200MHz bw for free
http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/

Peter

von Pustekuchen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christoph B. schrieb:
> ihr habt einfach das setfix File auf den USB Stick kopiert und dann das
> Firmware update ausgeführt. Richtig?

Ja, das ist simpel und schadet nicht.

Peter Dreisiebner schrieb:
> seit dem 'setfix' geht es bei mir auch ohne 'reset-me'-Datei. Gerade
> nochmals einen Absturz provoziert, aus/einschalten ohne USB-Stick
> genügt.

Gut zu hören.

von Pustekuchen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christoph B. schrieb:
> Bekomme meinen UART Adapter erst in ca 3 Wochen.

Testweise habe ich einen MAX232N von TI mit 0,47µF Kondensatoren an 3,3V 
betrieben. Der funktioniert auch mit 115kBd und wäre eine einfache 
Lösung für DIESE Anwendung. Wichtig ist, dass die Ladungspumpe 
'anspringt'.
O.T. sagt Dir Haus Kannen etwas?

von Christoph B. (christoph_b)


Bewertung
0 lesenswert
nicht lesenswert
kann man eigentlich die Kabel für den UART an dem UART Port angesteckt 
lassen und nach ausen führen? oder gibt das irgendwelche Probleme.

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christoph B.,

> kann man eigentlich die Kabel für den UART an dem UART Port angesteckt
> lassen und nach ausen führen? oder gibt das irgendwelche Probleme.

ich habe eine Leitung aus einem alten CD-Player verwendet und nach außen 
geführt. Sind ~ 25 cm, dann noch ein 5 cm normales Flachbandkabel als 
Verbindung zum UART-USB-Adapter. Probleme habe ich damit nicht bemerkt.

Peter

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
neue fw version für Hantek/Tekway ist hier:

Beitrag "Re: VOLTCRAFT DSO-3062C 60 MHz = baugleich mit?"

von Nils S. (kruemeltee) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Dreisiebner schrieb:
> Sind ~ 25 cm, dann noch ein 5 cm normales Flachbandkabel als
> Verbindung zum UART-USB-Adapter. Probleme habe ich damit nicht bemerkt.

Ich hatte mit sowas auch nie Probleme, aber der Prozessor in der Kiste 
ist doch der s3c2440, oder?
Der hat anscheinend Probleme mit zu langen Leitungen. Aber wie gesagt, 
bei mir noch nicht, an 4 Boards mit s3c2440 drauf.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ja es ist s3c2440 und der mag auch keine alnge leitungen, anscheinend
funktioniert es bei manchen.
Das problem wird hier auch der bootloader sein, sobald der was im buffer
sieht beim booten wird er im vivi menu (bootloader) stoppen

von Tim R. (mugen)


Bewertung
0 lesenswert
nicht lesenswert
Auf der Hantek-Webseite gibt es die neue Firmware 
dst1kb_2.06.3_15102b_fact(120224.0).up

Der Ebay-Händler war so nett und hat mich darauf aufmerksam gemacht, 
bzw. diesen Link zugeschickt:

http://www.rigoloszilloskop.de/info/DSO5102B-firmware-update-38.html

Handelt sich anscheinend um die selbe Datei.

von Alois N. (alois)


Bewertung
0 lesenswert
nicht lesenswert
Kann man am Hantek DSO5102B die LAN Funktionalität nachrüsten?

Ich habe irgendwo gelesen das dies nur bei älteren Geräten HW0 über eine 
LAN-Addon Karte mit CS8900A-Ethernet-Chip geht.

Gibt es auch eine Lösung für neuere Modelle?

Und was kann man über LAN mit dem Gerät anstellen?

Gruss Alois ;)

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Alois Neumann schrieb:
> Kann man am Hantek DSO5102B die LAN Funktionalität nachrüsten?
>
> Ich habe irgendwo gelesen das dies nur bei älteren Geräten HW0 über eine
> LAN-Addon Karte mit CS8900A-Ethernet-Chip geht.
>
> Gibt es auch eine Lösung für neuere Modelle?

hw1005 und hw1007 noch nciht, bin leider z.zt. etwas
knapp mit zeit.

>
> Und was kann man über LAN mit dem Gerät anstellen?
>

z.zt. wäre es genau so wie bei den hw0 nur zugriff
auf die shell/ftp möglich und keine direkte steuerung
der firmare.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Alois Neumann schrieb:
> Kann man am Hantek DSO5102B die LAN Funktionalität nachrüsten?
>
> Ich habe irgendwo gelesen das dies nur bei älteren Geräten HW0 über eine
> LAN-Addon Karte mit CS8900A-Ethernet-Chip geht.
>
> Gibt es auch eine Lösung für neuere Modelle?
>
> Und was kann man über LAN mit dem Gerät anstellen?
>

hab ja ganz vergesen, WiFi geht auch

http://www.eevblog.com/forum/index.php?topic=1571.msg83370#msg83370

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

von Alois N. (alois)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
freu, das wäre toll wenn es versuchen könntest :)

Dieser mini programmer kann laut beschreibung mit MAX II CPLDs umgehen.
Ich denke Du hast auch irgendeine treiber (mit firmware) dafür bekommen 
damit es erkannt wird als Altera USB Blaster.

Danach braucht man Quartus II oder den Standalone Programmer

https://www.altera.com/support/software/download/programming/quartus2/dnl-quartus2_programmer.jsp

Falls Du diese sachen hast und der programmer (integrierter oder 
standalone) den Cable erkennt dann wird alles einfach.

DSO aufschrauben

Programmer an den CPLD JTAG port anschliessen - das ist die 10pin 2.54mm 
pitch header zwischen dem Q. oszillator und der unbestückten LAN buchse.

DSO einschalten und im programmer den cable auswählen, jtag chain 
scannen

Falls der MAX II erkannt wird nur das "examine" selektieren und "start" 
klicken

Falls das ging auf "Save file" button clicken und schon hast Du den dump
erstellt.

Ob der geht kann ich dann prüfen, für alles anderen modele habe schon 
die dumps hier.

von Alois N. (alois)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der JTAG-Pfostenstecker ist bei der hw1007 nicht bestückt.

Wie ist die Pin-Belegung des 10Pin-Headers damit ich beim anschliessen
des "Mini Usb Blaster Cable For CPLD FPGA NIOS JTAG Altera Programmer"
nichts falsch mache.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
die belegung ist standard, einfach eine stiftleiste in die löscher 
stecken, den flachband kabel anschliessen auf die stiftleiste stecken
(pin 1 ist auch auf der pcb markiert) und natürlich in den programmer.

Die stiftleiste brauchst du nicht zu löten, einfach etwas zeitlich zu 
der PCB drucken und dann jtag scan + auslesen (dauert 5 sekunden).

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
da ich gerade am dokumentieren bin was die jeweilige firmware an sysdata 
(das ist ein 200+ byte langes block mit allen DSO einstellugnen 
read-write natürlich) macht ist mir aufgefalles das Hantek haufen 
idioten sind.

Die Tekway DSOs mit fw 2.03 benutzen das selbe proticol.inf was auch 
heutige Hantek/Tekway/Voltcraft DSOs mit 2.06.3 benutzen.

Allerdings DSOs (Tekway und Hantek) aus der zeit wo Hantek sich gerade 
reingekauft hat beim Tekway, also mit fw 2.05.0 bis 2.06.2 benutzen eine 
ganz andere protocol.inf.

Im prinzip könnte man sagen "halb so schlimm" da die PC software die 
datei einliesst und dementsprechend agiert - das hat sich wohl auch 
Hantek gedacht. Nur leider ist das nicht so, leider ist das was die 
protocol.inf beschreibt das was die dso.exe (also die DSO applikation 
auf dem DSO selber) macht.

Die alten Tekway firmwares beinhalten immer schön brav die protocol.inf 
(passend zu jeweiligen dso.exe), die neueren firmware updates beinhalten 
nix. Das bedeutet es wird benutzen geben die 2.05.0 bis 2.06.2 gekauft 
haben, die firmware irgendwann auf 2.06.3xx upgedated haben aber nie die 
protocol.inf (passend zu 2.06.3) mitinstaliert haben da Hantek 
anscheinend davon ausgeht das niemand mehr "alte" DSO noch benutzt.

Die unterschiede in den protocol.inf versionen sind gross genug um die 
PC software teilweise unbrauchbar zu machen (reiehnfolge von 
einstellungen anders, auch grösse von datenfeldern anders!!).

Ich werde mal später ein update erstellen der die aktuelle protocol.inf 
installiert.

von Hannes J. (Firma: professional Professional) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> ist mir aufgefalles das Hantek haufen
> idioten sind.

Ach?

Die letzten 40, 50 Jahre Methodik in der Softwareentwickung sind an 
Hantek spurlos vorbei gegangen. Aber im Studium haben sie alle zwei 
Bücher von Großen Vorsitzenden gelesen.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hannes Jaeger schrieb:
> Thomas R. schrieb:
>> ist mir aufgefalles das Hantek haufen
>> idioten sind.
>
> Ach?
>
> Die letzten 40, 50 Jahre Methodik in der Softwareentwickung sind an
> Hantek spurlos vorbei gegangen. Aber im Studium haben sie alle zwei
> Bücher von Großen Vorsitzenden gelesen.

Einerseits haben die einige sachen nett/gut gelöst - beispiel die 
protocol.inf -> kopiert man eine eigene protocol.inf die z.b. nur 5 
zeilen (werte) sendet/empfängt stellt sich die ganze firmware daruf hin 
und tut dies auch ohne absturz. Kopiert man sachen die nicht 
implementiert sind (wie DMM auf dem Bench) ignoriert die firmware es 
(bzw. sendet 00 und reagiert nicht auf die werte die man sendet in den 
unbekannten feldern).

Andererseits ist die PC software mittlerweile hardgecoded und prüft die
ges.länge/werte der protocol.inf (wozu???), bereiningt man die fehler in
der protocol.inf wird das model nicht erkannt und die PC software geht
nicht mehr.

Eine eigene software und dso firmware laufen aber ohne ärger.
Die frage warum hardgecoded und vor allem warum so kann man sehr schnell 
beantworten - die modelbezeichnug felder kennen nur die Tekway geräte :

0:  DST1202B
1:  DST1100
2:  DST4060
3:  DST1150
4:  DST4042
5:  DST1102B
6:  DST4062B
7:  DST1152
8:  DST3022B
9:  DST3042B
10: DST4062
11: DST4102B
12: DST1062B

von Hantek wissen die nix und Hantek hat sich keine mühe gemacht es zu 
implementieren. Man könnte sagen "nciht weiter schlimm", ist es aber da 
man gar nicht unterscheiden kann ob es gerade ein Handheld (der sich 
weiterhin dumm als Tekway z.b. DST1062B meldet) oder ein Bench Voltcraft 
(auch Tekway DST1062B) oder ein Hantek DSO5062BMV (immer noch Tekway 
DST1062B). Handheld hat aber anderes display auflösung/andere 
funktionen, BMV hat mehr speicher (wird aber auch nciht erkannt) usw. 
usw. usw.
Und wehe wenn man handheld und bench software auf den selber PC hat :)

Mittlerweile weiss ich das man an daten die das model identifizieren
können durchaus auslesen kann - debug protokol 0x2 code (DSO Firmware
Variablen auslesen) zeigt die. Das wird aber Hantek nciht wissen.


Die protocol.inf hat einige fehler :
- falsche gesammt protokol länge, zeigt 208 sind aber 216Byte
  (nur auf den handhelds)

- falsche byte länge im feld [TRIG-SWAP-CH1-PULSE-TIME],
  steht 1 sollte 8 sein (alle bench modele mit fw 2.06.3)

- beim alt trigger werden für ch1 und ch2 die slope trigger daten
  gesendet/empfangen (alle modele) :
  [TRIG-SWAP-CH2-SLOPE-SET]  1
  [TRIG-SWAP-CH2-SLOPE-WIN]  1
  [TRIG-SWAP-CH2-SLOPE-WHEN] 1
  [TRIG-SWAP-CH2-SLOPE-V1]   2
  [TRIG-SWAP-CH2-SLOPE-V2]   2
  [TRIG-SWAP-CH2-SLOPE-TIME] 8
  [TRIG-SWAP-CH1-SLOPE-SET]  1
  [TRIG-SWAP-CH1-SLOPE-WIN]  1
  [TRIG-SWAP-CH1-SLOPE-WHEN] 1
  [TRIG-SWAP-CH1-SLOPE-V1]   2
  [TRIG-SWAP-CH1-SLOPE-V2]   2
  [TRIG-SWAP-CH1-SLOPE-TIME] 8
  die firmware kennt sowas nicht (bzw ich sehen kein slope im
  alt trigger submenu/auswahl)

- beim alt trigger werden keine O.T. trigger für ch1/ch2
  gesendet/empfangen (alle modele):
  [TRIG-SWAP-CH1-OVERTIME-NEG] 1
  [TRIG-SWAP-CH1-OVERTIME-TIME] 8
  [TRIG-SWAP-CH1-VPOS]       2
  [TRIG-SWAP-CH2-OVERTIME-NEG] 1
  [TRIG-SWAP-CH2-OVERTIME-TIME] 8
  [TRIG-SWAP-CH2-VPOS]       2
  die firmware hat aber genau den trigger typ im trigger alt submenu

- der single/dual window status wird nciht gesendet/empfange
  [CONTROL-MUL-WIN]          1
  obwohl die firmware es kann und versteht (alle modele).

Alle diese fehler sind leicht zu beseitigen, danach geht aber die PC 
software nicht mehr :)

Ich glaube ich werde doch kein patch mit protocol.inf erstellen, soll
doch Hantek es machen.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

> - falsche byte länge im feld [TRIG-SWAP-CH1-PULSE-TIME],
>   steht 1 sollte 8 sein (alle bench modele mit fw 2.06.3)

woher kommen die DSO-Einstellungen wenn man sie per Kommando 0x01 liest. 
Die Größe ist nämlich auch 208 Bytes, sowie in der protocol.inf 
angegeben. Da kann ja nicht nur die protocol.inf falsch sein oder passen 
sich die DSO-Einstellungen wirklich so flexibel an? Dann kann der 
Parameter [TRIG-SWAP-CH1-PULSE-TIME] nie richtig gelesen und gespeichert 
werden bei nur einem Byte.

Peter

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Dreisiebner schrieb:
> Hallo Thomas,
>
>> - falsche byte länge im feld [TRIG-SWAP-CH1-PULSE-TIME],
>>   steht 1 sollte 8 sein (alle bench modele mit fw 2.06.3)
>
> woher kommen die DSO-Einstellungen wenn man sie per Kommando 0x01 liest.
> Die Größe ist nämlich auch 208 Bytes, sowie in der protocol.inf
> angegeben. Da kann ja nicht nur die protocol.inf falsch sein oder passen
> sich die DSO-Einstellungen wirklich so flexibel an?

Die firmware selber arbeitet auch ohne protocol.inf, ich hatte
am anfang auch keine und hatte keine probleme gehabt (ich finde keine
in meinem ersten fw dump, in späteren schon  - auch in fw updates, d.h. 
ich habe die selber irgendwann installiert ohne es zu merken das die 
wichtig ist).

Die firmware weisst auch was für grösse einzelne datenfelder haben und 
welche reihenfolge - diese sachen sind auch hardgecoded.
Was aber übertragen wird zum PC wird anhand der protocol.inf 
festgestellt,
fehlt da etwas oder ist falsch definiert bekommt PC nur unsinn.

Du kannst z.b. die protokol.inf umbenennen und wirst schon sehen, nix 
passiert (ausser das PC software nciht geht weil die ohne diese inf 
denke das das DSO nciht vorhanden ist).

Du kannst ja auch gerne eine zeile hinzufügen (vor dem [END] :

[CONTROL-MUL-WIN] 1

und natürlich die grösse in der inf anpassen. Nach dem dso.exe neu 
gestartet wird sendet dein DSO auf 0x01 1 byte mehr -> den Single/Dual
window status. Das macht mein handheld z.b., bench noch nciht getestet,
wird aber nciht anders sein (oder doch? hehe).


> Dann kann der
> Parameter [TRIG-SWAP-CH1-PULSE-TIME] nie richtig gelesen und gespeichert
> werden bei nur einem Byte.
>

zu kurz ist nicht schlimm, abgesehen davon muss die software es auch
können. Z.zt. kann man zwar auf alt umschalten aber keine enstellugnen
machen, was natürlich sehr sinlos ist. Sowas kann also nciht mal QC 
merken (nicht das die eine haben heh) da es gar nicht zu prüfen ist.

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier ein screenshot, meine protocol.inf ist abgekürzt,
alles was drin ist sind ch1 daten und multifenster status.

Mein DSO überträgt jetzt nur:

53 0D 00 81 01 06 00 00 00 01 00 00 00 00 00 E9

bzw. dies wenn dual window eingeschaltet ist:

53 0D 00 81 01 06 00 00 00 01 00 00 00 00 01 EA


Die PC software merkt natürlich das dual window eingeschaltet ist
und meckert wenn ich z.b. auf ALT trigger umstellen möchte.

Wenn ich jetzt z.b. mit PC software die timebase ändern will sendet
die nur

53 0D 00 11 01 06 00 00 00 01 00 00 00 00 01 7A

was auch logisch ist - die timebase felder gibt gar nicht in
meiner protocol.inf

------------

Nächster versuch, protocol.inf hat jetzt nur ch1 und timebase
einstellungen, DSO sendet jetzt nur

53 0E 00 81 01 06 00 00 00 01 00 00 00 00 06 06 F6

oder dies wenn cih timebase verkleinere:

53 0E 00 81 01 06 00 00 00 01 00 00 00 00 07 07 F8

Was macht die PC software? Akzeptiert alt trigger auch im dual
window, kalr sie weisst nix davon das dual eingeschaltet ist (0x1)
auch weisst die nix von multiwindow.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

> Du kannst ja auch gerne eine zeile hinzufügen (vor dem [END] :
>
> [CONTROL-MUL-WIN] 1
>
> und natürlich die grösse in der inf anpassen. Nach dem dso.exe neu
> gestartet wird sendet dein DSO auf 0x01 1 byte mehr -> den Single/Dual
> window status. Das macht mein handheld z.b., bench noch nciht getestet,
> wird aber nciht anders sein (oder doch? hehe).

ja, ein- ausschalten funktioniert. Mit meinem DSO-Tool kann ich die 
Einstellungen schon komplett flexibel manipulieren. Die Oberfläche dazu 
fehlt noch.

Peter

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Dreisiebner schrieb:
> Hallo Thomas,
>
>> Du kannst ja auch gerne eine zeile hinzufügen (vor dem [END] :
>>
>> [CONTROL-MUL-WIN] 1
>>
>> und natürlich die grösse in der inf anpassen. Nach dem dso.exe neu
>> gestartet wird sendet dein DSO auf 0x01 1 byte mehr -> den Single/Dual
>> window status. Das macht mein handheld z.b., bench noch nciht getestet,
>> wird aber nciht anders sein (oder doch? hehe).
>
> ja, ein- auschalten funktioniert. Mit meinem DSO-Tool kann ich die
> Einstellungen schon komplett flexibel manipulieren. Die Oberfläche dazu
> fehlt noch.
>
> Peter

ehm, ich helfe dir etwas dabei, schicke dir ein paar infos zu den 
einstellungen. Wie gesagt, ich bin mit diesen 200+bytes schon fertig,
das ganze zu formatieren damit es gut sichtbar wird ist horror :)

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

wenn man die Einstellungen am DSO speichert und wieder aufruft, wird das 
Bedienfeld aktualisert. Bei der TTScope-Software wir das Bedienfeld 
nicht aktualisiert. Gibt es vielleicht ein Kommando dazu? Bei der 
Protokoll-Seite hast du '0x7F Init DSO' beschrieben, aber das klingt ein 
bisserl 'oversized'.

Die DSO-Einstellungen zum Lesen, Ändern und Schreiben habe ich soweit 
fertig:
http://www.dreisiebner.at/dso-usb-tool/
Eine Beschreibung ist natürlich super, da die Werte ja teilweise 
umgerechnet werden müssen denke ich. z.B.: Pixel in Volt oder so?

Peter

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Dreisiebner schrieb:
> Hallo Thomas,
>
> wenn man die Einstellungen am DSO speichert und wieder aufruft, wird das
> Bedienfeld aktualisert.

ja, liegt daran das die firmware einen init macht nach einstllung lesen.

> Bei der TTScope-Software wir das Bedienfeld
> nicht aktualisiert.

richtig, weil dies auch ohne init eingelesen werden kann

> Gibt es vielleicht ein Kommando dazu? Bei der
> Protokoll-Seite hast du '0x7F Init DSO' beschrieben, aber das klingt ein
> bisserl 'oversized'.

direkt nicht, indirekt wenn man die firmware patched schon.
Die 0x07F kann aber auch benutzt werden.

>
> Die DSO-Einstellungen zum Lesen, Ändern und Schreiben habe ich soweit
> fertig:
> http://www.dreisiebner.at/dso-usb-tool/

ich mag das tool! Schade nur das es nicht mit handeld läuft,
evt. biege ich es entsprechend um - wenn ich mal das RealStudio
verstanden habe (shell geht, screenshot nicht wegen auflösung - klar, 
read file geht aber read settings nicht was wenig sinn mach)

> Eine Beschreibung ist natürlich super

hast email bekommen

> , da die Werte ja teilweise
> umgerechnet werden müssen denke ich. z.B.: Pixel in Volt oder so?
>

fast :)

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

>> Bei der TTScope-Software wir das Bedienfeld
>> nicht aktualisiert.
>
> richtig, weil dies auch ohne init eingelesen werden kann

ich meinte beim Senden von TTScope zum DSO, dann wird das Bedienfeld 
auch nicht aktualisiert.

> direkt nicht, indirekt wenn man die firmware patched schon.
> Die 0x07F kann aber auch benutzt werden.

werde ich mal probieren.

> ich mag das tool! Schade nur das es nicht mit handeld läuft,
> evt. biege ich es entsprechend um - wenn ich mal das RealStudio
> verstanden habe (shell geht, screenshot nicht wegen auflösung - klar,
> read file geht aber read settings nicht was wenig sinn mach)

Bildschirmkopie anpassen ist kein Problem, sind ein paar Konstanten. Die 
Handhelds kenne ich nicht, noch nie gesehen. Die Settings passen sich an 
die 'protocol.inf' an, oder sollten es tun, solange das Kommando gleich 
ist.

>> Eine Beschreibung ist natürlich super
>
> hast email bekommen
>
>> , da die Werte ja teilweise
>> umgerechnet werden müssen denke ich. z.B.: Pixel in Volt oder so?
>>
>
> fast :)

Ui, danke, dass schaut nach Arbeit aus!
Habe jetzt nur ein bisschen darin gelesen, das wird noch interessant.

Peter

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Dreisiebner schrieb:
>
> Bildschirmkopie anpassen ist kein Problem, sind ein paar Konstanten. Die
> Handhelds kenne ich nicht, noch nie gesehen. Die Settings passen sich an
> die 'protocol.inf' an, oder sollten es tun, solange das Kommando gleich
> ist.
>

die konstanten habe ich geändert, hat nciht geholfen.
Wird aber an meinen kenntnissen von RealStudio liegen.


Peter Dreisiebner schrieb:
>>> , da die Werte ja teilweise
>>> umgerechnet werden müssen denke ich. z.B.: Pixel in Volt oder so?
>>>
>>
>> fast :)
>
> Ui, danke, dass schaut nach Arbeit aus!
> Habe jetzt nur ein bisschen darin gelesen, das wird noch interessant.
>

sowas ist z.b. ein horror (wenn man sich nur die werte die übertragen 
werden anguckt, kennt man die formel geht sehr schnell):

DSO auf 4,96V/DIV (also fine mode), pos -1DIV, trigger slope V1
auf -0.5DIV und V2 auf +0.5DIV :)

Spannung: 5V - (5/75)
Position V1: (-0.5DIV - -1DIV) * ((5V-5/75)/25)
Position V1: (0.5DIV - -1DIV) * ((5V-5/75)/25)

Per sw kann man natürlich jetzt ganz krass direkt auf z.b.
1,98V/DIV umschalten, dann sind es 2V - (2/50) und nicht 2/75 :)

Die position muss dann natürlich auch neu berechnet auf der PC seite.

Bewegt man jetzt ch1 position muss natürlich trigger position neu 
berechnet da alle position angaben display koordinaten bezogen sind.
Ahja, und die koordinaten sind natürlich nicht einfach 800x480 sondern
+1000 bis -1000 (laut Hantek, nach meine observation nur +-500) in
vertikal und 800 +- X horizontal (details was X bedeutet in der doku).

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

>> Bildschirmkopie anpassen ist kein Problem, sind ein paar Konstanten. Die
>> Handhelds kenne ich nicht, noch nie gesehen. Die Settings passen sich an
>> die 'protocol.inf' an, oder sollten es tun, solange das Kommando gleich
>> ist.
>
> die konstanten habe ich geändert, hat nciht geholfen.
> Wird aber an meinen kenntnissen von RealStudio liegen.

eine neue Version steht bereit mit Option für 'Handheld' bei der 
Bildschirmkopie, ist aber ungetestet. Die Farbpalette ist auch noch die 
gleiche. Wenn bei einem Handheld-Gerät das Hakerl nicht gesetzt wird, 
dürfte keine Bildschirmkopie angezeigt werden.Bei normalen DSOs gibt es 
kaputte Bilder, ist aber Absicht.

@Frage an alle: Wie speichert man die Sample-Daten am Besten? Ich habe 
das Format MDF (Measurement Data Format) entdeckt, dürfte in der 
Automobil Industrie standard sein. Für die Version 3.3 habe ich 
Dokumentation gefunden, schaut nicht so schwierig aus. Ist das sinvoll?

Peter

von Johannes R. (johannes_r29)


Bewertung
0 lesenswert
nicht lesenswert
Mit was kommen Programme wie z.B. Matlab usw. klar?

Hameg hat bei seinen Oszilloskopen auch ein Plugin für Excel, da hatte 
man die Messwerte dann alle in ner Tabelle.

Wobei CSV auch ein nettes Format ist sofern die Daten richtig 
gespeichert werden - denn aus ner CSV kann man leicht über kleine 
Programme/Scripte andere Formate erzeugen.

MFG Johannes

von Mischmasch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter Dreisiebner schrieb:
> @Frage an alle: Wie speichert man die Sample-Daten am Besten? Ich habe
> das Format MDF (Measurement Data Format) entdeckt, dürfte in der
> Automobil Industrie standard sein. Für die Version 3.3 habe ich
> Dokumentation gefunden, schaut nicht so schwierig aus. Ist das sinvoll?

CSV, allerdings gibt das bei tiefem DSO-Speicher elend lange Dateien.

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.

von Mischmasch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Mischmasch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Blödsinn, das ist doch die 1x und 10x Probeeinstellung.
Sorry, ich bin zu dumm.

Peter

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von egonotto (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

 ich glaube, dass es sich nur um die Anzahl der auf dem Schirm 
angezeigten Punkte handelt.

MfG
egonotto

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Philipp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wozu gibt es bei den dingern platz für ein audio chip?

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Philipp schrieb:
> wozu gibt es bei den dingern platz für ein audio chip?

benutze suchfunktion

von Philipp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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"

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
vergiss es, da muss wohl ein mapping sein in der fw, ältere versionen 
liefern bei dem register komplett was anderes.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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ö

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von egonotto (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lukas P. (parsley)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Hannes J. (Firma: professional Professional) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
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>

von P. K. (dg4ek)


Bewertung
0 lesenswert
nicht lesenswert
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?

von kunze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Welches Equipment benutzt ihr für eure Untersuchungen/Mods?

von Hannes J. (Firma: professional Professional) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
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.

von P. K. (dg4ek)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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"

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas S. (doschi_)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert

von Lukas P. (parsley)


Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

von Lukas P. (parsley)


Bewertung
0 lesenswert
nicht lesenswert
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

von Lauren (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter Dreisiebner schrieb:
> ...RealStudio...

Wo liegt eigentlich der Vorteil so eine exotische IDE zu benutzen?
VisualStudio Express gibts doch kostenlos.

von Thomas S. (doschi_)


Bewertung
0 lesenswert
nicht lesenswert
Schaltplan vom Netzteil:
Ich habe EEVBlog, Artikel und die Threads hier durchsucht:
gibt es irgendwo ein Schaltplan vom Netzteil?

von Pascal H. (pase-h)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas S. (doschi_)


Bewertung
0 lesenswert
nicht lesenswert
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 ?

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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)

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von egonotto (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hannes J. (Firma: professional Professional) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
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.

von egonotto (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Hannes J. (Firma: professional Professional) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hannes,

hast du etwas Quellcode? Vielleicht kann ich mir was abschauen und komme 
so auf meine Fehler drauf.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
hehe, wir haben gleichzeitig gepostet
gut, teste ich sofort :)

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
meine ergebnisse beziehen sich auf xxxx08btest, teste später die 09

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Alois N. (alois)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Alois,

danke schön!

von Christoph B. (christoph_b)


Bewertung
0 lesenswert
nicht lesenswert
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

von Mischmasch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Christoph B. (christoph_b)


Bewertung
0 lesenswert
nicht lesenswert
muss er speziell gesetzt werden?

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Christoph B. (christoph_b)


Bewertung
0 lesenswert
nicht lesenswert
Habe das DSO schon neu gestartet. An dem liegt es nicht

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von egonotto (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

 die Triggerposition von Kanal 2 kann man mit V0 einstellen.

MfG
egonotto

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?"

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?"

von Owen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ahja, und hier gibts auch noch kopie von qq2440 dvd

http://203.81.29.13:7635/

und nocheinmal nur 2.6.13 root_fs.

von Michael D. (mike0815)


Bewertung
0 lesenswert
nicht lesenswert
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

von Lukas P. (parsley)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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)

von Random .. (thorstendb) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Fritz S. (team151)


Bewertung
0 lesenswert
nicht lesenswert
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

von P. K. (dg4ek)


Bewertung
0 lesenswert
nicht lesenswert
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

von yatko (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Michael D. (mike0815)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Johannes R. (johannes_r29)


Bewertung
0 lesenswert
nicht lesenswert
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

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

von Johannes R. (johannes_r29)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ü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.

von Hannes J. (Firma: professional Professional) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> Ich habe auch ein paar neuigkeiten zum thema firmware bugs,

Hantek hat ein paar Programmierer gefunden? :-)

von P. K. (dg4ek)


Bewertung
0 lesenswert
nicht lesenswert
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

von Johannes R. (johannes_r29)


Bewertung
0 lesenswert
nicht lesenswert
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

von P. K. (dg4ek)


Bewertung
0 lesenswert
nicht lesenswert
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 :))

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von P. K. (dg4ek)


Bewertung
0 lesenswert
nicht lesenswert
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

von Mischmasch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also die selben Leute, die seit Monaten nicht richtig weiter kommen, 
werden in den nächsten zwei Monaten alle Probleme lösen?

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Hannes J. (Firma: professional Professional) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Es könnte aber günstiger sein so eine PCB von Tekway zu kaufen als selber machen
Kann man die denn einzeln nachkaufen?

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Old P. (old-papa)


Bewertung
0 lesenswert
nicht lesenswert
Mooooment!
Neue harte Ware? Da bin ich doch gleich dabei ,-)

Gruß
Old-Papa

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
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').

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Mischmasch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert