TEKWAY DST1xx2B Oszilloskop

[Thomas R. (tinman)]

kannst machen, im schlimmsten fall bekommst du das selbe error.
Das meinte ich auch als ich geschrieben habe:

Thomas R. schrieb:
>
> Eigentlich nciht so schlimm für die die es sowieso hacken möchten,
> allerdings es kann passieren das jemand der es nciht hacken will
> auf einmal probleme hat passende firmware zu finden weil.

Die dst1kb_9.99.9_cli_111111.0_.up wird es unter umständen wegbügeln.

EDIT: nur eine up file darf auf dem stick sein, den letzten unterstrich
im dateinamen bitte wegmachen (also dst1kb_9.99.9_cli_111111.0.up)

[Alf S. (alfsch)]

jo....update....grüner balken läuft komplett durch....
dann kommt: error 0xF7 illegal upgrade files detected !
--- sowas aber auch :-(
wat nu ?

+ ein rechteck sieht mit den mitgelieferten tastköpfen etwa so aus, wie 
schon gezeigt: mit dem abgeflachten Anfang;
anbei Bild, 16.9Mhz mit 200Mhz-Tastkopf (2 Abgleich-Trimmer)

[Thomas R. (tinman)]

Alf Sch schrieb:
> jo....update....grüner balken läuft komplett durch....
> dann kommt: error 0xF7 illegal upgrade files detected !
> --- sowas aber auch :-(
> wat nu ?

habe dir eigentlich PM geschrieben, aber gut machen wir übers forum 
thread.
Das tool um firmware backup zu machen (siehe anhang) hat mehrere 
versionen.

Wenn du sagst das die universele version nicht geht muss eine andere
modellspezifische gehen. Zur auswahlt stehen:

DSO5062B
DSO5102B
DSO5202B
DST1062B
DST1102B
DST1202B
Universal

kopiere jeweils nur eine davon auf ein leeres usb stick, rein damit,
10sec abwarten, firmware update starten - wenn es nciht geht
die nächste versuchen.

Alle sind nonintrusiv, es bleiben keine hinweise in der firmware
dafür das du backup gemacht hast (was auch nciht verbotten ist)
Wenn eine davon geht dann notiere welche - dann kann ich dir ein
hack zusammenstellen der für die version geht.
Eigentlich sollte der universal hack gehen da er die Hantek-interne
routine benutzt um die model überprüfung umzugehen - die hat
Hantek implementiert um kein dircheinander bei den firmware versionen
zu haben. Bis 110806 fw version ging das, du hast 110808 also
kann es natürlich sein das da etwas neues drin ist.
Sollte also keine von den files funktionieren muss du dann
leider DSO öffnen und über UART (115200, 8n1) auf die linux shell
und manuel machen. Möchtest du nicht manuel benötige ich dann allerdings
die dso.exe die im root verzeichniss vom DSO sich befindet - um
die kopieren können einmal über UART auf die shell, mit strg+C laufendes
DSO process unterbrechen, usb stick rein - wird gemountet ins /mnt,
mit cp /dso.exe /mnt rüberkopieren, einmal sync und stick raus.
Wenn ich die habe kann dann reingucken was los ist und hier prüfen,
bzw den hack anpassen - das ist soweit kein problem.

UART is 3.3V, also entweder CP2102, FTDI oder max3232 converter nehmen.
Der eingebaute SoC mag keine lange kabeln für UART, die pin belegung
siehe anhang.

Wenn du aber doch manuel hacke willst, dann über UART einlogen,
mit strg+C laufendes DSO process killen, auf der shell folgende dateien 
editieren :

jeweils dst1102b (oder was auch imemr da drin steht) auf
dst1202b ändern

vi /sys.inf
vi /tmpdst
vi /logotype

hier DSO5102B auf DSO5202B ändern
vi /logotype.dis

und am ende noch
mv /dst1102b /dst1202b

Um zu testen ein DSO applikation starten mit /dso.exe,
wenn alles geht (sprich 2ns/div verfügbr ist und model stimmt)
DSO abschalten, UART trennen, zusammenbauen und beutzen ...


Wie auch immer du dich entscheidest würde gerne den dump
oder mindestens die dso.exe angucken/analysieren.

Ich vermutte das es bei dir falsche einträge sind deswegen stimmt
weder firmware update noch waveform verhalten.

Übrigens, wo hast du es gekauft?

[Alf S. (alfsch)]

hallo, man glaubts ja kaum....
habe alle DSO-dump files durchprobiert....immer error 0x7F ....
dann -zur Sicherheit- nen anderen USB stick versucht, mit dem 
"universal.."
-> es ging !   möchte das Teil den einen stick nicht !!!

dann das "...11111..." ging auch. nennt sich jetzt DSO5202 :-)

anbei screen, selbe messung wie vorher, selber tastkopf....
sieht noch etwas besser aus

bzgl dump....sende mir doch ne PM mit deiner email drin....dann sende 
ich dir den dump gerne. (hier als anhang...gehen 30MB wohl kaum)

gekauft....ibäh...lotusofchina2007....390 incl porto

[Thomas R. (tinman)]

Alf Sch schrieb:
> hallo, man glaubts ja kaum....
> habe alle DSO-dump files durchprobiert....immer error 0x7F ....
> dann -zur Sicherheit- nen anderen USB stick versucht, mit dem
> "universal.."
> -> es ging !   möchte das Teil den einen stick nicht !!!
>

eigentlich kaum zu glauben das manche sticks nicht gehen,
im prinzip der Linux 2.6.13 sollte nicht so viele probleme machen
aber ich kanns nur bestätigen - manche werden nicht erkannt.
Man kann auf der shell auch sehen, liegt am Linux.


>
> anbei screen, selbe messung wie vorher, selber tastkopf....
> sieht noch etwas besser aus
>
> bzgl dump....sende mir doch ne PM mit deiner email drin....dann sende
> ich dir den dump gerne. (hier als anhang...gehen 30MB wohl kaum)
>

oki, PM ist raus.

Ich spiele den dump bei mir auf, die 4ns rise time
sind eindeutig falsch, irgendwie denkt er immer noch das er DSO5062B 
ist.
Möglicherweise neue schutzmassnahme gegen hacks, was auch immer
es ist kann ich es definitiv beseitigen.

[Alf S. (alfsch)]

bzgl usb stick: nee, erkannt wurde er ja ! auch screen-save geht 
problemlos....deswegen kam ich ja nicht gleich drauf;
nen anderen stick hab ich dann nur probiert --- weil: man weiß ja nie 
....

und aufgeschraubt hab ichs trotzdem....
die Sirene schrie einfach nach dem 7805 :-)
 jetzt lüftet das praktisch lautlos ....perfekt.

[Thomas R. (tinman)]

Alf Sch schrieb:

> und aufgeschraubt hab ichs trotzdem....
> die Sirene schrie einfach nach dem 7805 :-)
> jetzt lüftet das praktisch lautlos ....perfekt.

und eigentlich so musste es sein, funktion vorhanden und trotzdem
keine störungen.

Übrigens, habe dir gerade eine email geschickt, dein dump ist seltsam
klein, da fhelt die hälfte von root.bin

Also entweder gibts da eine neue partition, oder der stick war zu
langsam und zu schnell rausgezogen, oder aber gibts ein problem
mit NAND speicher - ich schreibe das hier nochmal weil falls
es kein NAND oder usb stick fehler ist werden andere auch seltsam wenig
dumpen können. Habe ein neues dump tool zusammen gebaut um
das durchzuleuchten - aber erst mit deinem DSO.

Sollte der NAND kaputt sein kann ich es reparieren, passende NANDs
habe auch eine ganze tray hier.

[Thomas R. (tinman)]

Thomas R. schrieb:
> Falls jemand die werks-kalibrierung wiederherstellen (nach NAND flash
> crash oder versehentlichen löschen) oder starten möchte (nach z.b. einem
> hardware umbau), ich habe letztendlich rausgefunden wie die funktioniert
>
> Siehe:
>
> http://www.eevblog.com/forum/index.php?topic=1571.msg50043#msg50043

ich habe nochmal die werkskalibrierung unter die lupe genommen
und herausgefunden das man es noch genauer machen kann als
der hersteller es selber macht, siehe hier:

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

[P. K. (dg4ek)]

Hallo allerseits,

kennt jemand die 110808.0 fw Version?
Habe heute ein neues Hantek 5202B bekommen was diese Version drin hat,
funktioniert soweit alle ganz nett, bis auf die Helligkeitsregelung
des LCDs. Egal ob man Kontrast 0 oder 15 einstellt, immer volle
Helligkeit. Da ich noch ein anderes mit der 531er fw hier habe, habe
ich mal Netzteil und Display gegenseitig getauscht, daran liegt es 
nicht.
Jetzt hätte ich gern gewusst, ist es die fw Version oder ein 
Hardwarefehler
auf dem Board...?

Gruß
Peter

[Thomas R. (tinman)]

Peter Krengel schrieb:
> Hallo allerseits,
>
> kennt jemand die 110808.0 fw Version?
> Habe heute ein neues Hantek 5202B bekommen was diese Version drin hat,
> funktioniert soweit alle ganz nett, bis auf die Helligkeitsregelung
> des LCDs. Egal ob man Kontrast 0 oder 15 einstellt, immer volle
> Helligkeit. Da ich noch ein anderes mit der 531er fw hier habe, habe
> ich mal Netzteil und Display gegenseitig getauscht, daran liegt es
> nicht.
> Jetzt hätte ich gern gewusst, ist es die fw Version oder ein
> Hardwarefehler
> auf dem Board...?
>
> Gruß
> Peter

kein hardware fehler, alle fw revisionen vom 110728 bis
110808 haben den fehler - der LCD treiber versteht kein PWM mehr.

Es gibt neue firmware version auf antek website, der beseitig es.

Eine bug liste und informationen zu neuerung in der letzten firmware
findest du hier

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

Ich habe auch zwei bugs selber beseitigt, die geänderte firmware
ist hier

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

[P. K. (dg4ek)]

Hallo,
kann mir jemand sagen welchen USB Treiber ich für TTScope einsetzen 
muss?
Sowohl bei XP als auch bei Win7 bekomme ich immer die Meldung dass
kein Treiber vorhanden ist.

Herzlichen Dank für eure Hilfe
Peter

[Johannes R. (johannes_r29)]

http://pastebin.com/XJvyjerm

Das erste ist der Treiber, das zweite die Software.

Muss es über Pastebin verlinken da China Links gesperrt sind.

MFG Johannes

[P. K. (dg4ek)]

Ja prima, danke

Treiber hat er nun aber ich sehe nichts vom Osci auf dem Schirm :(

TTscope zeigt nichts

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Peter Krengel schrieb:
> TTscope zeigt nichts

Die Software ist ein ziemlicher Müll, Nichts funktioniert so richtig.

Zuerst gilt es im Menü, alternativ der Toolbar, den Menüpunkt zu finden, 
der den PC mit dem Oszilloskop verbindet. Sonst geht gar nichts.

Dann gibt es in der Toolbar, ganz links, als "Neues Dokument" Icon 
getarnt, eine Auswahlliste von mehr oder weniger sinnvollen 
Möglichkeiten zur Darstellung von Daten.

Chinesischer Logik entsprechend sind einzelnen Operationen und 
Einstellungen im Baum auf der linken Seite versteckt, die alle so 
aussehen wie Hyperlinks. Die Auswahl der Einstellungen ist so unbequem 
wie nur irgend möglich gemacht. Einige Einstellungen ("Data") 
funktionieren bei mir gar nichts. Als letzter Eintrag im Baum gibt es 
den Punkt Panel. Dahinter verbirgt sich eine hässliche 
Oszilloskop-Darstellung und -Fernsteuerung.

Mein Fazit: Für mich unbrauchbar. Von der Benutzung wird man doof.

Da es kein SDK gibt, habe ich das USB-Protokoll mitgeschnitten und mir 
für ein paar Sachen was Eigenes gebaut. Damit komme ich über die Runden 
aber das Hantek wird sicher nicht mein Brot-und-Butter Oszilloskop 
werden. Dafür ist es zu schlecht. Man merkt sehr schnell, das das 
Oszilloskop ein Billigprodukt ist.

[Thomas R. (tinman)]

Hannes Jaeger schrieb:>
> Die Software ist ein ziemlicher Müll,

nein, standard china software

> Nichts funktioniert so richtig.

was meinst du mit richtig^^

> Zuerst gilt es im Menü, alternativ der Toolbar, den Menüpunkt zu finden,
> der den PC mit dem Oszilloskop verbindet. Sonst geht gar nichts.

logisch muss man erst verbinden, bei der USB software fragt man
sich zwar wozu, bei der LAN software ergibt das schon sinn

>
> Dann gibt es in der Toolbar, ganz links, als "Neues Dokument" Icon
> getarnt, eine Auswahlliste von mehr oder weniger sinnvollen
> Möglichkeiten zur Darstellung von Daten.
>
> Chinesischer Logik entsprechend sind einzelnen Operationen und
> Einstellungen im Baum auf der linken Seite versteckt, die alle so
> aussehen wie Hyperlinks. Die Auswahl der Einstellungen ist so unbequem
> wie nur irgend möglich gemacht. Einige Einstellungen ("Data")
> funktionieren bei mir gar nichts.

richtig, alle funktionen sind zwar irgendwie da, man wird aber
leicht wahsinnig bei der bedienung, manchmal schwer zu sagen
was wozu da ist. Die hilfe ist nicht vorhanden, das erschwert
noch zusätzlich.

Man muss dazu sagen die software ist eigentlich eine abgespeckte
version von der vorgängermodel software, die hat zwar auch so besch**
ausgesehen, dafür gingen die funktionen sehr gut.
Warum bis heute kaum was geändert worden ist steht in den sternen.
Hantek hat neue handhelds, deren software ist minimal verbessert und
unterstüzt auch LAN verbindung.


Als letzter Eintrag im Baum gibt es
> den Punkt Panel. Dahinter verbirgt sich eine hässliche
> Oszilloskop-Darstellung und -Fernsteuerung.

Virtual Panel ist unbrauchbar, die fw sendet screenshots an PC
- viel zu langsam.

Abgesehen davon sind die entwickler einfach nur krank, warum die
resource datei das bild verkleinert darstellt ist ein rätsel,
geschwindigkeit kann es nciht sein, mein 5 jahre alte
notebook kann genau so schnell auch 800x480 bilder darstellen.

>
> Mein Fazit: Für mich unbrauchbar. Von der Benutzung wird man doof.
>

dito

> Da es kein SDK gibt, habe ich das USB-Protokoll mitgeschnitten und mir
> für ein paar Sachen was Eigenes gebaut. Damit komme ich über die Runden
> aber das Hantek wird sicher nicht mein Brot-und-Butter Oszilloskop
> werden.

oh wie nett, kannst es zeigen wie du es gemacht hast?

> Dafür ist es zu schlecht. Man merkt sehr schnell, das das
> Oszilloskop ein Billigprodukt ist.

naja, scope selber ist nciht schlecht, die software allerdings
wirklich billig. So ganz am rande, Hantek hat mal einen moment
nciht aufgepasst und falsche sw/driver auf deren seite gehabt,
die hatten auch kein Hantek copyright mehr gehabt sondern Extech.
Möglicherweise wird also Extech die neuen handhelds als "eigene" 
vermarkten, bleibt nur hoffen das dadurch die pc software
verbessert wird.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Thomas R. schrieb:
> Hannes Jaeger schrieb:>
>> Da es kein SDK gibt, habe ich das USB-Protokoll mitgeschnitten und mir
>> für ein paar Sachen was Eigenes gebaut. Damit komme ich über die Runden
>> aber das Hantek wird sicher nicht mein Brot-und-Butter Oszilloskop
>> werden.
>
> oh wie nett, kannst es zeigen wie du es gemacht hast?
>

Ganz klassisch. Eine Virtual Machine mit Windows in dem TTScope lief. 
Dann in der VM TTScope-Knöpfe gedrückt und gemütlich auf der 
USB-Schnittstelle des Host-Systems die USB-Daten mitgeloggt.

Das Protokoll ist ziemlich einfach. Es werden USB Bulk-Transfers 
verwendet. Die Nachrichten sind in beide Richtungen gleich aufgebaut.

Jede Nachricht beginnt mit einem 0x53 (ASCII 'S', für "Start"?).

Dann zwei Längenbytes (Little Endian), die die Länge des Rests der 
Nachricht (Gesamtlänge - 3) angeben.

Dann ein Byte, das den Typ der Nachricht beschreibt. Werte < 0x80 sind 
Anforderungen vom PC an das Oszilloskop, Werte >= 0x80 Antworten von 
Oszilloskop an den PC. Der Antworttyp entspricht dem Anforderungstyp, 
nur dass das MSBit im Byte zusätzlich gesetzt ist.

Optional folgt dem Typ-Byte in manchen Nachrichten ein Subtyp-Byte 
(besonders in Antworten).

Dann folgen die Daten.

Den Abschluss bildet eine primitive Checksumme. Das ist wirkliche eine 
Summe, nicht eine CRC. Einfach alle Bytes, angefangen mit dem 0x53 
addieren und das LSByte ist die Checksumme. Schlechter kann man eine 
Checksumme kaum machen.

Wenn Daten länger sind als man mit dem 2-Byte Längenfeld beschreiben 
kann, dann wird der eigentlichen Meldung eine weitere Meldung 
vorangestellt. Die ist genauso wie eine normale Meldung aufgebaut und 
enthält im Datenbereich die Gesamtlänge der in weiteren Meldungen 
folgenden Daten. In ihrer Länge enthält sie nur ihre eigene 
Meldungslänge.


Beispiel: Run/Stop-Taste betätigen

PC -> Osc:  53 0400 13 1301 7e

   0x53:   Beginn der Nachricht
   0x0400: Länge der Nachricht 0004 (Little-Endian)
   0x13:   Typ der Nachricht (hier Tastenbedienung)
   0x1301: Tastencode 0x113 (Run/Stop-Taste) (Little-Endian)
   0x7e:   Checksumme

Osc -> PC:  53 0300 93 02 eb

   0x53:   Beginn der Nachricht
   0x0300: Länge der Nachricht 0003 (Little-Endian)
   0x93:   Typ der Nachricht (hier Tastenbedienung | 0x80)
   0x02:   Antwort-Code 2 (diesen und andere Codes, die ich gesehen
           habe, habe ich nicht weiter analysiert. Die Antworten kommen
           bei Tasten auch in verschiedenen Längen)
   0xeb    Checksumme

Vielleicht ist folgendes für einen Hack zu gebrauche. Es gibt eine 
Nachricht um zumindest einige Dateien vom Oszilloskop zu lesen:

PC -> Osc: 53 1300 10 00 2f6b657970726f746636f6c2e696e66 66

   0x53:   Beginn der Nachricht
   0x1300: Länge der Nachricht 0x0013  (Little-Endian)
   0x10:   Typ der Nachricht (hier Datei lesen)
   0x00:   Subtyp 0 (?)
   0x2f6b...  Dateiname ASCII für /keyprotocol.inf
   0x66:   Checksumme

Osc -> PC: 53 ae03 90 01 <Inhalt der Datei> <Checksumme>

   0x53:   Beginn der Nachricht
   0xae03: Länge der Nachricht 0x3ae (Little-Endian)
   0x90:   Typ der Nachricht (hier Datei lesen | 0x80)
   0x01:   Subtyp 1 (vielleicht OK? Subtyp 0 vielleicht "nicht gefunden"?)
   <Inhalt der Datei>:
           [TOTAL]  49
           [START]
           [FN-0-KEY] 1
           [FN-1-KEY] 1
           [FN-2-KEY] 1
           ...
  <Checksumme>

Ich glaube, ich habe in meinen Logs alle Tastenkodes (alle analysiert), 
Sonderfunktionen wie das Sperren der Eingabe am Gerät, Lesen der 
Oszilloskop-Einstellungen (ca 200 Bytes kommen auf einen Rutsch, von 
denen ich vielleicht 10 analysiert habe, wie Kanal an/aus), setzen von 
Einstellungen, Bildschirmfotos, und Sample-Daten lesen.

Allerdings habe ich mir bei einigen Dingen nicht die Mühe gemacht sie zu 
analysieren, da ich das nicht brauche. Interessant wäre es die 200 Bytes 
mit den Oszilloskop-Einstellungen und das Format der Bildschirmfotos 
komplett zu analysieren. Aber irgendwann muss ich auch mal arbeiten ...

[Thomas R. (tinman)]

Protokol format war genau was ich gesucht habe, das hilft
schon weiter, danke.

Übrigens, 0x43 als begin der nachricht startet den debug mode,
da sind natürlich einige interessante funktionen verfügbar
(FPGA reg write/read, FPGA FIFO read, DSO data read usw)

Für hack interessant sind zwei, die eine die du schon angesprochen hast
und remote control die nix anderes ist als eine remote shell (typ der 
nachricht 0x11). Dabei wird dann der buffer als /msg geschrieben und 
ausgeführt, ergebniss (shell echo) wird dann zurückgeschickt an PC.

Für alt. PC software können auch einige von den debug mode nachrichten
nutzlich sein.

Die normale kommunikation steht in der "DoNormalProtocol",
die debug kommunikation in der "DoDebugProtocol" in dem asm code.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Thomas R. schrieb:
> Protokol format war genau was ich gesucht habe, das hilft
> schon weiter, danke.
>
> Übrigens, 0x43 als begin der nachricht startet den debug mode,
> da sind natürlich einige interessante funktionen verfügbar
> (FPGA reg write/read, FPGA FIFO read, DSO data read usw)

Sample-Daten lesen habe ich als normale 0x53 Nachricht, Typ 0x02 in 
meinen Logs gefunden.

Das ist eine der Nachrichten, bei der der Antwort eine zusätzliche 
Nachricht vorausgestellt wird, in der zuerst die Datenlänge kommt.

Front-Panel Lock/Unlock ist Typ 0x12 mit etwas merkwürdigen Argumenten. 
Dabei geht das Schlüssel-Icon auf dem Bildschirm schön an und aus.

> Für hack interessant sind zwei, die eine die du schon angesprochen hast
> und remote control die nix anderes ist als eine remote shell (typ der
> nachricht 0x11).

0x53 0x11 habe ich nicht als Remote-Shell, sondern als Gegenstücke zu 
0X53 0x01:

0x01: Aktuelle DSO-Einstellungen lesen.
0x11: Neue Einstellungen schreiben.

Beide Nachrichten sind in meinen USB Logs jeweils 213 Bytes lang (inkl. 
0x53, Länge, Typ und Checksumme).

Besonders 0x01 ist im USB-Log nicht zu übersehen. TTScope sendet diese 
Nachricht alle 0,5 Sekunden um keine Änderungen der Einstellung zu 
verpassen. Allerdings macht TTScope dann nichts mit den Daten, oder ich 
habe den versteckten Menüpunkt nicht gefunden.

[Thomas R. (tinman)]

Hannes Jaeger schrieb:
> Thomas R. schrieb:
>> Protokol format war genau was ich gesucht habe, das hilft
>> schon weiter, danke.
>>
>> Übrigens, 0x43 als begin der nachricht startet den debug mode,
>> da sind natürlich einige interessante funktionen verfügbar
>> (FPGA reg write/read, FPGA FIFO read, DSO data read usw)
>
> Sample-Daten lesen habe ich als normale 0x53 Nachricht, Typ 0x02 in
> meinen Logs gefunden.
>

ja das schon, was der debug modus erlaubt is die raw daten zu lesen
und nicht nur die nachbearbeitete daten.

>> Für hack interessant sind zwei, die eine die du schon angesprochen hast
>> und remote control die nix anderes ist als eine remote shell (typ der
>> nachricht 0x11).
>
> 0x53 0x11 habe ich nicht als Remote-Shell, sondern als Gegenstücke zu
> 0X53 0x01:
>

beachte mein hinweis auf debug mode, 0x43 0x11 und nicht 0x53 0x11

[Thomas R. (tinman)]

Johannes R. schrieb:
> Carsten Sch. schrieb:
>> Eine Begründung dazu wäre interessant...
>
> Naja, ich bin mehr so die Haptik eines Hameg 1507-3 gewohnt, daher
> möchte ich für manches lieber eine direkte Taste anstatt eines Menüs,
> zudem finde ich das Scrollen beim Hameg über den Art Wipptaster besser
> gelöst als über den Drehimpulsgeber beim Tekway.

naja ... das ist eher persönliche vorliebe, wobei klar
man achtet auch aus sowas beim kauf.

>
> Genauso sind die
> Triggerfunktionen nicht das Optimale. Irgendwie bin ich blind und find
> die Einstellung nicht, damit ich die Triggerposition einfach wie beim
> Hameg um 0-25-50-100 verschieben kann oder ich kann bei dem Tekway
> wirklich nur über eine horizontale Verstellung der Zeitachse arbeiten,
> das geht zwar, ist aber nicht so schnell wie diese Stufung, denn man
> kann das Signal zwar feiner ausrichten, aber man braucht länger als wenn
> man einfach wie beim Hameg 3x die Taste drückt und das Signal dann an
> der richtigen Position hat.
>

Triggerposition hat leider keine stufung (abgesehen von dem 50% 
trigger),
das könnte aber auf die wünscheliste hinzugefügt werden.

Da sind übrigens schon sachen wie :
- 20kpoint speicher mit 400MSs (war eigetlich da ist aber disabled),
oder 16kpoint mit 1GSs gesammpled.

- avg. für long memory

- besseres equ. mode, die waveform distortion machen es kaum
möglich z.zt. Wobei da gibts auch ein paar neuegkeiten, mehr weiter 
unten.

- tracking cursor (das ist schon implementiert)

HanTekway arbeitet z.zt. an den bugs, es gab eine lange liste,
die würde approved und zurück gescickt mit datum angaben wenn die
damit fertig werden.

Ich habe seit ein paar tagen eine test version von der firmware wo schon
folgende gubs beseitigt sind :

- dots/vectors icon ändert sich jetzt beim umschalten - das ist zwar
kleinigkeit aber ich mocte es nciht

- default setting knopf löscht die farbeinstellungen nicht mehr,
auch kleinigkeit allerdings hat sich es jemand so gewünscht.

- im long memory mode beim 8ns/4ns/2ns/DIV wird die waveforam jetzt
auch gescrollt wenn man de position ändert - die ist davor immer
verschunden was sehr lästig war (da man kaum zurückscrollen konnte)

- es wird beim maximalen zoom jetzt eine nachricht gezeigt und timebase
regler abgeschaltet - davor konnte man scrollen bis gar nix zu sehen 
war.
Das war ebenfalls sehr lästig, speziel weil in grenzbereichen die
abstände zwischen angezeigten samples nicht mehr gestimmt haben

Diese firmware version habe auch hier gepostet :

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


Woran die gerade arbeiten sind die verbesserungsvorschläge von oben und 
:
- digitale filter - die waren total schrott, mittlerweile
akzeptieren die die eingestellten freq. vorgaben, die waveform sieht 
aber
noch sehr besch. aus.

- FFT full span vs. sampling rate im 80ns->20ns/DIV. Mein patch
funktioniert zwar gut, allerdings nicht immer sauber mit hw1005
modelen - da hat Hantek versucht neues design zu bastelln
und nur haufen timings fehler produziert.

- SDK wird auch bald verfürgar sein (wobei stellt sich die frage
ob auc die die bench modele oder nur die neuen handhels - eigentlich
egal da die handhelds fast 1:1 den bench modelen entsprechen)

- FPGA/ADC timing .. tja lange geschichte. Eigentlich ist mir
(und ich glaube jedem der ein Tekway/Hantek hat) die wavform distortion
beim 1GSs direkt aufgefallen, was an sich bei einem design wo die ADCs
mit FPGA getaktet werden auch "selbstverständlich" erschien, speziel
weil standard i/o pins für clock out verwendet werden.
Manche haben es auch versucht zu beseitgen (mit rauscharmen clock 
source)
cih habe wiederum anderes weg gewählt und externe clocks gebaut.
Das hat auch sehr gut funktioniert, ich war eigentich dabei
eine PCB zu machen mit 2 externen clocks. Für den finetunning musste
ich aber genau nachmessen wie die clocks sich verhalten - Hantek
wollte es nciht sagen ob da irgendwelche delays notwendig sind.

Vor 6 wochen habe dann etwas lab zeit gehabt und ein paar messungen
gemacht und dabei festgestellt das im 1GSs mode timing überhaupt nicht
stimmt. Auf den ersten blick könnte man sagen das das design nicht zur
PCB passt, allerdings im 800MSs passt es wieder auf wenige ps :

Clock 8->Clock 1 1250 ps
Clock 1->Clock 7 1260 ps
Clock 7->Clock 2 1280 ps
Clock 2->Clock 6 1230 ps
Clock 6->Clock 3 1260 ps
Clock 3->Clock 5 1280 ps
Clock 5->Clock 4 1230 ps
Clock 4->Clock 8 1260 ps

ideal wäre jeweils 1250ps

wärend beim 1GSs

Clock 8->Clock 1 1010 ps
Clock 1->Clock 7 1250 ps
Clock 7->Clock 2  550 ps
Clock 2->Clock 6 1230 ps
Clock 6->Clock 3 1000 ps
Clock 3->Clock 5 1280 ps
Clock 5->Clock 4  500 ps
Clock 4->Clock 8 1250 ps

ideal 1000ps.

Ich habe Hantek mit den ergebnissen konfrontiert, als antwort kamm
eine anfrage ob ich den helfen könnte die timing probleme zu beseitigen.
Ich war an sich überrascht, Hantek hat zwar hin und wieder die hosen
runtergelassen (wie beim hw1005), sowas habe aber nciht erwartet.
Es war am ende typische management antwort, der Hantek ingenieur hat
kurz danach zugegeben das er das selber beseitigen kann, so hat sich
also meine hilfe erübrigt. Eigentlich sollte ich schweigen, da ich
aber kein NDA unterschrieben habe ist eh wurscht, evt. lernen
die auch darus und spendieren den armen schlucker der die firmware
schreibt auch ein paar vernünftige messgeräte. Bin gespannt was
die mir sagen wenn die merken das die ausgerechnet "den bösen hacker"
um hilfe gebeten haben.

Man könnte sich zwar fragen wie kamm es dazu das die timings nicht
stimmen, ist aber im prinzip egal. Jemand war einfach sehr schlampig
und hat möglicherweise nach dem Hantek die fa. Tekway "aufgekauft" hat
es gar nciht mehr erwähnt (oder war schon entlassen).
Auf jeden fall, wenn man sich den ARM code anguckt, haben
die seit dem immer wieder versucht den ARM code anzupassen damit die
distortion kleiner wird anstatt direkt an der feheler quelle arbeiten.

Die reaktion von Hantek ist eigentlich ein beweis dafür das es niemanden
(der z.zt. bei dem HanTekway dev team arbeitet) so wirklich bekannt
war das beim PLL umschalten die phase shifts nicht angepasst sind.

Angeblich (aussage Hantek) haben die es mittlerweile beseitigt und
suchen nach einer möglichkeit das als ein firmware update
zu implementieren - allerdings haben mir keine neue FPGA
design version zugeschickt sondern nur beantwirtet
"warte sie bis wir fertiges update haben".

An sich fw-update klingt einfach, allerdings da die werkskalibrierung
mit alten design gemacht war kann man nciht mal eben die designs 
tauschen.
Gut, da ich die werkkalibrierung geknackt habe und public gemacht
habe sollte es nicht unmöglich sein, allerdings wird Hantek kaum
die enduser fragen so eine kalibrierung selber durchzuführen.

> Was mich auch stört, ist die geringe Trägheit beim Erfassen eines
> Signals. Ich hab alles mögliche in den Einstellungen probiert, bekomm es
> aber nicht weg, die Messwertbildung aus mehreren Messwerten ist aus,
> aber das könnte natürlich nur ein Firmwarebug sein.

je nach firmware kann sein das du eine version erwischt hast die
zu viele debug informationen rausspuckt - die sind dann allerdings 
träge.
Es ist teilweise auch meine schuld, ich habe immer wieder neue - und 
manchmal auch testversionen - verfügbar gemacht.


> So ist es recht toll, aber die Erweiterungen ala Ethernet oder auch
> Touchscreen lassen auf sich warten, genauso die angekündigte
> Logikanalyzerfunktion.


LAN erweiterung ist z.zt. nur bei den neuen handheld implementiert,
den habe ich zerlegt und zeichne gerade nach wie der DM9000 dran hängt.
Die PC software arbeitet mit LAN deutlich schneller, die ist
zwar müll aber da kann man auch selber etwas bauen.
Ich habe bis jetzt auch Hantek gar nicht angesprochen die PC software
zu ändern, ich denke stabile und bugfreie firmware ist wichtiger.

Ich habe mitlerweile auch VGA-out zusammen gebaut, bin am überlegen ob
ich es nciht zusammen mit LAN auf einem board machen soll oder als eine 
"fliegende" PCB.

Hantek selber hat mir gesagt das LAN mit den BM/BMV modelen
kommt. Es ist auch nicht geplannt die B modele nachzurüsten.
Man kann die hw1005/hw1007 modele aber sehr leicht
auf BM/BMV umbauen - grosseres SRAM, Audio DAC, µSD, LAN chip und
eine kleine ini die einmal ins E2PROM eingelesen wird - und schon
gehts.

Beim hw0 geht natürlich kein Audio DAC, kein µSD udn evt. kein LAN
mit DM9000 - allerdings so wie ich sehe ist es im prinzip
egal welches IC verwendet wird, d.h. CS8900 dürfte auch funktionieren.
Kann das allerdings z.zt. nciht testen.

Mehr sample speicher beim hw0 geht auch, man muss lediglich zwei
CPLD pins mit (den grosseren) SRAM verbinden.

Ahja, evt. muss CPLD mit anderen inhalt programmiert werden,
ist aber keine so grosse sache - ich habe die .pof files hier
(für hw0/hw1007 - hw1005 fehlt, evt. kann jemand zurück lesen,
die sind nciht geschüzt)

LA erweiterung wird (soweit ich weiss) nciht mehr bei den B modelen 
eingebaut, ich habe ein katalog bekommen und auch ein paar infos
darüber hier geschrieben :

http://www.eevblog.com/forum/index.php?topic=5778.0

Die B/BM/BMV werden weiterhin produziert, dazu kommen also
auch 4ch modelle.

Übrigens - die BM/BMV modele kommen auch mit kernel 2.6.30.4,
die firmware wird allerdings mit beiden kernels arbeiten.
Ich glaube nciht das Hantek ein kernel/root fs update anbieten wird,
ist allerdings halb so wild - ich werde eins bauen falls
wirklich notwendig um die finallen BM/BMV feature zu enablen.
Soweit ich sehen kann wird aber so ein update notwendig sein,
die handhelds haben auch 2.6.30.4 (und nur da konnte ich z.zt. alle
BM/BMV features freichschalten)

>
> Aber gerade in Sachen Haptik vergleiche ich ja Äpfel mit Birnen, das
> eine ist ein 500€ Gerät und das andere eins für rund 1500€, wobei ich
> für den Preis dann eher zu der X Reihe von Agilent greifen würde. ;)
>
> MFG Johannes

ach was, ein 500€ gerät kann durchaus gute features haben,
vergleiche sind immer gut. Ganz ohne vergleich gäbe es keine firmware
verbesserungen, wenn es nach Hantek gehen würde (am anfang waren die
auch so, mittlerweile habe die verstanden - Tekway eigentlich war
immer für veränderungen) hätten wir chinesisch drauf gehabt.


P.S. - ich freue mich schon auf die üblichen schläger und die
billig-china-crap kommentare. Man sollte dabei aber nicht vergessen das 
Tekway lediglich eine idee von zwei armen schlucker war, danach
eigenständige abteilelung und mittlerweile eine kleine aber feine firma.
Hantek hat die fast für um sonst gekauft, die produzieren zwar
weiter unter eigenen namen, sind aber von Hantek doch abhängig (mehr
als die gerne hätten). Seit Hantek die gekauft hat ist viel mist
entstanden (hw1005), zwar hat Hantek es mittlerweile auc verstanden
das man nich mehr sch* produzieren kann und hoffen das es keiner merkt
allerdings haben die durch den lernprozess ein ganzes jahr verlohren
(und wir natürlich auch).
Ich habe allerdings Hanteks entschuldigung akzeptiert, sowas passiert
selten das ein hersteller fehler zugibt und sich dafür entschuldig,
schade nur das die nciht genug mutt hatten um es auf dren website
zu machen.

[Thomas (Gast)]

Gibt es denn die BM/BMV Modelle schon irgendwo zu kaufen?
Wenn ich mir jetzt bei Pinsonne, oder bei ebay ein Gerät ziehe, bekomme 
ich dann noch ein HW1005 oder schon ein HW1007?

2MB Speicher (BM) währen schon toll, aber was soll denn diese "Built-in 
Video Help" (BMV) sein? Da kann ich mir jetzt wenig drunter vorstellen.

[Thomas R. (tinman)]

HW1005 war nur 3 mon. lang produziert, denoch mit etwas pech kann
man noch eins bekommen. Die vertragshändler händler (sollten) haben 
allerdings die hw1005 zurück geschickt. Sollte es denoch passieren das
man ein hw1005 bekommt - einfach zurück schicken und neues teil 
verlangen,
die vertragshändler (aussage Tekway) müssen es annehmen/tauschen.

Beim (chinesischen)ebay händlern bekommt man evt. ein hw1005,
jemand hat mir bilder zugeschickt von sogar HW0 die er erhalten hat
(wobei die is genau so stabil wie hw1007 - nur eben keine BM/BMV
nachrüstmöglichkeit).

Z.zt. sind weder die preise noch liefertermin für BM/BMV modele
bekannt, beide hertseller haben lediglich Dez2011/Jan2012 gesagt.
Eigentlich war der plan die firmware fehler/verbesserungen aus
der issuelist die HanTekway mir zugeschickt hat bis ende Nov.
abzuarbeiten, und dann erst weiter an BM/BMV firmware arbeiten.
So wie ich das sehe (verglcih zwischen soll/ist) liegen die 2 wochen
zurück. Es ist allerdins sehr fair gegenüber den kunden die
hw1005 gekauft haben, der FFT full span bug könnte schon längst
(für hw0 und hw1007) beseitigt sein allerdings will HanTekway
das auch lauffähig auf den hw1005 haben.



BMV erhält ausser video help system auch microSD.
Auf microSD kann man (ausser den videos) die waveforms speichern,
wobei auf dem BMV handheld (umgebautes B) sind es nur die tatsächlichen
waveforms - also keine setups, keine refs, und keine screenshots.
Mag sein das dies noch geändert wird sobald die BMV tatsächlich
verfügbar sind (sprich wenn die firmware staut "final" erreicht hat).

Die Video Help ist im prinzip nur video player, der vom USB auf SD und
umgekehrt video kopieren und die natürlich abspielen kann - vom SD und 
USB.
Das ist also eigentlich nur für klassenzimmer/schulungen sinvoll.

Die 2Mpoint speicher auf dem umgebauten handheld sind genau so "träge"
wie 1Mpoint auf dem bench DSO, funktionieren allerdings soweit gut.

[Johannes R. (johannes_r29)]

Sprich ich kann bei Pinsonne das Gerät gegen eins mit HW1007 tauschen 
lassen? Hab die ältere 1005er...


MFG Johannes

[Thomas (Gast)]

Danke für deine Antwort.
Ich werde mir wahrscheinlich ein DST1062B bei PinSonne kaufen und auf 
DST1202B "upgraden", das wird ja dann wohl HW1007 haben.

Was meinst denn du mit "träge"? Kann man den Speicher etwa nur bei 
langsamen Abtastraten voll nutzen?

[Thomas R. (tinman)]

Johannes R. schrieb:
> Sprich ich kann bei Pinsonne das Gerät gegen eins mit HW1007 tauschen
> lassen? Hab die ältere 1005er...
>
>
> MFG Johannes

vorrasugesetzt Pinsonne hat die gleichen information von Tekway die
ich erhalten habe - ja.

Im schlimmsten fall kann man auch nachhelfen, kaputt ist kaputt.
Es prüft zwar keiner, ich würde dann aber die firmware in org.
zustand versetzen - falls du ein backup gemacht hast
siehe hier wie ein restore ohne JTAG kabel geht :

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



Thomas schrieb:
>
> Was meinst denn du mit "träge"? Kann man den Speicher etwa nur bei
> langsamen Abtastraten voll nutzen?

design bedinngt reagieren die knöpfe/menu etwas träge wenn 1Mpoint
eingeschaltet sind.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Thomas R. schrieb:
> P.S. - ich freue mich schon auf die üblichen schläger und die
> billig-china-crap kommentare.

Wenn du so bettelst ...

Aber mal im Ernst

> Ich habe allerdings Hanteks entschuldigung akzeptiert,

Es ist schön das die mit dir reden, mit mir reden die gar nicht. Dabei 
wollte ich keine Entschuldigung, nur als normaler Kunde ein paar ganz 
einfache Informationen.

Höflich gefragt, keine Antwort bekommen. Nochmal höflich gefragt, keine 
Antwort bekommen. Jetzt können sie mich mal am Arsch lecken, denn 
irgendwann ist mir meine Zeit zu schade solchen Firmen 
hinterherzulaufen. Wenn ihnen eine Frage nicht passt, dann stecken sie 
sich die Finger in die Ohren und pfeifen La-Paloma (oder was der 
Chinamann so pfeift wenn er pfeift ...).

Aus meiner Sicht hat Hantek nichts, aber rein gar nichts gelernt. Die 
produzieren immer noch den gleichen China-Schrott in der billigsten Art 
und Weise mit der Hoffnung gerade noch davon kommen zu können. Der Kunde 
hat gefälligst das Geld abzuliefern und, besonders wenn er eine Langnase 
ist, danach gefälligst die Klappe zu halten.

Natürlich sind andere auch so. Es läuft darauf hinaus, das man beim Kauf 
keinen auf die Zukunft gerichteten Aussagen glauben sollte.

[Thomas R. (tinman)]

Hannes Jaeger schrieb:
>
> Es ist schön das die mit dir reden, mit mir reden die gar nicht. Dabei
> wollte ich keine Entschuldigung, nur als normaler Kunde ein paar ganz
> einfache Informationen.
>
> Höflich gefragt, keine Antwort bekommen. Nochmal höflich gefragt, keine
> Antwort bekommen. Jetzt können sie mich mal am Arsch lecken, denn
> irgendwann ist mir meine Zeit zu schade solchen Firmen
> hinterherzulaufen.

das ist typisch chinesiches "problem" (mentalität) - wenn die gerade
nix zu sagen haben sagen die auch nix, statt einfach und ehrlich
zu beantowrten was die sache ist. Hier kennt man sowas nicht, ich bin
aber sowas nach mehreren jahren asien tätigkeiten gewöhnt.
Schreibt man "ihr könnt mich mal, warum bekomme ich keine antwort"
sind die gleich beleidigt und verstehen nicht warum man sich aufregt.


>
> Aus meiner Sicht hat Hantek nichts, aber rein gar nichts gelernt. Die
> produzieren immer noch den gleichen China-Schrott in der billigsten Art
> und Weise mit der Hoffnung gerade noch davon kommen zu können. Der Kunde
> hat gefälligst das Geld abzuliefern und, besonders wenn er eine Langnase
> ist, danach gefälligst die Klappe zu halten.

es ist nicht so das Hantek sich entschuldig hat weil ich so nett war
sondern weil ich ein paar händler und privat personen angestiftet habe
sich masive zu beschweren - mit genau den selben bugs/taktik.
Z.zt. sind die super nett (trotzdem dauert es hin und wieder tage
bis eine antwort kommt, siehe oben), mal sehen wie lange das so geht.
Vermutlich bis die firmware anhand der issuelist bugfree ist und die
mit BM/BMV und 4ch modelen starten - dann wird das ganze von vorne 
gehen:
- bugs sammeln
- durchdrehen
- mit schlechter werbung drohen
- woche warten und wieder von vorne

dann werden die wieder "wach" und machen etwas.

Evt. wird aber alles anders sein, bald werden wir sehen.

Übrigens, Tekway selber wünscht sich das jemand sich meldet
und die ganze DSO geschichte von Hantek abkauft. Die waren klein
aber fein - klar resourcen probleme, verzögerungen beim bugs
beseitigung - allerdings konnte man mit Tekway immer sprechen.

Hantek ist ein alter Conrad & Co zuliferer/abzocker, man muss sich nur
die hantek.org angucken und schon wird klar das die viel machen um nix
zu machen.

Allerdings wissen die mittlerweile das es sehr schnell wieder so
sein wird das niemand deren geräte kaufen wird - schlechte werbung zu
machen ist einfach.


Owon kämpft z.zt. sehr stark mit dem abzocker/billig-gurken image,
die neue SDS serie sollte "die lösung sein" - die ist zwar nett aber
natürlic haben die ein paar sachen vergurkt.
Nur es sieht so aus das die auch dazu gelernt haben,
3 tage nach meinen posting über die hausfrauen-BNC-lösung
und massiven email terror haben die neue PCB geroutet - diesmal
sind die BNC richtig dran, VGA chip auf main pcb statt mit einen kabel 
hin
und mit anderen zurück (natürlich nciht geschirmt).
Nach wochenlangen terror wollen die auch die firmware udpates
public machen und nciht mehr über händler.

ATTEN ist auch cool drauf, ich wollte mal deren SAs testen - habe
die preise bekommen und wollte bestellen nur dann kamm die antwort:
"bitte nicht kaufen, firmware instabil". Sowas schreckt mich nciht
ab, wollte denoch kaufen, da hat aber ATTEN zugegeben das z.zt. können
diese SAs gar nicht upgedated werden - sprich alle bugs die drin sind
bleiben auch für immer drin (es sei den ich schicke es zurück und die
neues BOARD! einbauen wenn die fertig sind).

Man könnte also denken das chinesische hersteller verstanden haben
das ein zufriedene kunde auch treue kunde bedeutet - dann gibts
aber tage an den ich genau so wie du denke.

In paar tagen sind es genau 2 jahre seit dem ich den Tekway habe,
bin immer noch zufrieden und kann die immer noch empfehlen -
allerdings muss ich dan auch ehrlich sagen - achtung da sind bugs
drin - bitte ein paar tage abwarten.

Die alte firmware (also bevor Hantek inhaber Tekway gekauft hat)
war nach ~3 monaten so weit ok das ich von bug-free sprechen kann.
Dann ab der Hantek ära war alles anderes, aber das weiss man hier
mittlerweile.

Jetzt, abgesehen von dem digital filter bug, ist die firmware
akzeptabel (da ich hw0 und hw1007 habe ist FFT full span bug
für mich zweil mal im hex editor klicken und fertig).
Die FPGA design timing geschichte ist nur extra, ich kann mit
der distortion leben, toll wäre natürlich wenn die kleine wäre.
Versuche mit externen clock oder intern aber immer mit 800MSs haben
gezeigt das es geht, jetzt muss nur Hantek endlich die file
freigeben.


>
> Natürlich sind andere auch so. Es läuft darauf hinaus, das man beim Kauf
> keinen auf die Zukunft gerichteten Aussagen glauben sollte.

hehe stimmt, SDK sollte schon vor 12 monaten da sein .. ohja und
vor 18 monaten auch ... dann aber immer wieder gestoppt -
erst weil Tekway SCPI implementieren wollte, dann weil Hantek
es nciht mehr wollte da die selber super SDK schreiben wollten,
dann wieder weil die total busy waren nach dem die hw1005 vergurkt 
haben,
dann wieder weil die neue modele vorbereiten wollten, dann weil
die erst fw bugs beseitigen wollen (da sind wir gerade).

[Thomas (Gast)]

So, ich habe jetzt doch über ebay beim Chinamann bestellt. Auf Nachfrage 
hat er mir bestätigt, dass es sich dabei um die aktuelle HW Revision 
handelt.
Der kann mir zwar viel erzählen, ist ja schließlich 9000km weit weg, 
aber für 390€ riskier ichs.
Außerdem hat er nur gute Bewertungen.
Ich habe gesehen, dass der gleiche Anbieter auch einen deutschsprachigen 
Webshop betreibt, bei dem es die Dinger zum selben Preis gibt:
http://www.rigoloszilloskop.de
Aber über ebay war mir dann doch sicherer.

Übrigens ganz schön dreist, wie offensiv die den Steuerbetrug bewerben:

Fragen und Antworten zu diesem Artikel
Frage: gilt das bei diesen Oszillioskop auch wie beim UNI-T UTD2102CEL
       das die Ware über England nach Deutschland geliefert wird und somit
       keine Zollgebühren entstehen?
Antwort: Hallo. Ja, stimmt so ist das, keine Zollgebuehren zur fuerchten.

;)

[Marc (Gast)]

Hallo,

ich will mir dieses Jahr zu Weihnachten auch ein Oszi zulegen und 
schwanke noch zwischen dem hier und dem Owon SDS8102.
Beim Owon finde ich das riesen Display und den fetten Speicher klasse.
Das Hantek hingegen kann man billig kaufen und auf 200MHz tunen.

Wichtig währe mir noch, wie bastelfreundlich das Scope ist.
Evtl. weil ich selbst damit spielen will, aber auch weil man dann auch 
auf Features aus der Community hoffen kann und nicht unbedingt auf den 
Hersteller angewiesen ist.
Gerade bei der Produktpflege haben die Chinesen ja nicht unbedingt den 
Besten Ruf...

Jetzt habe ich gehört, dass auf dem Hantek ein richtiges Linux läuft, 
während das Owon irgend was eigenes gebastelt hat.
Deswegen denke ich, dass das Hantek wahrscheinlich zugänglicher sein 
wird.

Kann da jemand was zu sagen?

Ach ja, und kann mir mal bitte jemand den Begriff "wfrms/s" erklären, 
und warum ich davon möglichst viel haben will?

Danke!

[branadic (Gast)]

Marc schrieb:
> Ach ja, und kann mir mal bitte jemand den Begriff "wfrms/s" erklären,
> und warum ich davon möglichst viel haben will?

Schau dir den Film an und du weißt warum Waveforms/Sekunde so wichtig 
sind ;)

http://www.scope-of-the-art.de/de/film/

branadic

[Marc (Gast)]

Danke, jetzt hab ichs verstanden.
Das Video hat mich überzeugt, ich werde mir also jetzt ein R&S RTO1024 
zu Weihnachten schenken ;)

Weiß noch jemand was zur Bastelfreundlichkeit des Scopes (Hantek vs. 
Owon)?

[Pascal 1. (lodschi)]

Bin auf auf der suche nach nem Oszi für daheim war eigentlich fixiert 
auf das TEKWAY DST1062B und dann mit hack auf 200Mhz aufmachen, hätte 
schon über pinsonne bestellen wollen. aber dann hier gelesen das das 
Hantek ev. besser/billiger wäre.
kann mir hier jetzt einer einen Tipp geben.

brauchs hauptsächlich für schaltregeler, µC und Signalanalyse.

[Carsten S. (dg3ycs)]

Hi,

Pascal B. schrieb:
> Bin auf auf der suche nach nem Oszi für daheim war eigentlich fixiert
> auf das TEKWAY DST1062B und dann mit hack auf 200Mhz aufmachen, hätte
> schon über pinsonne bestellen wollen. aber dann hier gelesen das das
> Hantek ev. besser/billiger wäre.
> kann mir hier jetzt einer einen Tipp geben.
>
> brauchs hauptsächlich für schaltregeler, µC und Signalanalyse.

Das Hantek DSO5062B ist weder besser noch schlechter als das Tekway 
DST1062B. Es sind prinzipiell die selben GEräte. Von derselben Firma 
gebaut! Wobei der Vetriebszweig wohl noch etwas eigenständig ist.(Hantek 
hat Tekway aufgekauft)
Vor rund einem Jahr als bei uns die Beschaffungsentscheidung gefallen 
ist (und ich mir in dem Zuge auch habe eines habe zu Weihnachten 
Schenken lassen) unterschieden sich lediglich die Tastenmatte und das 
MAterial der Drehknöpfe geringfügig. Ob das immer noch so ist oder 
selbst dieser Unterschied mittlerweile hinfällig ist kann ich aber nicht 
sagen.

Für Hantek gibt es mehrere Quellen, Tekway hat dagegen eine recht 
strikte GEbietsschutzpolitik so das nur wenige Händler in Frage kommen.
Ob Hantek billiger ist kommt ein wenig darauf an ob du reiner 
Privatkäufer bist oder aber die MwSt erstattet bekommen kannst. Es gibt 
einige Angebote wo die möglichkeit besteht ohne MwSt bzw. EUSt 
abzuführen an die Hantek Geräte zu kommen. Dadurch währe beim selben 
Netto Verkaufspreis das HAntek Gerät schon 19% billiger las Pinnsonne es 
anbieten kann. Der Verkäufer kann also viel mehr Gewinn aufschlagen und 
ist immer noch billiger als der Verkäufer der hier in DL ordnungsgemäß 
die MwSt abführt.

Als Gewerblicher Kunde bekommt man die 19% ja zurück, da muss man nur 
die Nettopreise vergleichen. Wenn man dies macht steht Pinnsonne gar 
nicht mal so schlecht da.
(In Frankreich gibt es z.B. einen Hantek Händler der aufgrund einer 
Besonderheit im Französichen Steuerrecht die GEräte ohne automatischen 
Aufschlag von Mehrwertsteuer verkaufen kann. Nettopreis ist höher als 
der von Pinnsonne, aber da keine 20% an den Staat gehen ist der Billiger 
für den Endkunden. Für Gewerbliche aber ist Pinnsonne die günstigere 
Quelle. Zumindest ist dies der Stand von vor 12 Monaten!!! Aktuell 
beobachte ich die Preise nicht)

Dazu gibt es wohl aktuell einen Ebay Händler aus China der die Hantek 
Skopes für 390 Euro anbietet. Das ist natürlich der Preis OHNE EUSt. Der 
Händler schreibt zwar das er garantiert das keine Steuer gezahlt werden 
muss, das GARANTIEREN ist aber Blösinn, das könnte er nur wenn er die 
Steuer selber zahlen würde.
Hier gibt es ja schon einige Berichte über den KAuf aus denen HErvorgeht 
das der Händler die Geräte -wie eigendlich fast alle dieser Ebay Händler 
aus China - mit "falscher", also viel zu niedriger Wertangabe versendet 
und daher die meisten wohl tatsächlich durchrutschen werden. Eine 
Garantie darauf das es klappt hat man aber nicht. Wird es dann aber doch 
vom Zoll "gefunden" muss man die 19% Zahlen oder es geht zurück nach 
China!
Eine Strafe dafür das die Wertangabe falsch ist gibt es aber nicht, denn 
belangen könnte man nur den Versender, der ist aber nicht greifbar...

Daher beser die Knapp 80 Euro mit Einkalkulieren und den Preisvergleich 
so machen als wenn man diese zahlen müsste. Wenn es dann trotzdem 
durchrutscht kann man sich freuen! Kalkuliert man es nicht ein und hat 
gerade einmal die 390 Euro mühsam zusammengekratzt (z.B. als Schüler 
oder Student) und dann will der Zoll auf einmal 80 Euro innerhalb von 
14Tagen oder er schickt das Paket zurück, dann hat man evtl. ein 
Problem.

Gruß
Carsten

P.S.: Das alles steht natürlich hier schon mehrfach im Thread. 
Allerdings kann ich verstehen das es für einen schnellen Überblick 
mitlerweile recht mühsam ist sich durch die vielen Beiträge zu wühlen.

[Pascal 1. (lodschi)]

also wäre das zb. gleich besser:
http://www.ebay.at/itm/Hantek-Digital-Speicher-Oszilloskop-DSO5202B-3-Jahre-G-/150605820945?pt=Mess_Pr%C3%BCftechnik&hash=item2310ce7411

weil dann muss man auch nicht die Hardwar modifizieren wie oben 
beschrieben da beim kleinen 1% Widersände und noch ein paar andere 
sachen anders sind und das dann genau so viel kostet wie das kleine tek 
bei pin.

aber wo bekomm ich dann die firmware her muss ich mich dann an Thomas 
halten?

bei pinn.. bekommt man aber auch die aktuelle hw 1007 und auch die fw 
updates.

hab zwar wirklich schon gut 3h hier im forum gelesen aber man überliest 
doch des öfteren etwas da ein forum einfach nicht so übersichtlich ist 
wenn schon so viele posts drin sind. hab auch schon einiges auf eevblog 
gelesen man kann sich einfach nie genug informieren.

was noch ausschlaggebend wäre ist zwecks lüfter mod mit lm7805 hab ich 
gelesen. aber ist der jetzt nur beim hantek drin oder auch beim tek?


Vielen Dank für die schnelle und ausführliche Information

ps: kenn mich im Forum mit den Funktionen noch nicht so aus aber könnte 
man nicht die ganzen Infos zusammenfassen und einen Artikel erstellen? 
würd mich auch gern beteiligen da das sicher für viele immer wieder 
interessant ist.

[Thomas R. (tinman)]

Pascal B. schrieb:
> also wäre das zb. gleich besser:
> 
http://www.ebay.at/itm/Hantek-Digital-Speicher-Oszilloskop-DSO5202B-3-Jahre-G-/150605820945?pt=Mess_Pr%C3%BCftechnik&hash=item2310ce7411
>
> weil dann muss man auch nicht die Hardwar modifizieren wie oben
> beschrieben da beim kleinen 1% Widersände und noch ein paar andere
> sachen anders sind und das dann genau so viel kostet wie das kleine tek
> bei pin.

winnie puuh würde sagen "denk, denk, denk"

Es sind 119EUR unterscheid zwischen selber löten (was an sich nur
notwendig ist wenn man 220MHz bw statt 180-190Mhz haben will)
oder fertiges kaufen (jetzt sollte ich dir eigentlich ein
umgebautes 60MHz DSO reindrehen und 119EUr kassieren).

Ahja, eigentlich verkaufen ebay händler nur "domestic market" modele,
die sind eigentlich nciht CE konform - das hat auch Hantek schriftlich
bestätigt.  Tekway war da mal etwas schlauer und hat die domestic modele
mit chineischen front-panel ausgestattet - die ebay &co händler sind
aber nicht dumm und produzieren eigene englische aufkleber.

Mit ist auch klar das es menschen gibt die direkt ein 200Mhz model
bei einen deutschen händler kaufen und das gerät dann "lediglch"
benutzen - es gibt aber auch welche die ständig die finger irgendwo
reinstecken müssen (und kein grosses wert auf garantie/gewährleistung
legen, was bei diesen geräten dank schaltplan und standard bauteilen
halb so wild ist).

Zur welcher gruppe du zugehörst muss du dir selber beantworten - und
demensprechend handeln.


>
> aber wo bekomm ich dann die firmware her muss ich mich dann an Thomas
> halten?
>
> bei pinn.. bekommt man aber auch die aktuelle hw 1007 und auch die fw
> updates.

Tekway / Hantek websites und händler oder hier/eevblog

>
> hab zwar wirklich schon gut 3h hier im forum gelesen aber man überliest
> doch des öfteren etwas da ein forum einfach nicht so übersichtlich ist
> wenn schon so viele posts drin sind. hab auch schon einiges auf eevblog
> gelesen man kann sich einfach nie genug informieren.

zum glück poste ich nciht alles was möglicherweise interessant wäre ...

Was ich allerdings immer mache sind die wichtigsten sachen gleich im
ersten eevblog post zu ändern (mit links), damit man die 70 seiten
nicht durchsuchen muss.

>
> was noch ausschlaggebend wäre ist zwecks lüfter mod mit lm7805 hab ich
> gelesen. aber ist der jetzt nur beim hantek drin oder auch beim tek?
>
>

lüfter sind jetzt standard bei beiden, die mainbaords sind auch gleich.
Tekway allerdings bestückt eigene boards (immer noch) selber und
macht auch burn-out tests, Hantek wollte nix dazu sagen (test).


>
> ps: kenn mich im Forum mit den Funktionen noch nicht so aus aber könnte
> man nicht die ganzen Infos zusammenfassen und einen Artikel erstellen?
> würd mich auch gern beteiligen da das sicher für viele immer wieder
> interessant ist.

gibts hier :

http://www.mikrocontroller.net/articles/Tekway/Hantek

allerdings nicht gepflegt, wenn du zeit hast kannst ruhig eevblog/mknet
postings da zusammen pasten.

[Pascal 1. (lodschi)]

Thomas R. schrieb:
> Es sind 119EUR unterscheid zwischen selber löten (was an sich nur
> notwendig ist wenn man 220MHz bw statt 180-190Mhz haben will)
> oder fertiges kaufen (jetzt sollte ich dir eigentlich ein
> umgebautes 60MHz DSO reindrehen und 119EUr kassieren).

dann also doch das 60Mhz gerät :D

> lüfter sind jetzt standard bei beiden, die mainbaords sind auch gleich.
> Tekway allerdings bestückt eigene boards (immer noch) selber und
> macht auch burn-out tests, Hantek wollte nix dazu sagen (test).

mir wurde von pins bestätigt das die tek in europa ohne lüfter geliefert 
werden. der lüfter ist nur für wärmere länder.

wozu würdest du greifen? Tek oder han. (mal abgesehen von den 129€ + 
vers.)

wenn die wirklich komplett gleich sind würd ich zum han auf ebay greifen 
wozu brauche ich als priv. person ein ce kennzeichen das eh jeder nach 
belieben überall draufdruckt. ausserdem ist das ja schon vorprogrammiert 
das ich da reinschaun muss :D

[Thomas R. (tinman)]

Pascal B. schrieb:
> wozu würdest du greifen? Tek oder han. (mal abgesehen von den 129€ +
> vers.)

Persönlich mag ich die Tekways wegen gehäuse farbe (messinstrument
grau-gelb, Hantek dagegen grau-weiss) und knöpfen (gummi qualität).
Abgesehen davon wenn man die bezeichnung abkürzt sieht es direkt
teurer aus :)

An sonsten ist es egal, burn-out tests klingeln zwar toll, sind aber
sowieso "pflicht" (wegen DOA). Mittlerweile schaft es Hantek
sauber zu löten und PCBs abzuwaschen (bench DSOs, beim einzelnen
handheld konnte ich dagegen locker 100g flux zurück gewinnen ...),
Tekway konnte es immer (abgesehen von der zeit direkt nach dem merger).

Trotzdem habe ich deutlich mehr Hantek als Tekway DSOs verkauft in
den letzten 2 jahren - der grund ist eigentlich simple - preis.
Die 60$ mehr einkaufspreis und günstigeren versand konditionen
machen schon am ende ein paar eur unterschied aus.
An sich müssen meine kunden zwar nicht sparen (gut, private die ich
hin und wieder habe möchten immer sparen) aber wir sind in
deutschland - geiz ist geil gillt für alle.

Ich hätte dir auch ein verkaufen können (Tekway oder Hantek),
habe aber z.zt. nur bestellungen für die BM modele die leider
noch nciht fertig sind (was mich nervt da die besteller bis
ende Dez. das geld los werden möchten).
Gut, ich habe zwei Hantek handhelds (auf 2Mpoint erweitert + LAN),
allerdings hat die firmware ein power saver bug (DSO spielt verrückt 
nach
dem aufwachen), mit so einen bug kann und will ich die nicht verkaufen.

>
> wenn die wirklich komplett gleich sind würd ich zum han auf ebay greifen
> wozu brauche ich als priv. person ein ce kennzeichen das eh jeder nach
> belieben überall draufdruckt. ausserdem ist das ja schon vorprogrammiert
> das ich da reinschaun muss :D

klar, man kan die betrofenen bauteile im netzteil austauschen
und schon passt es mit der sicherheit.

Pinsonne wird auch nix gegen "reinschauen" haben, umbauen ist
dann allerdings was anderes. Übriegns, hin und wieder
hat pinsonne bessere konditionen für studenten/schüler, nachfragen
lohnt also.

Auch den Hantek händler in Frankreich (elec3i.com) macht hin und wieder
solche aktionen.

[Thomas R. (tinman)]

Nils S.

> Beitrag #2452574 wurde vom Autor gelöscht.

nciht so schüchtern Nils :)

[Nils S. (kruemeltee)]

Thomas R. schrieb:
>> Beitrag #2452574 wurde vom Autor gelöscht.
>
> nciht so schüchtern Nils :)

Ich hab nich aufgepasst und einen Beitrag zitiert, der schon ein 
Weilchen zurücklag und nichts mehr mit dem aktuellen Thema hier zu tun 
hatte. Daher raus damit ;)

[Thomas (Gast)]

Hallo Freunde,

laut Trackingdienst kommt mein Oszilloskop morgen an.
Kann mir jemand sagen, wie ich schnell rausfinden kann welche 
HW-Revision das Teil hat? Am liebsten ohne das Gerät öffnen zu müssen.

Gruß,
Thomas

[Mischmasch (Gast)]

Thomas schrieb:
> Hallo Freunde,

Oh, die klassische Anschleim-Anrede. Nein, wir sind nicht deine Freunde.

> laut Trackingdienst kommt mein Oszilloskop morgen an.
> Kann mir jemand sagen, wie ich schnell rausfinden kann welche
> HW-Revision das Teil hat? Am liebsten ohne das Gerät öffnen zu müssen.

Einfach im System-Menü auf den Bildschirm schauen. Wenn du damit nicht 
überfordert bist.

[Thomas (Gast)]

Das du hier (und auch im RL) keine Freunde hast ist klar.
Du solltest allerdings nicht von "wir" sprechen, das ist ganz alleine 
dein Problem.

Wie auch immer, vielen Dank für deine Antwort (sofern sie denn was 
taugt).

[Thomas R. (tinman)]

locker Thomas, as Thomas darfst du auch keine freunde haben
(es sei den du bist kein echter Thomas) :P

Menu button, F1 (system inforation), die dritte zeile steht
hw version :

0 x 555583e8 = hw0
1005 x 555583e9 = hw1005
1007 x 555583e8 = hw1007

(die 555583e8/9 sind FPGA design versionen)

Ahja Thomas, und bevor du finger in die DSO-löcher reinsteckst
einmal backup machen.

[Thomas (Gast)]

Danke, Thomas. Du bist ein wahrer Freund ;)

[Thomas (Gast)]

So, das Gerät ist heute angekommen.
Macht einen guten Eindruck, vor allem wertiger als befürchtet.
Nur der Lüfter nervt, ich war eigentlich davon ausgegangen, dass das 
Teil Lüfterlos ist, irgendwo hatte ich das mal gelesen...
Keine Probleme mit dem Zoll, und HW Revision ist 1007.

Jetzt erstmal was rumspielen, und nächste Woche dann evtl. das 
Firmwareupgrade auf 200MHz machen.

[Thomas R. (tinman)]

ja, die sind lüfterlos, das was du hörst ist eine turbine :)

Die sind auch als lüfterlos entwickelt, irgendwann kammen die kühlkörper
aufd den ADCs und FPGA und seit kürzer zeit Lüfter.

Eigentlich kannst den Lüfter ausbauen, oder den 7812 auf dem netzteil
durch 7805 ersetzen - dann dreht es schnell genug.
Die meiste hitze wird durch den 3.3V LDO auf dem netzteil erzeugt,
man kann der duch ein dc/dc (mit filter) oder Micrel HELDO ersetzen,
dann ist de hitzequelle auch weg.

[Pascal 1. (lodschi)]

die lüfter sind aber nur in den Hantek auf eb** verbaut.
bei den Tek von pin ist das nicht der fall.

deswegen hab ich mich jetzt trotz 130€ für die tek entschieden.

[Thomas (Gast)]

Dir ist es 130€ wert einen Lüfter nicht selbst deaktivieren zu müssen? 
Und das als Elektronikbastler!?
Ich wollte auch erst bei Pinsonne kaufen, aber eher wegen Argumenten wie 
Gewährleistung, Ansprechpartner in DE, sauber versteuert. Letztlich hat 
mich der Geiz nach ebay getrieben ;)

Aber mal was anderes.
Was ist das eigentlich für eine bescheuerte Zeitbasis: 2 4 8
Die Spannungsbasis hingegen ist vernünftig: 1 2 5
Kann man das ändern?

[Johannes R. (johannes_r29)]

Anscheinend kann man es ändern, dies werde ich auch demnächst machen, 
denn die Zeitbasis nervt ein wenig, aber das hatte schon vorher 
Tektronix und dann hatte es Tekway...


MFG Johannes

[Thomas R. (tinman)]

Johannes R. schrieb:
> Anscheinend kann man es ändern, dies werde ich auch demnächst machen,
> denn die Zeitbasis nervt ein wenig, aber das hatte schon vorher
> Tektronix und dann hatte es Tekway...
>
>
> MFG Johannes

ändern kann man vieles, es gibt TIME_BASE_LIB2 und TIME_BASE_LIB

Die TIME_BASE_LIB2 ist für csv import export, die TIME_BASE_LIB
für die DSO timebase.

Die werte stehen in ps, z.b. DCB 0xD0, 7, ... is 7D0 also 2000ps
bzw. 2ns/div.

Man muss dabei beachten das an einigen stellen mit diesen werten
etwas berechnet wird, es gibt auch stellen wie z.b. factory calibration
wo eine timebase änderung von 4ns/div auf 5ns/div dazu führt das
die factory calibration nicht mehr läuft.

Soweit ich mich erinner kann müssen auch die FFT frequenz und step werte
(gibts auch tabellen) dann angepast werden wenn man die timebase
ändert.

Vom 2ns/div bis 800ns/div funktionieren änderungen (abgesehen von
den fehlern die ich gerade angesprochen habe, die kann man aber 
beseitigen)
eigentlich brauchbar, ab 2us/DIV bis 40s/DIV hatte ich nur haufen
probleme gehabt mit samples - ich vermutte es müssen auch noch ein paar
andere sachen dann angepast werden  (z.b. screen buffer).

Das ganze habe ich nur mit 4ksamples getestet, beim 40k/512k/1Msamples
gibts dann ein paar extra probleme (da jetzt geänderte sampling
rate noch dazwischen funkt).

Die timebase position ist die funktion Dso_GetWindowTBID,
es gibts stellen im code wo dann einfach abgefragt wird wie
weit man schon gedreht hat und dann dementsprechedn etwas gemacht,
z.b. der FFT full span fehler den ich immer wieder in den firmwares
patche prüft ob es schon position 3 ist (CMP R3, #2), also 8ns/div.
Wenn 0 bis 2 (1 bis 3) werden ADCs mit 125MHz getaktet (und kein long 
memory enabled ...) an sonsten mit 100MHz. Mein hack ändert es
auf CMP R3, #8 damit die 125MHz clocks bis einschliesslich 800ns/DIV
aktiv sind.

Es gibt aber z.b. eine abfrage CMP  R3, #0xF, also ob gerade die
position 200us/DIV erreich sind - dann wird 1Mpoint speicher
auf 512kpoint umgeschaltet da das scope probleme hat mit 1Mpoint
und 200us/DIV (also gehen die 1Mpoint davor und danach aber
nicht mit 200us/DIV).

Einige änderungen sind schmerzfrei, 2ns/DIV kann man wunderbar
auf 500ps/DIV ändern wenn man will - da hatte ich keine probleme
gehabt (dann aber mit nächster position - 4ns/DIV wegen factory cal)

All dies habe gemacht/geprüft bevor die fine timebase implementiert
war, jetzt sind möglicherweise ein paar zusätzliche fallen drin.

Wie gesagt, ändern kann man alles, man muss aber "ein paar" sachen
beachten. Mich juckt auch immer wieder in den fingern etwas anzupassen,
die firmware ist sehr gut lesbar (auch im asm code).

[Pascal 1. (lodschi)]

Thomas schrieb:
> Dir ist es 130€ wert einen Lüfter nicht selbst deaktivieren zu müssen?
> Und das als Elektronikbastler!?
> Ich wollte auch erst bei Pinsonne kaufen, aber eher wegen Argumenten wie
> Gewährleistung, Ansprechpartner in DE, sauber versteuert. Letztlich hat
> mich der Geiz nach ebay getrieben ;)

ist nicht nur der Lüfter den ich angesprochen habe sonder:
* ich mag ebay nicht (nicht vertrauenswürdig)
* ich hab einen richtigen Händler dahinter
* sollte mal was sein weiß ich der muss grade stehen
* Tekway hat mir von Anfang an mehr zugesagt
* 130€ einmal mehr zahlen dafür später nicht ärgern und was sind schon 
130€ bei nem Gerät das man dann gut 10 Jahre hat
* usw. paar andere kleinigkeitetn

hab mir echt lange den Kopf zerbrochen aber ich bin mit meiner 
Entscheidung zufrieden.
das einzige was mich zu Hantek gezogen hat war der geiz und da bin ich 
schon oft auf die schnautze gefallen.

[Thomas R. (tinman)]

Anbei die neueste firmware für Hantek / Tekway DSOs

Änderungen zur 111124.0:

+ USB drucker/printout (HP) implementiert
+ Trigger fixpoints verbessert (DC/AC/LH/HF/NR verschiebung)
- Digitale Filter sind jetzt komplett ohne funktion
(um keine verwirrung zu stiften solange bis die nicht gefixt sind)
- debug code entfernt (ist also keine test firmware wie 111124.0)

Mit ist noch ein bug aufgefallen, es scheint duchgehend seit März 2010
drin zu sein - im Equ. mode sampling beim timebase 800ns/DIV bis 2ns/DIV
wenn man die acq. stoppt und runter zoomt stirbt die firmware
beim überschreitung von 2us/DIV (oder malt haufen zeichen auf
dem bild und dann stirbt, je nach firmware version).

Im 40s/DIV bis 2us/DIV gibts den fehler nicht (also kein überlauf beim
runter zoomen), scheint also ein übergangsüberlauf zu sein.

Das ganze trifft allerdings nur für single window, im dual window
gibts keine probleme. Das wird auch der grund sein warum es niemand
gemerkt hat, für sowas ist dual-window mode besser geeignet.

[Pascal H. (pase-h)]

Hallo,
Danke für die neue Firmware. Ich muss jetzt dann gleich mal testen, ob 
der printout mit meinem HP ColorLaserJet funktioniert.
Nur eine Frage hätte ich noch an dich tinman:
Im Beitrag 
Beitrag "Re: Such Oszilloskop" hast du 
geschrieben, dass ein VGA Out keine Hexerei ist. Könntest du mir bitte 
die Modifikationen sagen, damit ich meinen Monitor am Scope anschließen 
kann?

Mfg
Pascal

[Thomas R. (tinman)]

Pascal H. schrieb:
> Nur eine Frage hätte ich noch an dich tinman:
> Im Beitrag
> Beitrag "Re: Such Oszilloskop" hast du
> geschrieben, dass ein VGA Out keine Hexerei ist. Könntest du mir bitte
> die Modifikationen sagen, damit ich meinen Monitor am Scope anschließen
> kann?


ja, anbei der schaltplan. Im prinzip nix grossartiges, lediglich
ein buffer und VGA2LCD module.

Der buffer an sich könnte auch weggelassen werden, ich habe aber
nicht so gerne wenn der S3C2440 gleichzeitig den FPGA und Display
treiben soll, das letzt was man braucht ist kaputte pins.
Man kann dafür line driver nehmen oder CPLD wie ich.

LCD2VGA module gibts jede menge, es muss 800x600 version sein
und am besten die LCD2VGA V2, siehe bild.

Die V1 (durchgestirchen auf dem bild) mag evt. auch funktionieren,
ich würde aber es nicht unbedingt drauf ankommen. Abgesehen davon
ist die V1 falsch designed (unnötige clock chips) und zu gross
für das DSO. Die V2 dagegen kann man wunderbar ablöten und
auf die buffer PCB draufpacken, VGA out natürlich dann mit
extra (abgeschirmten) kabel zur VGA buchse.

Die buffer PCB natürlich möglichst nah an S3C2440/Display.

Jumper 1 dient zur auswahl:
- VGA out immer an
- VGA out nur an wenn VGA kabel angeschlossen

EDIT: ich werde ein paar von den LCD2VGA V2 modulen bestellen, falls
jemand eins möchte bitte melden. Eine Buffer PCB werde allerdings nicht
extra machen, ich will VGA zusammen mit LAN auf einer PCB machen.

[Johannes R. (johannes_r29)]

Ich hätte Interesse an LAN+VGA.

Hab die 1005er Hardware, muss noch anrufen wegs Umtausch gegen 1007er.

MFG Johannes

[Peter S. (petesp)]

Thomas R. schrieb:
> Anbei die neueste firmware für Hantek / Tekway DSOs
>
> Änderungen zur 111124.0:
>
> + USB drucker/printout (HP) implementiert
> + Trigger fixpoints verbessert (DC/AC/LH/HF/NR verschiebung)
> - Digitale Filter sind jetzt komplett ohne funktion
> (um keine verwirrung zu stiften solange bis die nicht gefixt sind)
> - debug code entfernt (ist also keine test firmware wie 111124.0)

Hallo Thomas. Eine Frage, ist die Firmware noch kompatibel zu meiner 
Tekway DST1102B (0 x 555583e8 = hw0) Hardware? Oder gibt es da 
Limitierungen?

Gruss Peter

[Thomas R. (tinman)]

Peter Sprenger schrieb:
>
> Hallo Thomas. Eine Frage, ist die Firmware noch kompatibel zu meiner
> Tekway DST1102B (0 x 555583e8 = hw0) Hardware? Oder gibt es da
> Limitierungen?
>
> Gruss Peter

Hallo Peter,

ja hw0 wird noch full supported.

[Thomas R. (tinman)]

übrigens, es mag vorkommen das diese universal firmware updates
sich nicht installieren lassen auf geräten mit ältere firmware.

Es liegt daran das die universal updates ein "backdoor" benutzen
den Hantek/Tekway im April 2011 eingebaut haben um weniger
firmware-update versionen produzieren zu müssen.

Wichtig ist auch das nur eine dst**** datei auf dem USB stick
sich befindet, an sonsten bricht der update ab.

[Pascal H. (pase-h)]

Thomas R. schrieb:
> EDIT: ich werde ein paar von den LCD2VGA V2 modulen bestellen, falls
> jemand eins möchte bitte melden. Eine Buffer PCB werde allerdings nicht
> extra machen, ich will VGA zusammen mit LAN auf einer PCB machen.

Ich hätte ggf. auch interesse an einen LCD2VGA Modul. Wieviel würde denn 
eine Platine kosten, und würdest du die Platine auch fertig bestückt 
verkaufen?

Mfg
Pascal

[Oliver (Gast)]

Hallo,

mir ist da gerade ein Bug in der aktuellen Firmware 111202.0 (org) 
aufgefallen. Die Frequenzmessung scheint fehlzuschlagen, wenn im 
Menüpunkt 'Aquire' der Peak-Modus eingestellt ist. Anbei mal eine 
Messung des 1kHz Testsignals.
Je nach eingestellter Zeitdivision ergeben sich hier völlig 
unterschiedliche Frequenzen. Die Triggerfrequenz stimmt jedoch immer.

Viele Grüße,
Oliver

[Thomas R. (tinman)]

Oliver schrieb:
> Je nach eingestellter Zeitdivision ergeben sich hier völlig
> unterschiedliche Frequenzen.

Oli,

das muss ao sein weil die sample rate dadurch verändert wird und mal 
mehr
mal weniger tatsächlich "gesehen" wird, natürlich auch aliasing
und sonstige dreck effekte haben einen einfluss

Was peak detect angeht, siehe user manual:

Peak Detect: In this acquisition mode, the oscilloscope gets the maximum 
and minimum values of the input signal over each sample interval and 
uses these values to display the waveform. In this way, the oscilloscope 
can acquire and display those narrow pulses that may have otherwise been 
missed in Normal mode. However, noise will appear to be higher in this 
mode.

...

In certain circumstances, to display a noisy signal on the oscilloscope 
and to get its details, you may follow the steps below to analyze this 
signal ... 3.  Push the Peak Detect option button ...


Auf deutsch, peak detect mode ist sinnvol um den noise anzuzeigen,
ergo das was die measure zeigt (da es berechnet wird anhand von den
sample daten) "verzerrte" ergebnisse durch den noise anteil.

Der freq. counter (die anzeige unten) zeigt die tatsächliche
(trigger) frequenz.

Über die tatschächliche genaugkeit/sinn der frequency anzeige
im peak modus kann man evt. streiten, man darf aber die peaks
die mitgemessen werden nicht vergessen - so sieht das bei mir aus.

[Alex (Gast)]

Hallo,
mein Handtek ist nach langem warten heute nun auch endlich eingetroffen.
nach einem kurzen Test musste ich es aber erst mal aufschrauben, um den 
Lüfter bis auf weiteres totzulegen, da er doch schon enorme Geräusche 
macht.

Dabei ist mir folgendes aufgefallen:
Im gegensatz zu den Bildern hier besitzt das Mainboard meines Oszi schon 
die Lötstellen für einen RJ45-Anschluss (siehe Bild). zusätzlich gibt es 
auch noch die Kontakte für Lautsprecher und Micro Buchsen (laut 
Beschriftung auf dem Board)

[Thomas R. (tinman)]

Alex schrieb:
> Dabei ist mir folgendes aufgefallen:
> Im gegensatz zu den Bildern hier besitzt ..

nein nein, das passt schon, das ist die letzte hardware revision hw1007.

Hier und auf eevblog gibts einige bilder, hw0 ist zu erkennen am
i/o port mit 2mm pitch, hw1005 hat 1.27mm pitch am i/o header und
sieht ähnlich wie deine - hat aber jtag stecker an anderen stelle.
Deine, also hw1007 hat zusätzlich noch einen auschnitt in der PCB
damit man die i/o - was auch immer buchse da anschrauben kann - die
war/ist für LA option geplannt. Ob die LA option allerdings in den
B/BM/BMV eingebaut wird weiss ich nicht, nutzlich ist allerdings
schon das man da eine buchse anschrauben kann.

[Alex (Gast)]

Ich mein eigentlich die nichtbelegten Lötstellen links und rechts der 
USB-B Buchse.
Evtl. könnte man ja dort eine RJ45 Buchse einlöten, die Frage ist nur 
wie weit diese Anschlüsse auf dem Board schon verbunden sind. Die 
Vorwiderstände der LED's sind ja so wie es aussieht noch nicht verbaut 
aber die sind auch nicht unbedingt notwendig da sie ja nur Status LED's 
sind

[Thomas R. (tinman)]

ja die lötstelen, bzw nicht bestücktes LAN ist seit hw1005 da.
Alleine die RJ45 buchse reicht nicht, es muss noch ein DM9000EP
über den langen 1.27pitch i/o port angeschlossen werden - natürlich
entsprechend adressiert.

[Marc (Gast)]

Hallo,

wäre es möglich, dieses Oszilloskop als Quelle für GNU Radio zu 
konfigurieren?
Die normale Hardware dafür ist mir zu teuer, und so ein DSO hat doch 
eigentlich alles was nötig ist, oder?

http://gnuradio.org

http://cre.fm/cre087

http://www.youtube.com/results?search_query=GNU+Radio&oq=GNU+Radio&aq=f&aqi=g1&aql=&gs_sm=e&gs_upl=2361l10216l0l23915l11l11l1l5l6l0l292l1181l0.1.4l5l0

[Thomas R. (tinman)]

Marc schrieb:
> Hallo,
>
> wäre es möglich, dieses Oszilloskop als Quelle für GNU Radio zu
> konfigurieren?
> Die normale Hardware dafür ist mir zu teuer, und so ein DSO hat doch
> eigentlich alles was nötig ist, oder?
>

nein, nicht alles. VCXO, mischer, filter sind nicht vorhanden, die
müssetn aussen auf sep. PCB dann sein. Die ADCs sind auch 8bit
und keine 14-16bit, gut sind mehrere man kann also etwas tricksen.
Dank des schaltplans den ich erstellt habe kann man dann anfangen
zu coden - neues FPGA design angepasst für GNU Radio zwecke,
dann software für ARM9 ... ja möglich ist alles aber die zeit
die man dafür investieren muss (und evt. umbau kosten + ext. PCB
kosten) würden auch beim 1EUR stundenlohn die GNU Radio hardware kosten
beim weiten übersteigen. Sowas lohnt nur wenn man keine andere
möglichkeiten hat (z.b. einsamme insel, kein bot, keine andere
sachen als ein DSO und zwei-drei alte radios vorhanden)

[Marc (Gast)]

> nein, nicht alles. VCXO, mischer, filter sind nicht vorhanden
VCXO und Mischer braucht man ja auch nur bei hohen Frequenzen.
Bei niedrigen Frequenzen bis zu einigen 10kHz kann man ja auch alles per 
Software machen.
Für höhere Frequenzen kann man sich ja einen aktiven "Tastkopf" basteln, 
der das Signal erst filtert und runtermischt.

> Die ADCs sind auch 8bit und keine 14-16bit
Ok, das ist sicher problematisch.

> neues FPGA design angepasst für GNU Radio zwecke,
> dann software für ARM9 ...
Ich würde eigentlich eine Lösung bevorzugen, bei der das Oszi nicht 
verändert wird, bis auf zusätzliche Software auf dem ARM evtl.

Man müsste doch eigentlich nur alle Werte per USB direkt an den PC 
übertragen. Bei 100kS/s wären immerhin schonmal 50kHz drin.
Aber wahrscheinlich kann man dem Scope gar nicht beibringen wirklich 
kontinuierlich abzutasten, oder?
Also, der schreibt erst seinen Speicher voll, macht dann irgendwelche 
Auswertungen, stellt das dann auf dem Display dar, und fängt dann erst 
wieder an zu Samplen?

Aber ich lese gerade, dass Harald Welte im Moment an einer neuen 
Hardware arbeitet:

"OsmoSDR - an upcoming small form-factor, inexpensive USB SDR. Not big 
and expensive like USRP or real "professional" solutions, but also not 
as weak as the ultra-narrow-band funcube dongle. I wasn't involved in 
the hardware design, but have volunteered to take care of the firmware 
development for the Atmel SAM3U micro-controller inside."

Hört sich interessant an, bin mal gespannt was da kommt...

[Thomas R. (tinman)]

für Tekway benutzer - nciht wundern, deren alte websites
(tekwayins.net/com) sind abageschaltet. Die sind jetzt unter
www.tekway.net erreichbar.


Übrigens, bin gerade dabei den USB protokol zu analysieren.
Von den 213bytes DSO settings nachricht ~ 1/3 schon fertig
analysiert/dokumentiert.

[Pascal H. (pase-h)]

Hallo,
ich hätte mal eine Frage zur Hantek Firmware:
Wäre es möglich eine Funktion zum analysieren von Bussignalen (I²C, 
RS232, ggf SPI - clock könnte man ja auf den ext. Trigger legen) zu 
implementieren? Zur Not könnte ich auch noch die PC Software benutzen, 
die funktioniert nur nicht bei mir, und ich müsste einiges vom Bastel- 
ins Arbeitszimmer räumen.

Wie sieht es denn mit den LCD2VGA Modulen mit LAN aus(Preis/ Bausatz 
oder Fertig/...)? Ich hätte nämlich Interesse an einen Modul.

Mfg
Pascal

[Patrick (Gast)]

Pascal H. schrieb:
> Wäre es möglich eine Funktion zum analysieren von Bussignalen (I²C,
> RS232, ggf SPI - clock könnte man ja auf den ext. Trigger legen) zu
> implementieren?

Direkt in die Firmware? Halte ich für sehr sehr aufwendig, da der 
Quellcode der Firmware nicht vorhanden ist und man recht heftig 
rumhacken müsste...

> Zur Not könnte ich auch noch die PC Software benutzen,
> die funktioniert nur nicht bei mir, und ich müsste einiges vom Bastel-
> ins Arbeitszimmer räumen.

Das USB-Protokoll ist recht simpel und kann mit einem Sniffer recht 
leicht reverse-engineered werden. Wenn du da mit einer eigenen Software 
die Samples ausliest (libusb), kannst du die sicher gut 
weiterverarbeiten.



Übrigens: Den 200-MHz-Hack kann man auch ohne Öffnen des Gehäuses und 
Löten durchführen. Im EEVBlog-Forum gibt es eine kleine Anwendung, die 
das Scope in den 200-MHz-Modus versetzt. Dazu muss es nur per USB 
angeschlossen sein.

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

[Thomas R. (tinman)]

Pascal H. schrieb:
>
> Wie sieht es denn mit den LCD2VGA Modulen mit LAN aus(Preis/ Bausatz
> oder Fertig/...)? Ich hätte nämlich Interesse an einen Modul.
>

Preis ist von der Anzahl der bestellungen abhängig, bis jetzt habe
lediglich 8 "vorbestellungen".

[Marc (Gast)]

> Übrigens: Den 200-MHz-Hack kann man auch ohne Öffnen des Gehäuses und
> Löten durchführen.

Wie, Öffnen und Löten?
Ich habe das so verstanden, dass man lediglich Thomas Firmware Upgrade 
"firmware_111202.0.zip" einspielen muss. Ist dass denn nicht richtig?
Löten sollte nach meinem Verständnis nur erforderlich sein, wenn man 
auch noch die letzten 15MHz Bandbreite rausholen will.
Und das nimmt einem auch die Anwendung aus dem EEVBlog nicht ab.
Ich überlege mir das Scope zu kaufen, und ein unproblematischer Hack 
währe mir schon wichtig.

Es gibt jetzt übrigens mehr Informationen zum OsmoSDR, für die, die es 
Interessiert:
http://sdr.osmocom.org/trac/
Sieht mir nach einem vielversprechenden, simplen Design aus. Mehr als 
250€ wird das im Shop wohl hoffentlich auch nicht kosten.

[Thomas R. (tinman)]

Marc schrieb:
>> Übrigens: Den 200-MHz-Hack kann man auch ohne Öffnen des Gehäuses und
>> Löten durchführen.
>
> Wie, Öffnen und Löten?
> Ich habe das so verstanden, dass man lediglich Thomas Firmware Upgrade
> "firmware_111202.0.zip" einspielen muss. Ist dass denn nicht richtig?


nein, meine firmwares machen keine bw änderungen. Das muss schon jeder
benutzer für sich machen, was über eins dieser wege möglich ist:
- selbstgebautes firmware die dann änderungen vornimmt
- manuell über UART auf shell verbdinden und dateien editieren
- backup über JTAG, restore auf einem dev board, änderungen da
vornehmen und dann so eine firmware über JTAG zurück auf DSO

Neu (das was Patrick meinte) ist die möglichkeit über des USB port,
wie hier beschrieben:

Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

Patrick hat ein kleines tools geschrieben die demnentsprechend
das debug protokol benutzt um remote shell befehle auszuführen
(die wiederum die bw ändern).


Marc schrieb:
> Löten sollte nach meinem Verständnis nur erforderlich sein, wenn man
> auch noch die letzten 15MHz Bandbreite rausholen will.

ja, das bleibt auch weiter so, per software kann das DSO nicht
die widerstände ändern (sollte aber eigentlich möglich sein,
chinesische produkte können doch alles^^)

Apropos "können", Hantek hat neue PC software version rausgebraucht,
ist immer noch "bescheiden", allerdings ist der LAN support endlich
für die DSO5xxxxB/Tekway DST1xxxB eingebaut.

[Dirk (Gast)]

Hallo Leute,

habe ein DSO5102B und es gibt bei Hantek auf der Seite die Firmware 
111226.1
hat einer Erfahrungen damit was sich da getan hat bzw. was geändert 
wurde?

MFG Dirk

[Thomas R. (tinman)]

Dirk schrieb:
> habe ein DSO5102B und es gibt bei Hantek auf der Seite die Firmware
> 111226.1 hat einer Erfahrungen damit was sich da getan hat bzw.
> was geändert wurde?

- jede menge (über 1tsd kleine änderungen) kleinigkeiten in dem code
(so sachen wie leider funktionierende abfrage ob FPGA vorhanden und
config geladen - seit 2 jahren konnte ich ohne FPGA die firmware testen,
jetzt meckert die) geändert/angepasst a-s ob da jemand "langeweile
hätte".

-fast komplett überarbeitete timebase, fine timbase, dithering,
equ sampling routinen. An der timebase sieht man direkt
das die "max zoom reached" message ist jetzt weg - warum auch immer -
zoom bleibt aber wie gewollt stehen beim maximum wie gewollt.
Ich fangs besser mit der msg, keine ahnung was das soll.
Was man nicht direkt merkt ist allerdings die speichertiefe.
Bis jetzt hat HanTekway (abgeseehen vom 8/4/2nsDIV im 4k mode
wo es mit 1GSs gesammpled wird und tatsächlich 4ksamples gespeichert)
immer statt 4000point einfach 3200 gespeichert, oder im long memeory
32000, 400k/800k - jetzt sind es vollen 4k/40k/512k/1M so wie es sich
gehört. Der fehler lag an den krummen samplerate - 800MSs/400MSs
wärend hälfte der timebase routinen auf 1GSs/500MSs angepasst waren.
Das ist zwar nett das die endlich den ganzen speicher zu verfügung
stellen, schade aber das die soch doch nciht entschieden habe
die samplerate zu erhöhen (so wie ich die letzte monate immer
gepatched habe) - ok das ist den hw1005 fair gegenuüber, trotzdem
schade. Equ sampling kann ich schlecht sagen ob es besser ist da die
von mir verwendete FPGA design sowieso viel weniger jitter hat
(test version von Tekway). Entweder durch die veränderte dithering
oder sonst was ist die refresh rate nicht mehr so schnell wie es einmal
war - stellt man auf 50 bewegt sich das bild wie mit 30 vor dem update.
Habe testweise patched auf höhere update rate, hat aber nur etwas
gebracht, wenn ich ncoh weiter erhöhe verlagsammt sich alles drastisch
(weil reste vom alten buffer bleiben). Gut, wenn das so bleibt ist auch
nciht so wild da dadurch die wfrm/s steigt (beim 50 war sie immer
langsammer als beim auto oder 30 durch die cpu auslasstung).

- neu ist "Bode Assistent", eigentlich sollte es Bode Diagram sein,
vom hocker hat mich die implementierung allerdings nicht gerissen.

- 2Mpoint/Video für die BM/BMV modelle sind jetzt auch anscheinend
in der firmware drin. Diese funktionen sind logischerweise disabled
auf den B modelen. Ich kann die zwar verfügbar machen, dafür braucht
man aber physikalisch mehr speicher und anderes kernel/root fs.
Ich mache irgendwann eine anleitung verfügbar. Bis jetzt mag ich die
2Mpoints nicht da z.b. cvs export/import nicht gehen.

- die digitalen filter sind immer noch nicht wieder verfügbar.

Das sind sachen die ich auf die schnelle gesehen habe.

[Alex (Gast)]

also bei mir scheine die filter jetzt freigeschaltet zu sein (siehe 
bilder)

was ich aber festgestellt habe, ist dass nach jedem neustart meine 
einstellungen verloren gehen und ich jedesmal die sprache wider auf 
deutsch umstellen muss

[Dirk (Gast)]

Na Super :-(

habe die Software 111226.1 (ohne Problem) aufgespielt und wollte mal das 
Bodeding testen.
Hatte beide Tastköpfe mit dem 1kHz ref Takt des Oszi verbunden.
Bin dann in das Bode Menü und habe die Messfunktion aktiviert.
Kurze Zeit später verschwand der ref. Takt vom Schirm und das Oszi 
reagierte nicht mehr auf Tastendrücken.

Also Resatart.

keine Besserung, das Oszi fährt hoch und zeigt mir das Triggermenü aber 
auf dem Schirm sind keine Linien zu sehen. Laut LEDs (der Kanäle) wären 
aber beide aktiv.

Das OSzi reagiert nicht auf Tastendruck egal welche Tasten ich drücke.
Die Run/Stop Taste leuchtet grün und Autoset leuchtet gelb. Weiterhin 
leuchten die beiden Kanal-Menüknöpfe.

Was ist das Problem liegt es an der Software oder ist ein Hardware 
defekt zu vermuten? Was kann ich noch testen gibt es eine Tastenkombi 
die man beim Booten drücken kann um was zu sehen?

MFG
Dirk

[Thomas R. (tinman)]

Alex schrieb:
> also bei mir scheine die filter jetzt freigeschaltet zu sein (siehe
> bilder)
>

ja, du kannst alle parameter in menus ändern, bedeutet aber gar nicht
das die filter tatsächlich etwas machen. Wenn du nicht glaubst
teste es mit x-belibigen signal/filter einstellungen.

Die erklärung dafür sehe ich im code, die zuständige event
procedure "_proc_digital_filter" hat nur platzhalter
für jeweilige filter statt die jumps zu den low/high/bandpass/bandstop.

Alex schrieb:
> was ich aber festgestellt habe, ist dass nach jedem neustart meine
> einstellungen verloren gehen und ich jedesmal die sprache wider auf
> deutsch umstellen muss

sei doch froh! English ist DIE sprache für EEs.

Allerdings werden chinesen/japaner nich so happy sein, da deren
sprachen auch nciht gespeichert werden. Lizensierung ist es nicht,
habe meins testweise auf chinesische lizenz umgestellt
(versteckte einstellung), speichern tut er trotzdem alles bis auf
sprache / gui farbe.

Mich stört es nicht, speziel weil alle englishe dialoge/nachrichten
korrigiert sind und kaum noch fehler/wortbrüche gibt.
Bei anderen sprachen stellt die fw auf UTF8, da wird sofort wieder alles
verschoben und sieht grauenhaft aus. Auch die halben übersetzungen
waren unmöglich, wobei ich sehe gerade das jemand sich die mühe
gemacht hat und auf deutsch irgendwie übersetzt, toll, nur leider
nicht gut genug. Sachen wie "A. Lösch." sagen mir gar nix, da war noch
platz für z.b. "Alles lösch.", an SEHR vielen stellen gibts noch platz
um ganze wörter zu bilden (da beim UTF8 die buchstaben schmaller sind)

[Thomas R. (tinman)]

Dirk schrieb:
> Na Super :-(
>
>
> Was ist das Problem liegt es an der Software oder ist ein Hardware
> defekt zu vermuten? Was kann ich noch testen gibt es eine Tastenkombi
> die man beim Booten drücken kann um was zu sehen?
>

eher an gespeicherten unsinn nach dem absturz, da hilft nur
die default setting taste oder über uart die /param/sav/run1kb* löschen.

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.

[Dirk (Gast)]

@Thomas R.
Danke für dein Tool, leider passiert bei mir nix...
Ich drücke den Button und es steht da "doing ugly things" und das wars 
dann.

Doch die HW im Eimer :-( ???

MFG
Dirk

[Thomas R. (tinman)]

und nach dem reboot auch nix ? Einfach button drücken und danach falls
dein scope nix tut sofort abschalten - naja inerhalb den nächsten 10 
sekunden an sonsten werden die kaputten settings die immer noch gelade
sind wieder gespeichert.

[Dirk (Gast)]

Ok habe die /param/sav/run1kb* gelöscht wackelt wieder
puhh wisch :-)

nochmals vielen Dank an Thomas R.

MFG
Dirk

[DMS (Gast)]

Hallo zusammen,

mal eine Frage an die DSO - Linux Gurus.
Wäre es möglich an den USB Anschluss einen Logic Analyser anzuschließen 
und die entsprechende Software mit auf das DSO zu instalieren?

Man könnte dann die Tasten vom DSO nutzen um den LA zu steuern und den 
Schirm zum Anzeigen der Signale.

Wäre das möglich oder ist das zu viel Aufwand den man betreiben müsste?

Gruß
DMS

[Thomas R. (tinman)]

DMS schrieb:
> Wäre es möglich an den USB Anschluss einen Logic Analyser anzuschließen

ja, aber obacht - das ist USB 1.1, es wird also zu langsam sein
für LAs ohne speicher (wie z.b. Logic von Saleae)

> und die entsprechende Software mit auf das DSO zu instalieren?

ehm, jetzt wird spannend. Welcher LA wird mit einer ARM software
ausgeliefert?

Klar, es gibt Sigrok, das könnte also gehen mit einigen LAs,
ich kenne aber keinen LA der schon vom haus eine ARM UI sw hat.

>
> Man könnte dann die Tasten vom DSO nutzen um den LA zu steuern

ja, die tasten werden vom FPGA gesteuert, das design wird beim booten
geladen noch bevor dso.exe gestartet wird (in rcS, /sendspi f dn.rbf)
Man kann also gleich danach auf die tasten zugreifen.

> und den
> Schirm zum Anzeigen der Signale.

ja klar, über framebuffer

>
> Wäre das möglich oder ist das zu viel Aufwand den man betreiben müsste?
>

task 1 - dauer 2 tage: Passendes LA finden. Geeignet sind alle LAs wo
das protokol bekannt ist, mit internen speicher und möglichst viel
hirnschmalz im LA selber - reine software gesteuert/basierende LAs sind
overkill hier. Sowas wie sump, minila oder owls sind bestens geeignet.
Es schadet nicht die dokus/sources zu studieren um zu prüfen wie
viel hirnschmalz schon drin und wie viel in sw stecken muss/ist.

task 2 - dauer bis 2 tage: Die dso.exe analysieren und rauszufinden
wie die tasten ausgelesen werden (welche memory adresse). Am besten
dazu die dso.exe disassembleiren (gabs auch hier fertig zum download),
nach get_key_code oder scan_fpga_key_buf suchen und analysieren.
Hilfreich sind auch der /dso/driver/dso-fpga.ko treiber, die /fpga.exe
die schon cool genug ist um FPGA zu steuern, die /dso/app/getdata kann 
ebenfalls benutzt/analysiert werden.

task 3 - kleine app schreiben (QT, GO, C) die einfach auf multiknob
drehung reagiert (um z.b. buton focus zu wechseln) und auf knob klick
um dann den selektierten button zu wählen (DSO / LA).
Diese app wird dann statt dso.exe in der rcS geladen und starten je nach
dem was der user gewählt hat eintweder DSO oder LA app.
Task dauer 8+2 std (die 8std für die QT/C crossplatform umgebung)

task 4 - die LA app schrebien - task dauer 1 woche bis 2 jahre (dann
vergeht die lust und man kauft neues DSO). Wenn der gewähler LA schon
viel logik in der hardware hat, wird die app einfacher werden.
Trigger setzen, clock setzten, scharf stellen und run -> daten lesen,
diese tasks kann man sogar locker per script machen. Das meiste
hirnschmalz wird also für die UI gehen, zoom, multifenster usw.


Das ganze ist also schon machbar, USB ist zwar nicht die schnellste 
lösung
(schneller könnte sein über GPIO angeschlossenes LA abzufragen), dafür
aber mhr universel.

Die aktuellen DSO haben kernel 2.6.13, man sollte also auch dafür
entwickeln! Die neueren modele BM/BMV werden/sind wohl mit 2.6.30.4
ausgeliefert, mann kann also etweder hoffen das ich eine kernel/root fs
update mache (Hantek/Tekway wird es nciht tun) und dann für den neueren
kernel entwickeln oder nicht warten/hoffen und für den älteren kernel
schon anfangen/komplett machen.

[Thomas R. (tinman)]

tjo, Hantek hat mal wieder "schnell" reagiert und die firmware
upgedated, jetzt sollen die spracheinstellugnen nicht mehr
gelöscht werden nach reboot ... aber erst lass mich sagen was
drin/nicht drin:


neu:
- horizontal position coarse/fine umschaltung, "fine" ist eigentlich
das was immer vorhanden war, schaltet man auf coarse ist ein DIV = eine
positionsänderung auf dem rotary encoder. Sehr gute ergänzung, speziel
wenn man die lange waveform herumscrollen will.


neu:
- avg sampling für long memory möglich. Ich habe mal hochgerechnet das
dies möglich sein muss und HanTekway drum gebetes es zu implementieren.
Es sind allerdings nur 4/8/16 avarages mit 40ksamples machbar
(single und dual channel).
Im FFT, obwohl die 40k nicht ausgegraut sind im avg mode sind
die es denoch nciht möglich da grundsätzlich FFT keine long mem
unterstüzt.


kaputt gemacht:
- tracking cursor, erst rastet nciht ein, dann nach reset position
bleibt an der waveform zwar hängen, ändert man die freq./waveform
rastet er wieder nciht ein - also kaputt.
Im FFT mode läuft allerdings der tracking cursor ohne probleme,
wird also "nur eine kleinigkeit" sein, ja genau, wie immer.


gefixt (angeblich):
- sprachenumschaltung. Tja, ich sehe zwar im code das die 
sprachumschaltung irgendwie geändert ist in vergleich zu der
version auf hantek website, nutzt denoch aber nix, es kommt
immer wieder english nach dem reboot. Was evt. sein kann das
HanTekway schon so weit in deren köpfen sind das die einfach die
vorhandennen DSOs vergessen haben -> mittlerweile werden einige
features in EEPROM gespeichert, dazu gehört mittlerweile language
license (damit 0815 china shops keine china DSO verisonen verkaufen
können mit englishen fronpanel sticker - ich weiss da wird gleich jeder
meckerns, der grund ist aber die CE/WEEE und die tatsache das 
chinesische
versionen etwas billiger gebaut sind).
Wobei, es kan natürlich sein das mein EEPROMs diese infos icht mehr
haben, ich habe die irgendwann formatiert nach dem ich unsinn
reinprogrammiert habe.


Bevor ich also gleich morgen früh da wieder anrufe BITTE
um bestätigung ob die eingestellte sprache nach dem umschalten/reboot
bestehend bleibt (möglichst vom hw1005, hw1007 benutzern)
Die version im Anhang sollte auf den meisten modelen
installierbar ** sein (laufähig auf allen)


**Es sieht aber so aus das HanTekway sch.. gebaut hat und manche
ältere firmwares patou den fw update verweigern, man muss dann
leider einmal per hand neuere fw kopieren - dso.exe und libs!!! -
ab da geht dann wieder alles 1A. Auf der shell äussert sich dieses
fehler meistens als "fehler beim entpacken" oder "zu wenig platz"
beim entpacken von dso.exe

[Alex (Gast)]

hallo,
ich hab eben mal die neue fw drauf gemacht.
die sprache bleibt wie bei der vorgängerversion nicht bestehen.
(ich hab bei mir hw1007 drin)

[Thomas R. (tinman)]

danke alex,

im anhang verbesserte version, tracking cursor geht wieder, 
spracheinstellungen lassen sich speicher in setups und aktuellen
einstellungen und bleiben jetzt auch drin nach reboot.

[Alex (Gast)]

hallo,
ich hab eben das aktuelle update drauf gemacht und es scheint zu 
funktionieren.
mir ist aber dabei ein fehler aufgefallen, der zwar nich gravierend ist 
aber beim nächsten update mit behoben werden sollte.
im 200µs bereich geht geht die speichertiefe von 1mb nicht einzustellen!
in allen anderen bereichen ist dies aber möglich.

[Thomas R. (tinman)]

das ist kein fehler, ist absicht seit der ersten firmware.
Den grund dafür habe nie ganz verstanden, es hat aber etwas mit
sample buffer, display buffer und der skalierung zu tun.

Ich denke zwar schon da irgendwie das lösbar sein müsste, aber ehrlich
gesagt 1- stört mich nicht so sehr, 2- angst das die gleich die halbe
firmware kaputt machen :)

[Alex (Gast)]

wie schon gesagt, so gravierend find ich das nicht.
ist mir aber das erste mal aufgefallen, deswegen hab ich es gepostet

[P. K. (dg4ek)]

Danke auch von mir Thomas,
FW läuft ausgezeichnet :)

Aber mal was anderes:
Wie schalte ich vom Doppelfenster wieder in den Normalmode um?

Gruss
Peter

[Thomas R. (tinman)]

F7 um dual/single window umschalten.

Im dual kann man zwischen den fenstern mit F1 im horizontal menu
oder viel einfacher -> den horizontal knob einfach drucken -
dann schaltet er im hintergrung um zwischen beide fenstern.

[Dirk (Gast)]

F7 ?

[Thomas R. (tinman)]

Dirk schrieb:
> F7 ?

ja F7.

Thomas R. schrieb:
> .. viel einfacher -> den horizontal knob einfach drucken -
> dann schaltet er im hintergrung um zwischen beide fenstern.

und damit meine ich den timebase drehknopf - den kann man auch drücken.

[Dirk (Gast)]

Hallo,

habe auch noh eine Frage.

Warum kann man bei der Speicher Tiefe nur 4k, 40k, 512k und 1M auswählen
und nicht die 20k?

MFG
Dirk

[Thomas R. (tinman)]

Die 20ksamples sind eigentlich was ein Tekway DST3xxxB (siehe anhang)
max. machen kann, der grund ist der fehlende externe SRAM und FPGA 
grösse
(414kbits FPGA speicher '/' anzahl ADCs '/' ADC breite)


Im prinzip beim jetzigen FPGA design sind in dem Tekway DST1xxxB/
Hantek DSO5xxxBxx also maximal 6624points beim 1GSs möglich.
Würde allerdings HanTekway das design ändern und den externen
speicher mitbenutzen so könnten wie beim Rigol E z.b. 16k möglich
sein. Eigentlich vom anfang an hat Tekway mit "4k, 16, 40k ..."
geworben, daher habe ich HanTekway auch gefragt ob das implementiert
werden kann - entweder als 6k mit 1GSs, oder 8k, oder 16k (mit je max.
möglichen geschwindigkeit) oder 20k mit 400MSs.
Es ist auf jeden fall auf der todo liste gelandet, wie und ob
überhaupt das umgesetzt wird weiss ich aber noch nicht.
Glücklicherweise wird die todo liste tatsächlich abgearbeitet, einer
der letzten punkte auf der liste war avg. sampling im long mem mode,
das ist jetzt auch implementiert.

[Patrick (Gast)]

Bei allen Problemen: Ich finde es super, dass die Firmware aktiv 
weiterentwickelt wird und in kurzen Abständen neue Releases kommen. Wie 
viele (nicht nur China-)Produkte habe ich schon besessen, die nervige 
Bugs hatten und trotz Möglichkeit zum Firmware-Update nicht ein einziges 
Update erhielten. Und hier bekommt man ab und zu sogar noch neue 
Funktionen. Ich find's gut ;-)

[Strobo (Gast)]

Für was sind eigentlich die unbestückten Bauteile neben der Batterie?
Hat da einer eine Ahnung?

[Thomas R. (tinman)]

Strobo schrieb:
> Für was sind eigentlich die unbestückten Bauteile neben der Batterie?
> Hat da einer eine Ahnung?

der ssop28 ist ein UDA1341TS, so16 ist 74hc4053 der als USB mux
zwischen 2ten unbestückten front usb host port oder hinteren usb
device umschaltet - wobei der S3C2440 es auch dementsprechend
initialisiert werden muss, der so8 ist ein kopfhörer verstärker
(tda irgendwas).

Wenn ich irgendwann mit dem hw1007 schaltplan fertig bin wird man alle
diese unbestückte sachen sehen.

[Lukas K. (carrotindustries)]

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

[Thomas R. (tinman)]

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.

[Alex (Gast)]

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

[Patrick (Gast)]

Ich finde einen Videoplayer in einem DSO einfach nur hohl.

[Thomas R. (tinman)]

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.

[Yatko J. (denim)]

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

[Yatko J. (denim)]

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

[Thomas R. (tinman)]

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)

[Nils S. (kruemeltee)]

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?!

[Yatko J. (denim)]

> Spamschutz für rar Dateien?!

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

[Yatko J. (denim)]

@ 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 ?

[Thomas R. (tinman)]

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

[Nils S. (kruemeltee)]

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

[Roland (Gast)]

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

[Yatko J. (denim)]

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

[Thomas R. (tinman)]

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.

[Pascal H. (pase-h)]

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

Mfg
Pascal

[Thomas R. (tinman)]

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.

[Horst (Gast)]

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?

[Thomas R. (tinman)]

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.

[Tim R. (mugen)]

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?

[Carsten S. (dg3ycs)]

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.

[Tim R. (mugen)]

@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.

[Tim R. (mugen)]

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

[Thomas R. (tinman)]

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.

[P. K. (dg4ek)]

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

[Thomas R. (tinman)]

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.

[Tim R. (mugen)]

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.

[Thomas R. (tinman)]

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 ...)

[Tim R. (mugen)]

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.

[Tim R. (mugen)]

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.

[Carsten S. (dg3ycs)]

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

[P. K. (dg4ek)]

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

[Thomas R. (tinman)]

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)

[Yatko J. (denim)]

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.

[Thomas R. (tinman)]

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

[Tim R. (mugen)]

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.

[Tim R. (mugen)]

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.

[Carsten S. (dg3ycs)]

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

[Johannes R. (johannes_r29)]

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

MFG Johannes

[Tim R. (mugen)]

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.

[Johannes R. (johannes_r29)]

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

[Thomas R. (tinman)]

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.

[Thomas R. (tinman)]

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.

[Tim R. (mugen)]

@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. =)

[Pascal H. (pase-h)]

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

[Thomas R. (tinman)]

ü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"

[Tim R. (mugen)]

Uiii - So ein LogicAnalyser wäre schon was feines.

[Yatko J. (denim)]

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 :)

[Thomas R. (tinman)]

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.

[Pascal H. (pase-h)]

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

[Thomas R. (tinman)]

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!

[Thomas R. (tinman)]

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.

[Tim R. (mugen)]

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.

[Thomas R. (tinman)]

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.

[Peter D. (Gast)]

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

[Mike (Gast)]

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

[Thomas R. (tinman)]

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

[Thomas R. (tinman)]

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

[Mike (Gast)]

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

[Thomas R. (tinman)]

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.

[Christoph H. (christoph_b)]

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.

[Mike (Gast)]

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

[Christoph H. (christoph_b)]

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

[Pustekuchen (Gast)]

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.

[Peter D. (Gast)]

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

[Christoph H. (christoph_b)]

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?

[Thomas R. (tinman)]

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).

[Peter D. (Gast)]

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

[Pustekuchen (Gast)]

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.

[Pustekuchen (Gast)]

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?

[Christoph H. (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.

[Peter D. (Gast)]

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

[Thomas R. (tinman)]

neue fw version für Hantek/Tekway ist hier:

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

[Nils S. (kruemeltee)]

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.

[Thomas R. (tinman)]

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

[Tim R. (mugen)]

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.

[Alois N. (alois)]

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 ;)

[Thomas R. (tinman)]

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.

[Thomas R. (tinman)]

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

[Thomas R. (tinman)]

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).

[Alois N. (alois)]

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 ;)

[Thomas R. (tinman)]

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.

[Alois N. (alois)]

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.

[Thomas R. (tinman)]

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).

[Thomas R. (tinman)]

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.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

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.

[Thomas R. (tinman)]

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.

[Peter D. (Gast)]

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

[Thomas R. (tinman)]

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.

[Thomas R. (tinman)]

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.

[Peter D. (Gast)]

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

[Thomas R. (tinman)]

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 :)

[Peter D. (Gast)]

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

[Thomas R. (tinman)]

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 :)

[Peter D. (Gast)]

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

[Thomas R. (tinman)]

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).

[Peter D. (Gast)]

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

[Johannes R. (johannes_r29)]

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

[Mischmasch (Gast)]

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.