TEKWAY DST1xx2B Oszilloskop

das wars, alle remote kommandos die diese DSOs kennen sind dokumentiert:

http://www.mikrocontroller.net/articles/Hantek_Protokoll

Die debug meldungen :

0x00 FPGA Register lesen
0x42 FPGA Register beschreiben
0x45 Interpolation anpassungen
0x01 FPGA FIFO Inhalt auslesen

sind evt. nicht vollständig oder falsch beschrieben. Das liegt daran das 
bis jetzt Hantek keine informationen zu den debug meldungen rausgerückt 
hat (ich habe nochmal höfflich angefragt).

Denoch, jetzt schon liefern diese meldungen brauchbare daten bzw. 
reagieren entsprechend auf änderungen.

Die FPGA Register sind zwar nicht bekannt (die würde ich gerne von 
Hantek erfahren), man kann aber mit etwas arbeit die in der fw 
dissassembly finden (z.b. trigger setzen).


Es fehlen auch informationen zu der formatierung von den
DSO variablen aus den debug meldungen :

0x02 DSO Firmware Variablen auslesen
0x40 DSO Firmware Variablen schreiben

Man kann die evt. selber herausfinden (änderung vornehmen, 15sec warten 
bis die änderungen gespeichert werden und auslesen/zuordnen).
Was ich allerdings weiss ist das genau diee informationen firmware 
version abhängig sind (diese werte und die eigenen setups werden auch 
beim fw update gelöscht). Bei gelegenheit (falls Hantek keine 
informationen zuschickt) werde die alten fw versionen aufspielen, dumps 
von den variablen machen und vergleichen auf gemeinsamkeiten.

Peter Dreisiebner schrieb:
>
> Ich hoffe mein DSO hält solange durch, bis ich das alles vielleicht
> einmal in dem DSO-Tool umgesetzt habe :-)
>

hardwareseitig ist (eventuell) nur "0x42 FPGA Register beschreiben" mit 
vorsicht zu benutzen. Alle anderen fehler schiessen evt. ein paar 
dateien weg, aber die kann man schnell ersetzen :)

Eigentlich sind es nur display punkte die den postprocessed sampled 
entsprechen (die richtigen sample daten sind MÖGLICHERWEISE per FIFO 
read auslesbar, die sind afaik aber nciht post-processed, die display 
samples schon).

Die sample rate kannst du daraus sehr schwer bis gar nicht ableiten,
dafür braucht man die tatsächlichen daten samples.

Beispiel 200ns/div, laut deiner rechnung 200MSs, es sind aber 800.
Noch ein beispiel  - 8ns/div timebase. Sind immer, unabhängig von der 
speichertiefe immer 800 "samples", aber die sample rate im 4k modus 
1GSs, bei dir (hw 83e9) 500MSs und bei anderen mit hw 83e8 400MSs ;)
Übrigens 4k modus, eigentlich benutzt die firmware 20div intern, so 
ergeben sich auch min 800punkte und maximal 4000punkte beim 4k speicher.
Dies gielt auch für andere speichertiefen.

Die display samples sind sample rate mehr oder weniger unanbhängig, 
sieht man auch in deiner xls - die ändern sich natürlich je nach anzahl 
der DIV auf dem display aber das ist auch so gewollt - weil es display 
samples (dots) sind. Du kannst ja auch gerne die firmware abfragen - 
utility, page2/3, sys staus. Da steht auch "display dots" <- dise werte 
sind aber 20 DIV bezogen. Und ja, es sind maximal 800000 dots, um 
1000000 zu bekommen muss die timebase ratio ganz anders aufgebaut. Ich 
kann dir gerne eine firmware zuschicken (mit 1:2:5 ratio),da bekommt man 
auch 1M punkte und keine 800k. Das wird aber auch früher oder später bei 
alles Hantek/Tekway DSOs so sein (ich meine die 1:2:5 ratio). Die 
möchten nicht mehr verarschen, weder mit sample punkten noch mit sample 
rate (weil es war eine verarsche zu sagen 1GSs, 500MSs im dual oder long 
mem während es nur 400MSs sind - eigentlich sollte jder der 83e8 hat 
update auf 82e9 bekommen ... oder neues gerät kaufen ? K.a. was die so 
denken.).

Für die samplerate braucht man die anzahl der kanäle, die timebase, 
speichertiefe, FPGA clock werte und firmware version :)

Anzale der kanäle ist klar, auch speichertiefe und timebase sind 
vorhanden in den einstellungen daten. Die firmware version ist wichtig 
weil die 83e8 modele mit z.b. max 400MS/s in den 40k bis 1M samplen 
während die 83e9 mit max. 500MS/s.

FPGA clock (eigentlich nur die information ob mit 125MHz oder 100MHz 
sampled wird) braucht man evt. auch (per FPGA register lesen 
möglicherweise sichtbar), man kann aber auch hardcoden anhand was die 
aktuelle firmware (auf dem jeweiligen hw model .. evt. als checkbox in 
der software oder per dso variable auslesen) macht.

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

benutze suchfunktion

Philipp schrieb:
> Thomas R. schrieb:
>> Philipp schrieb:
>>> wozu gibt es bei den dingern platz für ein audio chip?
>>
>> benutze suchfunktion
>
> in dem trhead gibts nur 2 oder 3 beiträge mti dem wort audio und da
> steht nichts interesanes

Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"
Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

Thomas R. schrieb:
>
> FPGA clock (eigentlich nur die information ob mit 125MHz oder 100MHz
> sampled wird) braucht man evt. auch (per FPGA register lesen
> möglicherweise sichtbar), man kann aber auch hardcoden anhand was die
> aktuelle firmware (auf dem jeweiligen hw model .. evt. als checkbox in
> der software oder per dso variable auslesen) macht.

Peter,

also den status vom FPGA (125MHz oder 100MHz clocked) kann man auslesen,
benutze dafür die die "range" abfrage da die abfrage von einzelnen 
register irgendiwe nicht das liefert was ich will (deckt sich nicht mit 
range ausgabe, warum auch immer):

43 05 00 00 01 01 01 4B

die antwort für 125MHz:
43 06 00 80 01 00 00 00 CA

die antwort für 100MHz:
43 06 00 80 00 00 00 00 C9


Was wir noch wissen ist die feste anzahl der ADCs, beim zwei kanälen 
immer je 4ADCs, bei einem kanal immer 8 ADCs von 2ns/div bis 800ns/div 
und 4ADCs ab 2us/DIV bis 40s/div.

Das hilft für die samplerate berechnung auch etwas.

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

Thomas R. schrieb:
> Thomas R. schrieb:
>>
>> FPGA clock (eigentlich nur die information ob mit 125MHz oder 100MHz
>> sampled wird) braucht man evt. auch (per FPGA register lesen
>> möglicherweise sichtbar), man kann aber auch hardcoden anhand was die
>> aktuelle firmware (auf dem jeweiligen hw model .. evt. als checkbox in
>> der software oder per dso variable auslesen) macht.
>
> Peter,
>
> also den status vom FPGA (125MHz oder 100MHz clocked) kann man auslesen,
> benutze dafür die die "range" abfrage da die abfrage von einzelnen
> register irgendiwe nicht das liefert was ich will (deckt sich nicht mit
> range ausgabe, warum auch immer):
>
> 43 05 00 00 01 01 01 4B
>
> die antwort für 125MHz:
> 43 06 00 80 01 00 00 00 CA
>
> die antwort für 100MHz:
> 43 06 00 80 00 00 00 00 C9
>
>
> Was wir noch wissen ist die feste anzahl der ADCs, beim zwei kanälen
> immer je 4ADCs, bei einem kanal immer 8 ADCs von 2ns/div bis 800ns/div
> und 4ADCs ab 2us/DIV bis 40s/div.
>
> Das hilft für die samplerate berechnung auch etwas.


damit es vollständig ist habe alle fw versionen die ich habe mal 
angetestet um zu prüfen was diese einer register zeigt und ob es richtig 
ist was er zeigt:

bench

2.03.x  - nö
2.05.x  - nö
2.06.2  - nö
2.06.3 bis 111026.1  - nö

und ab da alle geliestetet fw funktionieren

2.06.3 - 111122.0
2.06.3 - 111124.0
2.06.3 - 111202.0
2.06.3 - 111226.1_HanTekway
2.06.3 - 111226.1_Voltcraft
2.06.3 - 120112.0
2.06.3 - 120112.1
2.06.3 - 120112.1_1:2:5_timebase_ratio
2.06.3 - 120224.0

wobei ich habe nur FPGA designs hw0-83e8, hw1005-83e8, hw1007-83e8
und 83e9. Die test version vom verbesserten FPGA design geht nicht,
was allerdings zeitlich zu dem passt ab wann die angefangen haben den
register für 125/100mhz zu implementieren.


Ahja, und handheld geht natürlich keine fw version, warum soll es
einfach gehen wenn es kompliziert sein kann :)

2.01.1_(110909.0) - nö
2.01.1_(111014.0) - nö
2.01.1_(111111.1) - nö
2.01.1_(111213.0) - nö

Peter Dreisiebner schrieb:

>
> Mit dem horizontalen Trigger kann man jetzt plus/minus 2000 ns scrollen,
> also den ganzen Speicher anschauen.
>

bin noch am lesen, aber sofort eine bemerkung - beim plus/minus scrollen
immer drauf achten ob das rotes kästchen mit waveform ober in der status 
anzeige schon link oder rechts an die ende des kästchen angrenzt.
Ich kann mich erinner an ein lustiges bug, man konnte viel weiter 
scrollen als der speicher es erlaubt hat, sah sogar alles gut aus (mit 
sinus :),
die anzegige war aber natürlich nur ein spiegelbild.

ja, deine formel stimmt. Die "0x02 Sample-Daten lesen" werte sind auf
10DIV Vertikal bezogen und gehen von -127 bis +127.

Es sind auch definitiv post-processed daten. Schade zwar das man nur der
ausschnitt auslesen kann (wenn WTB kleiner als MTB), aber das ist eine 
nette ergänzung zu den normalen CSV export der raw buffer speichert.

Den raw buffer kann man eigentlich mit "0x01 FPGA FIFO Inhalt auslesen",
allerdings bekomme ich nicht mehr als 2k ausgelesen
(43 04 00 01 00 08 50) ohne einen dso.exe crash. Dazu bin bei dem
syntax nicht sicher ob der stimmt. Die daten beim raw sind natürlich
nicht mehr display bezogen.

egonotto schrieb:


> Das erste Sample und die letzten Samples sind Unsinn. Da ist also noch
> ein Fehler!

> In der csv-Datei sind 40100 Samples.


ja, daran liegts auch,  40100 beim 40000 im speicher ist
etwas übertrieben.

>
> Mir ist das DSO-3052C beim Schreiben auf USB-Stick sehr häufig
> abgestürzt. Wieder ein Fehler!
>

mir nicht, bedeutet aber nix. Je mehr ich mir die letzten beiden
firmwares angucke desto mehr bin ich mir sicher das es ein fehler
war die zu publizieren.

Warum die solche zwischendinger (zwischen 1:2:5 und 2:4:8 tb, und das 
ist eine GROSSE änderung da fast alles sich dadurch ändert) herusbringen 
verstehe ich nicht, möglicherweise weil leute wie ich jeden tag 
nachfragen ob die endlich fertig sind. Und es war schon so chön, nur 
noch sehr kleine fehlr drin gewesen, aber nein, Hantek musste wieder 
verschlimmbessern.

Thomas R. schrieb:
> Und es war schon so chön, nur
> noch sehr kleine fehlr drin gewesen, aber nein, Hantek musste wieder
> verschlimmbessern.

Welche Version empfiehlst du bzw. welche würdest du also "stable" 
betiteln?

Lukas P. schrieb:
> Welche Version empfiehlst du bzw. welche würdest du also "stable"
> betiteln?

Ich bin zwar nicht Thomas, aber ich würde mittlerweile die Firmware von 
Rigol empfehlen. Ok, du brauchst noch ein anderes Oszilloskop dazu.

<rant>
Mittlerweile habe ich von Hantek die Nase voll. Die Software ist nicht 
nur ein Haufen Scheiße, die Programmierer sind offensichtlich zu doof 
sich selbst ein Butterbrot zu schmieren und der Support ist ein Haufen 
Lügner, wenn sie denn mal antworten.

Rigol hat zwar ebenfalls keinen nennenswerten Support und der lügt auch, 
aber wenigstens funktioniert deren Firmware ansatzweise.

Ich mag nicht mehr in dieser Scheiße zu wühlen, die Hantek Software 
nennt, nur um bei anderen Herstellern selbstverständliche Funktionen 
ansatzweise und fehlerhaft zu bekommen. Es ist nicht mein Job als Kunde 
dauerhaft in der Scheiße zu wühlen und von Hantek kommt nichts anderes 
als Scheiße.

Ich habe keine Lust mehr, mühsam Informationen durch Reverse-Engineering 
zu erraten, die Hantek in ein paar Minuten bereitstellen könnte, wenn 
man dort nur die faulen, inkompetenten Ärsche hochbekommen würde.
</rant>

Hannes Jaeger schrieb:
> Ich bin zwar nicht Thomas, aber ich würde mittlerweile die Firmware von
> Rigol empfehlen. Ok, du brauchst noch ein anderes Oszilloskop dazu.
>
> <rant>
> Mittlerweile habe ich von Hantek die Nase voll. Die Software ist nicht
> nur ein Haufen Scheiße, die Programmierer.......

Das war die morgendliche Frust-Entladung....wir habens zur Kenntnis 
genommen.

Hast Du auch etwas konstruktives?

Peter Krengel schrieb:
> Hast Du auch etwas konstruktives?

Dann schau mal, wer 
http://www.mikrocontroller.net/articles/Hantek_Protokoll begonnen hat. 
Dann weißt du auch, warum ich mittlerweile finde, dass Hantek nur einen 
Haufen Scheiße liefert.

Hannes Jaeger schrieb:
> Dann schau mal, wer
> http://www.mikrocontroller.net/articles/Hantek_Protokoll begonnen hat.
> Dann weißt du auch, warum ich mittlerweile finde, dass Hantek nur einen
> Haufen Scheiße liefert.

:))))))))))))

Vielleicht schreibt ja irgendwann, mal irgendwer die ganze
Software neu.....

Gruss
Peter

Hannes Jaeger schrieb:
>
> Ich habe keine Lust mehr, mühsam Informationen durch Reverse-Engineering
> zu erraten, die Hantek in ein paar Minuten bereitstellen könnte,

es ist nicht so das nach 2 jahren, zig emails, zig mehreren anrufen
und mittlerweile sogar bestechungsversuchen die nicht beatwortet hätten 
.. doch doch, es kamm sogar etwas SDK doku rüber.
Damit ist mindestens der "normale meldungen" teil wirklich komplett,
es war auch teilweise brauchbar für reversing von debug meldungen.
Allerdings bekommen wir keine doku zur debug meldungen, weil es interne 
sachen sind. Nun, ich war aber fleißig und eigentlich brauchen wir nur 
noch kleinigkeiten

Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

> wenn
> man dort nur die faulen, inkompetenten Ärsche hochbekommen würde.
>

ach, ob diese mädels sind schon fleißig, 99,9999999998% aller
versuche die entwickler direkt zu erreichen werden abgeblockt :)

Lukas P. schrieb:
>
> Welche Version empfiehlst du bzw. welche würdest du also "stable"
> betiteln?

habe lange aiuf einem DSO die "2.06.3_110923.1" benutzt und fand
die stable, davor glaube ich 2.06.3_110531.1, ist aber schon eine
weile her. Von den ganz alten war glaube ich 2.05.0_100305.0 nicht
schlecht.

Von den letzten versionen die auch "83E9" kompatibel sind
würde spontan sagen 2.06.3_111202.0

Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

Peter Dreisiebner schrieb:
> Das DSO-USB-Tool gibts hier:
> http://www.dreisiebner.at/dso-usb-tool/

Hallo Peter,
vielen Dank für die unermüdliche Arbeit am TTScope-Nachfolger!

Gibt es auch eine Möglichkeit, mal einen Blick in den Code zu werfen, 
ohne RealStudio zu besitzen - oder würde die kleinste Ausbaustufe 
(Personal) dafür auch schon ausreichen?  Aus der Vergeleichsliste von 
RealSoftware werde ich nicht so recht schlau.
Danke! Thomas

falls jemand die "ico" dateien ins png konvertieren möchte

http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg101338/#msg101338

und natürlich zurück:

http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg101352/#msg101352

Thomas R. schrieb:
> Von den letzten versionen die auch "83E9" kompatibel sind
> würde spontan sagen 2.06.3_111202.0

Super, danke! Speziell der Hinweis auf die 83e9 war gut! Sonst hätte ich 
wahrscheinlich die alten benutzt und mich gewundert... ;-)

Peter Dreisiebner schrieb:
> ...RealStudio...

Bescheidene Frage: Ich kenne RealStudio nicht, aber wäre es damit nicht 
vielleicht möglich auch eine Mac/Linux Version der Software zu bauen? 
Das Real-Zeug kann sowas doch angeblich. Benutze seit längerem privat 
kein Windows mehr... ;-)

Edit: Erst denken, dann... Mir fällt gerade der benötigte USB-Treiber 
wieder ein. Also wohl eher nicht. Wäre ja auch zu einfach gewesen ;-D

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

Ja, tinman hat hier und im EEVblog einen Schaltplan vom gesamten DSO als 
pdf gepostet. Da ist dann auch der Schaltplan vom Netzteil dabei.
Hier der Link:
http://www.mikrocontroller.net/attachment/116588/Hantek_Tekway_DSO_v1.03.pdf

Mfg

habs ihn nun doch gefunden:
Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"
Sorry.
Der Hitzespender im Netzteil (3,3V)  ist doch der "obere" Regler (zum 
Handgriff), oder ?

Alois Neumann schrieb:
> Thomas R. schrieb:
>> Falls jemand von euch ein Altera JTAG cable hat und ein Voltcraft DSOs
>> oder Hantek/Tekway hw 1007x555583e9 (nicht 83e8!) würde ich mich
>> freuen wenn derjeniger einen dump von dem MAX II CPLD machen würde
>> (die sind nciht copy protected).
> Ich habe die H/W Version 1007x555583e9 und einen "Mini Usb Blaster
> Cable For CPLD FPGA NIOS JTAG Altera Programmer".
>
> Was brauche ich für Software und wie gehe ich vor beim Erstellen des
> Dumps?
>
> Gruss Alois ;)

Alois,

habe jetzt auch so ein Blaster gekauft und getestet - damit geht es 
auch.
Anbei die Anleitung wie.

gruss

Thomas

Hantek hat mir gesagt "1000 punkte" bei der position und "alles
position - also vertikal - sind auf die 1000 display points bezogen".
Das halte ich aber für unsinn, wird nicht die erste abweichung sein
zwischen dem was die programmiert und dokumentiert haben.

Ich habe bei den sample daten pi * daum 10DIV am max wert
gemessen/gesehen, muss zugeben das war etwas schlampig.

Liesst man die raw daten dann entspricht full scale raw daten
einer anzeige von ca. ~10,5DIV

Es wird also etwas zwischen 10,5 und 10 sein, die 10,2DIV + 2pixel
"zero" pixel (also 10,24 gesammt vertikal) klingeln allerdings logisch.
Die fehler bei der darstellung auf dem bild (noise mal unten,
mitte oder oben beim pos. verschiebung) spricht evt. für glatte 500
(also 10DIV)

Das Weglassen von Abtastdaten (ob zum Zeichnen oder aus anderen Gründen) 
ist eine wohldefinierte Technik - Downsampling 
http://de.wikipedia.org/wiki/Downsampling

Nur, wenn es um das Zeichnen von den Sampling-Daten geht, würde ich zu 
Anfang erst mal drauf verzichten. Statt dessen würde ich einfach die 
Daten so zeichnen wie sie sind. D.h. jeden Abtastwert als einen 
(X,Y)-Wert betrachten, der durch lineares Skalieren gefolgt von Runden 
zu einer Bildschirmposition (x,y) gewandelt wird. Die (x,y)-Positionen 
werden durch Linien verbunden oder als Punkte gezeichnet. Fertig. Dabei 
liegen dann Linien oder Punkte übereinander, d.h. man Zeichnet einiges 
doppelt. Gas ganze entspricht dem Finden des minimalen und maximalen 
y-Werts für eine x-Position, nur das man diese Werte nicht sucht, 
sondern alles zeichnet.

Das sieht zwar in vielen Fällen bescheiden aus, aber es verbiegt einem 
kein Downsampling-Tiefpass das Signal zu etwas, was das Oszilloskop gar 
nicht gemessen hat.

Dazu eine horizontale Zoom-Funktion. Damit sieht der User beim 
Auseinanderziehen schön, wie aus einer vertikalen Linie langsam eine 
Kurve wird. Zoomen geht auch schneller, wenn man auf das Downsampling 
verzichtet, ansonsten müsste man nämlich bei jedem Zoom neu downsamplen, 
entsprechend der für die jeweilige Stufe wegzulassenden Werte.

Es sind bildspeicher daten, immer mindestens ein punkt pro
"DSO display" pixel. Wenn also deine anzeige fest auf
640x512 / 768x512 (oder beim handheld nur 600x512) steht ist
alles gut wie es ist - einfach alles malen was gelesen war.
Dadurch hast du kein ärger bei skalieren, keine unnötige interpolation. 
Auch beim zoom wird nur das angezeigt was tatsächlich vom DSO errechnet
und angezeit war - auch wenn dann nur unter umständen 1 punkt zu
sehen wird.

Hannes Jaeger schrieb:
> Peter Dreisiebner schrieb:
>> Anbei ein Liste mit einigen Menü-IDs.
>
> Ich habe die Liste mal ins Wiki gepackt
> http://www.mikrocontroller.net/articles/Hantek_Protokoll/Men%C3%BC-IDs

Hannes,

danke für die "Eindeutschung" des Artikels.

Hannes Jaeger schrieb:
> Peter Dreisiebner schrieb:
>> Sind die IDs denn über die Firmwareversionen gleich?
>
> Keine Ahnung. Wenn ich raten müsste, dann würde ich, weil es sich um
> Hantek handelt, raten, dass sie es nicht sind.
>
>> Ich wollte die
>> Menünamen schon in das DSO-Tool aufnehmen, hatte aber die Befürchtung
>> das die IDs nicht lange gültig sind.
>
> Ich würde es machen. Lieber für ein DSO richtig, als nichts für alle.
> Sollen sich die "Kunden" doch beschweren wenn es nicht stimmt.


ich werde (heute später) ein paar fw versionen testet.
Ich glaube die alten menus ändern sich nciht, was aber immer
wieder dazu kommt sind neue menus.

was ich gemerkt habe das z.b. auf dem handheld wo ein anderer usb-char
driver läuft (genau wie bei den BM/BMV bench modelen) die übertragung
selten sauber läuft ( mit deinem tool ).

Z.b. procotol.inf lesen ist schon die datenmenge "zu lang",
oder besser gesagt dein tool merkt nicht das zwei pakete empfagen
waren - wobei die länge und checksum von beiden einzeln stimm - nur
dein tool zeigt es als "ein paket" un dann stimmt natürlich
nix mehr. Lese ich kleinere dateien (wie keyprotokol.inf) dann
gehts, sende ich kurze kommandos geht auch - nur jeweils wenn es
länger oder komplex ist kann die empfangsroutine die pakete nicht
teilen/auswerten (als ob du nicht prüfen würdest auf die zu
empfangene länge).

Hier mal eine raw übersetzung von dem was Hantek gesagt hat:

> A host computer reads the waveform data flow

> To read the with a PC the DSO waveform data, lock keypad and then
> read the memory depth, waveform storage memory to allocate a large
> enough space, then the size of the received waveform data to determine
> the size of the data to actually receive (if does not receive the data
> size, and after to determine the size of the data reception.) finished
> size of the data is received, the received waveform data, if the
> machine waveform data is not ready, the PC will receive a data command.
> Waveform display receives this command, the host computer will retain
> the last valid data received and displayed. When data reception is
> complete, the PC will receive a completed command to indicate a
> waveform receiver is complete, then the host computer to the DSO
> unlock the keypad.

D.h. die werten die den buffer auf die jeweilige paket länge
bevor das paket weiter verarbeitet wird, ich blicke nicht
durch ob du es auch so machst.

Auf Linux lese ich Antworten vom Oszilloskop wie folgt:

1. Puffer der Größe wMaxPacketSize aus dem USB-Deskriptor (bei mir 64 
Bytes) allozieren.

2. Ein Paket lesen.

3. Diverse Konsistenz-Tests (Kein Timeout? Kein Lesefehler? 0x53 
Markierung? Überhaupt genug Daten um mindestens die Längenbytes 
auszuwerten? Usw.). Wenn Fehler weiter mit Punkt 11.

4. Längenbytes auswerten.

5. Puffer entsprechend Längenbyte vergrößern oder verkleinern

6. Wenn empfangene Daten vollständig, d.h. die Antwort ist komplett im 
Puffer -> weiter mit Punkt 10.

7. Versuchen Anzahl der noch fehlenden Bytes an einem Stück zu lesen. 
Das Ergebnis kann weniger Bytes als gewünscht enthalten, wenn das 
Oszilloskop zu langsam ist.

8. Diverse Tests (Kein Timeout? Kein Lesefehler?) Wenn Fehler -> Weiter 
mit Punkt 11.

9. Weiter mit Punkt 6.

10. Prüfsumme berechnen. Wenn OK -> Fertig


11. Eventuell gelesene Daten verwerfen.

12. Eingang flushen, falls noch irgendwas vom Oszilloskop kommt

12. Fertig mit Fehlermeldung.


Die Ebene drüber sieht sich dann das Kommandobyte in der Antwort an, ob 
es zur Anfrage passt. Wenn ja, und die jeweilige Antwort hat noch ein 
Subkommando, dann wird das Subkommando ausgewertet. Z.B. um zu 
entscheiden, ob weitere Daten gelesen werden müssen. Wenn das so ist, 
dann gehen die in einen eigenen Puffer, in dem nur die Daten, nicht die 
ganzen Meldungen, zusammengesetzt werden. Bis die Antwort mit dem 
Subkommando mit der Datenprüfsumme kommt.

Peter,

anbei bilder von dem was dein tool macht und was eine
einfache write und zwei mal read verursachen.
Wie gesagt, mit deinem tool kommet ein paket der eigentlich zwei
beinhaltet, einfaches write/2xread tut es wie es sein sollte.

Wenn ich zwischen jedem write/2xread block 50ms lasse
kann ich 100mal hintereinander lesen und jedesmal sind die daten
sauber (jedes read saubere paket, checksum ok).

Anbei noch log von deinem tool (im debug mode), habe nur gestartet
und direkt versucht protocol.inf zu lesen.

hehe, wir haben gleichzeitig gepostet
gut, teste ich sofort :)

Peter Dreisiebner schrieb:
> Hallo,
>
> sorry, falls ich mit den vielen Postings lästig bin.

unsinn

> Ich habe die Exe vom letzten Link nochmals aktualisiert. Die Anzeige der
> Kurven ist jetzt gleichzeitig, das verwirrt sonst. Getestet habe ich
> auch unter Windos 7, im Moment lauft es wie es soll. Ich kann am DSO
> kurbeln wie ich will, kein Hänger.

jo, soweit alles ok auf dem bench. Für handheld leider keine
veränderungen sichtbar.

> Nur ab 4 ms/DIV wird das Triggern träge, da gibt es Aussetzer, ich lese
> die Daten bei Triggerstatus Triggered, Auto- und Scan Modus.
>

also eigentlich (siehe unten - wobei ob autostop sinn macht weiss
ich nicht) genau so wie Hantek.

Das es träge wird ist klar. Zwei kleine kosmetische fehler habe 
entdeckt:
- im roll mode wird eine linie gezeichnet zwischen alten/neue daten,
da sollte eigentlich nix sein.
-im stop mode kann man die letzte wave nicht verschieben, wobei ich
denke hier bist du noch gar nicht fertig (wegen zoom usw.)

> @Thomas: Warum steht in dem Flussdiagramm nicht bei Triggerstatus Ready
> triggern? Was bedeutet der Status genau?
>

du meinst "DSO state"? Das ist der trigger status (auf chinesich steht 
eigentlich "status vom DSO zustand ist nicht "stop, armed, ready").

laut diagram wird der nur benutzt um zu sehen ob es noch daten kommen 
([TRIG-STATE] = 2,3,4,5) oder (noch)keine mehr ([TRIG-STATE] = 0,1,6).

Warum das so ist kann ich dir nicht sagen, gehe davon aus das die
Hantek leute es wissen warum (wobei eigentlich wird es nur der
ursprungliche Tekway mensch wissen warum).

meine ergebnisse beziehen sich auf xxxx08btest, teste später die 09

wegen dem buffer problem beim handheld und BM/BMV modelen:
wenn ich die pfDirectUSB auf true setze hängt die app zwar sehr oft
dafür aber (wenn die nicht hängt) die übertragung klappt.
Einmal sogar kamm die Waveform durch bevor die app hing.

Das heisst der fehler muss irgendwo bei den buffern übertragung
zwischen main app und dem usb worker.

Am besten würde ich dir den handheld für ein paar tage zum testen geben,
will/kann ich aber nicht weil der noch verkauft werden muss. Ich habe
allerdings noch ein austausch board mit def. FPGA, sollte ich den zum
laufen bekomme könnte ich es dann zu dir schicken. Das wäre zwar ohne
display und panel, aber zum testen reicht eigentlich.

Peter Dreisiebner schrieb:
>
> ich habe gerade das Programm ebenfalls mit pfDirectUSB kompiliert, die
> Update-Rate ist doppelt so schnell und es lauft ohne Hänger, hätte ich
> jetzt nicht drauf gewettet.

am anfang war deine read routine noch etwas anders,
jetzt ist sie viel sauberer da mag auch der direkt zugriff besser gehen.
Für handheld scheint es die lösung zu sein (teilweise - da manche sachen 
noch nicht stimmen, das mag aber an den kleinen unterschieden in den 
settings usw liegen).

>
> Muss wohl etwas mit dem USB-Treiber anders sein.
>

nein, der treiber am PC ist der selber. Allerdings die andere seite 
verwendet ein anderes treiber (nicht nur wegen neueren linux kernel).

Dies spielt zwar eine rolle, aber nur mariginal da der treiber
sich genau so verhält was die befehle angeht - nur timing mag evt.
anders sein.


>
>
> edit: Ich bau das als Option beim Log-Fenster ein.

gute idee, danke.

wie gesagt, für handheld reicht wenn es ohne die usb worker geht.
Wenn es also dabei bleibt das die app entweder ohne worker oder
per option abschaltbar bleibt ist alles ok.
Klar, es gibt kleine unterschiede bei den DSO settings und dadurch
geht alles was von den settings abhängig ist nicht, aber das kriege
ich schon hin (und dann sende dir die lösung dafür).

Ich bekomme schon bald auch ein bench BMV model, dann kann ich damit
auch durchtesten.

Alois Neumann schrieb:
> Thomas R. schrieb:
>> Falls jemand von euch ein Altera JTAG cable hat und ein Voltcraft DSOs
>> oder Hantek/Tekway hw 1007x555583e9 (nicht 83e8!) würde ich mich
>> freuen wenn derjeniger einen dump von dem MAX II CPLD machen würde
>> (die sind nciht copy protected).
Hi Thomas,

schau mal in dein Postfach.

Gruss Alois ;)

Hallo Alois,

danke schön!

mal eine kurze Zwischenfrage.

Habe Probleme eine SPI Verbindung sauber auf dem Oszi darzustellen. Die 
ganze Kurve zittert bei mir. Trigger ist natürlich richtig gesetzt.

Gibt es eine Firmware die das behebt. Verwende noch Version 111124.0

Gruß Christoph

muss er speziell gesetzt werden?

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

das klingt jetzt wirklich blah ...

Bei dem DSO gibts kein SPI trigger, also triggerst du auf
irgendetwas, der fehler kann also :
- am trigger einstellung liegen
- trigger implementierung in fw
- jitterigen signal

mögliche Lösungen:
- selbstkaliebrierung durchführen
- kanal auf AC, trigger auf AC, triger level auf 0
- auto benutzen
- auf pulse länge triggern
- auf slope triggern
- zoom verkleinern (falls im dual window mode)
usw.

falls der trigger immer noch spinnt (und das signal nicht jitterig ist)
prüfen ob tdc_edge125M, tdc_overtime125M und tdc_pulse125M vorhanden
sind <- evt. ist die factory cal falsch. Einfach ls -l im
DSO-Tool ausführen und size (so um 1k sollte es sein) und
datum (sollten alle vom selben tag sein) prüfen.


Und ja, irgendwie muss man öffters autoset bei den letzte fw versionen 
benutzen, ob es am trigger fehler oder den nicht 100% durchgeführten 
änderungen in timebase routinen liegt weiss ich nciht.

wie in dem Voltcraft thread schon geschrieben gibt es neue firmware
auf Hantek website. Die passt auch für die Tekway

http://www.hantek.com/Product/DSO5000Series/DSO5000/DSO5202B_Firmware.rar

Es sind erst 5 1/2 von 22 fehler gefixt, mehr dazu hier

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

Peter Dreisiebner schrieb:
> Hallo,
>
> mit der neuen Firmware 120423 gibt es keine Ausgaben auf die Konsole im
> normalen Betrieb, die Bootmeldungen sind auch kürzer.
> Das fehlt mir jetzt schon etwas.
>
> Peter

ja, leider ist das so. Alle debug, console nachrichten sind weg.
Auch die exports sind weg:

http://www.mikrocontroller.net/attachment/142149/alt.JPG
http://www.mikrocontroller.net/attachment/142150/neu.jpg

beacte auch den watchdog
Beitrag "Re: VOLTCRAFT DSO-3062C 60 MHz = baugleich mit?"

hier ein paar eeprom hack informationen,

http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg108309/#msg108309

Zwar haben Hantek und Tekway die GPL download links schon in den 
jeweiligen user manual angepasst, allerdings auf der jeweiligen
produktseite sind die verbogen (Hantek).

Anscheinend hat der webadmin etwas falsch verstanden und nur kraut
gepostet, solange die nicht geändert sind hier die funktionierende 
links:


Für Hantek DSO5xxxB, und Voltcraft DSO3062C modele:
http://www.hantek.com/download/desktop.zip

Für Tekway DST1xxxB, DST4xxxB, DST3xxxB modele:
http://203.81.29.13:2108/

Die beiden unterscheiden sich eigentlich nicht. Es gibt aber eine
neuere version die auch root fs beinhaltet:
http://203.81.29.13:8888/desktop.zip


Für Hantek Handheld DSO1xxxB/BV modele:
http://www.hantek.com/download/handscope.zip
oder
http://203.81.29.13:8888/handscope.zip


Für Hantek DSO5xxxBM/BMV modele:
http://www.hantek.com/download/desktop_video.zip
oder
http://203.81.29.13:8888/desktop_video.zip

Für Tekway MST1xxx modele:
http://www.hantek.com/download/desktop_logic.zip
oder
http://203.81.29.13:8888/desktop_logic.zip


Alle diese dateien beinhanlten auch die root_fs passend zu
jeweiligen kernel. Es lohn alles zu downloaden, logischerweise
sind sachen vermischt ... Hantek desktop sources beinhalten
kernel 2.6.13 aber root_fs für 2.6.30.4, dafür die desktop_logic
sources andersrum :)

Es lohnt auch die ersten GPL sources zu laden:

http://ftp.gpl-devices.org/pub/vendors/Voltcraft/VOLTCRAFT_dso3000series.zip

die beinhalten ein paar tools die wieder entfernt worden sind
bei den neueren versionen.

Auch die sources von handheld/mixed/video modelen sind interessant,
alleine schon wegen kernel/root_fs und drivers - so kann man schon
das "B" model auf BM/BMV updaten.

ahja, und hier gibts auch noch kopie von qq2440 dvd

http://203.81.29.13:7635/

und nocheinmal nur 2.6.13 root_fs.

wie finde ich das denn?
7,5kbit download bei fast allen Links und dann bricht's auch noch ab, 
weil Zeitlimit überschritten und das mit einer 16000er Leitung. :-(((
Gibt's noch andere Download-Quellen, die mehr hergeben?

Gruß Michael

Ein klassischer Fall für einen Torrent! Hat jemand schon alle files und 
kann diese als Torrent zur Verfügung stellen? Da das alles GPL ist 
sollte doch nichts dagegen sprechen.

ach was, seit einer stunde 70k durchgehend.

Nimm http://www.freedownloadmanager.org/ und gut ist, brauchst kein
krampf mit torrents uplink speed (wobei das kann es auch)

Lukas P. schrieb:
> Ein klassischer Fall für einen Torrent! Hat jemand schon alle files und
> kann diese als Torrent zur Verfügung stellen? Da das alles GPL ist
> sollte doch nichts dagegen sprechen.

Wie wärs mit http://sourceforge.net/ ? Da gibtz auch gleich ein SVN mit 
dabei.

Hallo

Da ich mir auch ein Oszi kaufen will lese hier schon lange mit und es 
ist erstaunlich was man hier so leistet.
 Mich würde das Hantek DSO5062B interesieren. Meine frage währe wo kann 
ich solches in Österreich oder in Deutschland kaufen.

Mfg. team151

Fritz Sch. schrieb:
> Meine frage währe wo kann
> ich solches in Österreich oder in Deutschland kaufen.

Hallo Fritz,

am besten mal nach googlen...
Beim grossen C sind sie wohl wieder in der 60MHz Version
und damit nach 200MHz umbaubar erhältlich, ansonsten wenns ein
Original sein soll, gibts auch chinesische Versender in der Bucht.

Die sind wohl am günstigsten, obwohl das bezüglich
Rechnung, so man denn eine braucht, so seine Tücken hat ;)
Auf der anderen Seite: Wegen Garantie muss man sich bei
den Chinesen keine Sorgen machen. Ausgetauscht wird problemlos.

Gruss
Peter

yatko schrieb:
> Hi Thomas R.
>
> (Ich hoffe, es ist erwünscht)
>
> kannst du bitte mal nen neuen Thread aufmachen ? Nach > 730 Beiträgen
> (Glückwunsch :) benötigen einige Browser schon viel Zeit um diesen
> interessanten Thread anzuzeigen.
>

unsinn, geht super schnell, benutze einfach

"Seitenaufteilung einschalten"

funktion. Das geht sogar auf meinem Nokia E90 ohne schmerzen.

> unsinn, geht super schnell, benutze einfach
> "Seitenaufteilung abschalten"

der Thomas... :-) nein: Mußt natürlich die "Seitenaufteilung 
einschalten", erst dann gibt's die Häppchen-Seiten.
Ich glaube, diese Opztion geht nur, wenn man hier einen Accound hat und 
angemeldet ist.

Gruß Michael

Hallo,

mein Tekway DST1062B (1005er Hardware) spinnt auf einmal rum obwohl ich 
nix verändert hab, Firmware ist 2.06.3 (12011.2.1) und der 2. Kanal geht 
mal und mal nicht. Geht er nicht, dann muss ich eine Kalibrierung 
durchführen, ohne die geht der Kanal selbst nach einem Reset nicht.

Wenn ich die Position bei dem 2. Kanal wenn er nicht geht (zeigt kein 
Eingangssignal an, einfach nur ne Spannung) veränder, dann verschiebt 
sich diese Spannung und wird größer oder kleiner.

Nach einer Kalibrierung geht wieder alles einwandfrei.

Ist das ein Bug in der Firmware oder ist die Batterie leer? Oder ist das 
Gerät kaputt und ich muss es einschicken?

MFG Johannes

Hi,

Johannes R. schrieb:
> mein Tekway DST1062B (1005er Hardware) spinnt auf einmal rum obwohl ich
> nix verändert hab, Firmware ist 2.06.3 (12011.2.1) und der 2. Kanal geht
> mal und mal nicht. Geht er nicht, dann muss ich eine Kalibrierung
> durchführen, ohne die geht der Kanal selbst nach einem

Sofern mich meine Erinnerung nicht trügt:
WENN du noch Gewährleistung hast und der VK im Europäischen Raum sitzt 
(Versandkosten) würde ich - egal ob es jetzt eine Chance gibt das selbst 
zu regeln- nicht weiter nach dem Fehler suchen sondern das Gerät 
schnellstens einsenden.

Wie gesagt -vorrausgesetzt ich erinnere mich richtig- war es doch so das 
die 1005er HW eine schlechte Zwischenversion war die einige Macken und 
Nachteile aufwies welche die Vorgänger und NAchfolger nicht haben.
Bisher wurden die nach den hier zu lesenden Ausssagen dann gegen neuere 
Boardversionen ausgetauscht.

Aber warte am besten noch mal auf Thomas Antwort, der kann sagen ob ich 
das jetzt richtig im Kopf habe...

Gruß
Carsten

Johannes R. schrieb:
> Hallo,
>
> mein Tekway DST1062B (1005er Hardware)

ich dachte Du hast den schon mal getauscht auf hw1007.
Grunsätzlich ein 1005 würde ich nicht haben wollen, die neigen
instabil zu sein, mit oder ohne grund (mit der zeit).

> spinnt auf einmal rum obwohl ich
> nix verändert hab, Firmware ist 2.06.3 (12011.2.1) und der 2. Kanal geht
> mal und mal nicht. Geht er nicht, dann muss ich eine Kalibrierung
> durchführen, ohne die geht der Kanal selbst nach einem Reset nicht.
>
> Wenn ich die Position bei dem 2. Kanal wenn er nicht geht (zeigt kein
> Eingangssignal an, einfach nur ne Spannung) veränder, dann verschiebt
> sich diese Spannung und wird größer oder kleiner.
>
> Nach einer Kalibrierung geht wieder alles einwandfrei.

ja man kann in gewissen grenzen die hardware fehler "wegkalibrieren",
dadurch wird aber nix repariert. Ändert sich mal die temperatur
verabschiden sich die hw1005 gleich wieder weg.

>
> Ist das ein Bug in der Firmware oder ist die Batterie leer? Oder ist das
> Gerät kaputt und ich muss es einschicken?
>

wenn du garantie hast dann einschicken. Wenn du pech hast bekommst
du restposten-gerät hw1005 (sowas würde ich aber nicht annehmen).

Ersatz PCBs für hw1005 gibts es keine mehr, hw1007 past 1:1 rein
(für hw0 geräte "auch", allerdings muss stück blech abgesägt werden).

Hallo,

das wurde mit der Begründung dass das nur in einem Fall getauscht wird 
abgelehnt.

Werde dann mal morgen telefonieren. Hab keinen Bock das Teil täglich für 
ne Zweikanalmessung zu kalibrieren.


MFG Johannes

ja gut, der händler hat natürlich auch kein leichtes leben,
der kann nix für das Hantek/Tekway 3 monate lang schrott
produziert haben. Gar nicht lustig ist die tatsache das die
hw1005-austauschkosten der händler selber tragen muss
(oder den kunden in rechnung stellen, egal wie man dreht ist
es viel zu viel geld um es zu akzeptieren).

Man bekommt auch keine hw1007 boards auf vorrat - es muss das
h1005 eingeschickt werden (66EUR) und hw1007 zurück (66EUR).
Es muss auch jemand einbauen und testen (und wehe wenn ersatz
PCB DOA war ...), das kostet auch zeit/geld.

Die hersteller möchten diese kosten nicht tragen da die PCBs
"funktionieren" - zwar muss man bei jedem fw update zittern
das die aufhören, aber so ist das schon leben. Es ist zwar
bedauerlich das die hw1005 so zickig sind, rein theoretisch
sind die aber "voll funktionstüchtig" (mindestens aufgewählte
modele beim 22,3° umgebungstemperatur ...)

Glaub mir, ob händler oder hersteller - der tag an dem die
hw1005 aus der garantie raus sind wird ein guter tag sein.

Da ist noch etwas was Hantek/Tekway evt. nicht gemerkt haben,
soweit ich es sehen kann die hw1005 melden sich als 83E9 FPGA
design (soweit richtig, es war neue version). Dummerweise denkt
die firmware das dies hw1007/83E9 sind und schaltet sampling
höher (schreibe gleich mehr dazu). So ist jedes hw1005 eine
zeitbombe - das hw1005/83e9 design kann nicht schneller getaktet
werden und schon gibts noch mehr ärger. Ich würde bei hw1005 keine
neure firmwares installieren, 110923.1 dürfte die beste version für
die hw1005 sein.

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

In deinem fall ist es allerdings einfach, es ist kaputt,
da braucht man nicht zu "zaubern". Ein gerät der jede 2 tage
ein kanal verliert hat eine macke, man kann es nicht schön
reden oder auf hw1005 termische probleme schieben.

Übrigens, falls jemand es noch nicht weisst - sobald die neuesten
firmwares ein FPGA design version 83E9 sieht ändern sich die 
möglichen/maximalen sample rates.

Bei 2 kanal betrieb sind es jetzt im long mem mode maximal
500MS/s pro kanal statt 200MS/s wie beim 83E8 design.

Bei 1 kanal betrieb sind es jetzt im long mem mode maximal
500MS/s statt 400MS/s.

Beim short mem mode unverändert maximal 1GSs bei 1 kanal
und 500MS/s bei 2 kanälen.

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

Was sind die 83E8, 83E9 ?

Im prinzip sind es ausbaustuffen, es gibts z.b. für die
langsammen modele (Tekway DST4000, DST3000) FPGA designs
markiert als 83ED, 83EE, 83EF, 83F4 und 83F5. Die unterschiede
liegen in den maximalen sample rate/speicher verwaltung.

So sind auch die Tekway DST1000 als 83E8 und 83E9 verfügbar,
und das zwar von anfang an. Leider gabs trigger (oder war das timing?)
probleme bei dem allerersten 83E9 design (vom Dez. 2009) so sind
alle geräte damals (Feb 2010) zwangupgedated auf die langsamere
design vrsion 83E8.

Hantek hat dann mit hw1005 mal wieder versucht etwas zu verbessern,
allerdings kamm nix gutes daraus.

Beim hw1007 ist Hantek/Tekway auf nummer sicher gegangen und direkt
mit 83E8 geliefert (auch beim handhelds drauf). Im Nov 2011 haben die
endlich geschaft die 83E9 stabiler zu designen. Die ist zwar sehr
hart an der grenze (mit 105MHz clock kommt die nicht mehr klar,
die 83E8 schaft auch 125MHz - also 1.25GS/s), funktioniert aber
auch bei FPGA temperatur änderungen (nicht wie bei hw1005 ...).
Auch die firmware sind glaube ich seit Nov/Dez 2011 schneller zu
samplen sobald FPGA als 83E9 sich meldet.

Und genau hier gibts probleme mit hw1005 (auch hw0 83E9 vom Dez 2009
wird probleme haben, ausser mir hat glaube ich niemand so ein gerät
in EU gesehen), die firmware denkt "es ist hw1007/83E9" und schon
spinnt ein hw1005 model. Man sieht dann ohne ein signal angelegt
zu haben wunderschöne 125MHz sinus auf beiden kanälen.
Übrigens, es mag passieren das ein hw1005 trozde sauber läuft,
es ist reine glückssache.

Übrigens, alle Voltcraft haben die gute 83E9 version drauf.
Auch die BM/BMV modele habe es.

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

Falls jemand es testen möchte, oder was auch immer
(z.b. ein hw0/83E8 oder hw1007/83E8 schneller machen)
anbei alle FPGA designs die ich raugeben darf:

dn_hw0_83E9_date_091201.rbf (erste design version für DST1000B)
dn_hw0_83E8_date_100224.rbf (stabile aber langsammere version)
dn_hw1005_83E8_date110225.rbf (kompletter Reinfall)
dn_hw1005_83E9_date110423.rbf (etwas besser)
dn_hw1005_83E9_date110427.rbf (die einzige quasi stabile design
                               für hw1005)
dn_hw1007_83E8_date110522.rbf (back to the root)
dn_hw1007_83E9_date111122.rbf (das ist die gute 83E9 version)

Einfach jeweilge datei rüber auf das DSO kopieren (als /dn.rbf),
die /param/sav/run* löschen (oder default setup drucken).
Nach dem reboot läuft dann das neue design.

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

Ich habe auch ein paar neuigkeiten zum thema firmware bugs,
werde bei gelegenheit es mehr dazu sagen.

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

Hantek hat ein paar Programmierer gefunden? :-)

Johannes R. schrieb:
> das wurde mit der Begründung dass das nur in einem Fall getauscht wird
> abgelehnt.

@Johannes:

Hast Du ein Hochspannungsnetzteil oder irgendwas, das ein paar
"KV-chen" mit ein paar µA aber bitte nur in dieser Richtung erzeugen 
kann?

Dann komme mal zufällig damit in die Nähe eines der großen Chips....
Was Du danach machen musst, kannst Du Dir denken :))))))

Nein, die Welt ist nicht schlecht, man muss nur das Beste daraus machen.

Gruss
Peter

Sonst geht es dir eigentlich noch gut? Wieso sollte ich ein damals 
funktionstüchtiges Gerät zerstören?

Sowas wie ein Sachverständiger kann das feststellen und dann folgt 
Justizia.

Halte dich also in Zukunft mit solchen Ratschlägen zurück.

MFG Johannes

Johannes R. schrieb:
> Sonst geht es dir eigentlich noch gut? Wieso sollte ich ein damals
> funktionstüchtiges Gerät zerstören?
>
> Sowas wie ein Sachverständiger kann das feststellen und dann folgt
> Justizia.
>
> Halte dich also in Zukunft mit solchen Ratschlägen zurück.

Es gibt Leute mein lieber Johannes, mit denen hat man keinen Spass.
Die können eine Satire auch nicht von Realität unterscheiden!

Und im übrigen, welchen Senf ich wozu gebe, überlasst Du mal schön mir, 
kapiert?

Üben, üben Johannes. Nach einigen Tagen gelingen Dir bestimmt schon die
ersten Lächelversuche :))

Hannes Jaeger schrieb:
> Thomas R. schrieb:
>> Ich habe auch ein paar neuigkeiten zum thema firmware bugs,
>
> Hantek hat ein paar Programmierer gefunden? :-)

fast ... eigentlich war ich mit Hantek am verhandeln, es ging um 
zusammenarbeit (unter NDA). Das hätte für die zwei vorteile bedeutet - 
keine hacks mehr von meiner seite (und dummerweise für die habe ich noch 
einige im petto) und günstige hilfe um die jämmerliche bugs zu 
beseitigen.
Allerdings nach dem Hantek versucht hat mich zu belügen, vorauf ich
ein paar "netter wörter" gesagt, herrscht funkstille. Ich bin auch nicht 
mehr bereit für Hantek die zeit zu invesiteren.

Der letzte status war das deren entwickler gestoppt hat die bugs in der 
aktuellen firmware zu beseitgen und angefangen hat die software komplett 
umzuschreiben. Es geht natürlich nicht nur um die bekannten bugs aber 
auch um sachen die nur der entwickler gemerkt hat (wie z.b. keine 
möglichkeit
für 1-2-5 timebase stepping bei den aktuellen fw ohne die hälfte 
umzuschreiben). Das bedeutet die wollen in den nächsten 2 monaten keine 
weiter updates rausbringen sondern erst die firmware neu schreiben - 
ohne bugs natürlich, dann gründlich testen und erst dann 
veröffentlichen.

Ob das am ende eine gute oder schlechte entscheidung war wird sich
zeigen. Damit die bugs informationen nicht verlohren gehen habe die
die ich kenne in einer pdf gespeichert - siehe anhang.
Ich habe bei den workarounds zu den bugs farbig die antworten markiert,
das sind meine empfindungen die auch weit von dem was andere denken 
entfert sein können (für mich ist z.b. AC trigger bug eine kleinigkeit 
mit der ich locker leben kann, dafür aber der screen refresh bug ein 
grober schnitzer).

Ich werde auch die tage eine patched firmware 2.06.3_120507.x posten
wo alles was ich beseitigen konnte beseitig ist. Ich versuche noch die
letzten sachen (bugs 20, 22 und 24) zu fixen. Wer nicht warten möchte
und die originale 2.06.3_120507.0 installieren möchte kann diese version
(nur die dso.exe wird benötigt) aus dem root fs dump (yaffs_2.6.13.bin)
extrahieren:

http://203.81.29.13:7635/bootloader.zip

wie nett, kaum habe ich auf eevblog gepostet schon kamm eine neue email.
Die firmware wird nicht neu gemacht sondern überarbeitet, dabei wird
die fehler liste die ich gepostet habe auch abgearbeitet.

Nun ja, ich lasse mich überraschen. Das letzte mal wo die 1 monat lang
die fehler beseitigen wollten (und davor ein monat lang angeblich mit 
anderen sachen beschäftigt waren) kamm eine firmware wo alle debug
infos / prozeduren entfernt sind. Leider nicht etwas um die firmware
zu beschleunigen (was eine gute idee wäre ... aber bitte erst die bugs)
sondern um mögliche weitere hacks zu erschweren.

Typisch Fernost...
Ich weiß schon warum ich bei so einem Verein
seit Jahrzehnten nicht mehr arbeite ;))

Danke übrigens für den Link oben,
hat geschlagene 15 Minuten gedauert um die
8MB runterzuladen. Wahrscheinlich sitzt da mal
wieder einer auf der Leitung und kontrolliert,
zensiert wenn nötig und zählt dann zu guter
Letzt nochmal die Bits ;)))

Gruss
Peter

Mischmasch schrieb:
> Also die selben Leute, die seit Monaten nicht richtig weiter kommen,
> werden in den nächsten zwei Monaten alle Probleme lösen?

das weiss ich nicht ob es die selben leute sind. Aber auch wenn,
es muss nix bedeuten, manchmal sind andere umstände dafür verantwortlich
das man keine vernünftige arbeit abliefern kann.

Ich mache mir sowieso keine sorgen, habe hier genug ältere firmware
versionen die zwar die eine oder andere funktion noch nicht haben,
dafür aber weniger/so gut wie keine bugs.

Seit Samstag habe sogar den neuen Tekway MST:

http://www.mikrocontroller.net/attachment/135049/MST1202B.jpg
(die LA/MSO funktionen muss ich erst richtig testen bevor ich
 was dazu sage,)

Drauf ist zwar nur eine frühe beta fw (2.07.1), aber die ist jetzt
schon besser als die 2.06.3 auf den bench top modelen
(bugs 1,2,3,8,9,10,17,18,24 und 25 nciht vorhanden, bug 6 sieht
 nochmal stück besser aus, 12 habe selber entfernt).

Sollte es Hantek nciht hinkriegen mit den bugs werde ich bei mir
backup von dem Tekway MST restoren (und factory cal ausführen).

Eventuell stelle ich so ein backup (mit restore anleitung) online,
auch die älteren firmwares wollte ich verfügbar machen, es gab schon
jede menge nachfrage.

> Seit Samstag habe sogar den neuen Tekway MST:
>
> http://www.mikrocontroller.net/attachment/135049/MST1202B.jpg
> (die LA/MSO funktionen muss ich erst richtig testen bevor ich
>  was dazu sage,)

wie stehen die Chancen eines der bisherigen Geräte um den LA 
aufzurüsten? Auf den Boards sind ja schon ein paar Vorbereitungen dafür 
wenn ich das richtig in Erinnerung habe.

Gerd E. schrieb:
>> Seit Samstag habe sogar den neuen Tekway MST:
>>
>> http://www.mikrocontroller.net/attachment/135049/MST1202B.jpg
>> (die LA/MSO funktionen muss ich erst richtig testen bevor ich
>>  was dazu sage,)
>
> wie stehen die Chancen eines der bisherigen Geräte um den LA
> aufzurüsten? Auf den Boards sind ja schon ein paar Vorbereitungen dafür
> wenn ich das richtig in Erinnerung habe.

für die hw0 und hw1005 besitzer keine chance da entweder nicht alle
benötigte i/o herausgeführt (hw0) oder "wackelige" hardware (hw1005).

für die hw1007 braucht man nur die LA PCB (die kann auch LAN machen,
auf dem bild nicht bestückt) und die firmware natürlich. Ich könnte
den schaltplan erstellen, sind zwar afaik 8 layer aber alles was ich
brauche (JTAG port) ist herausgeführt. Es könnte aber günstiger sein so
eine PCB von Tekway zu kaufen als selber machen (es sei den man hat ein
kleines EP3C5 board/modul mit allen benötigten i/o schon da).
Der rest ist nix wildes: VREF, 12bit DAC, DC/DC converter und opamp
für offset und SRAM (IS61LPS51236A-200TQLI) für samples.

Thomas R. schrieb:
> wie nett, kaum habe ich auf eevblog gepostet schon kamm eine neue email.
> Die firmware wird nicht neu gemacht sondern überarbeitet, dabei wird
> die fehler liste die ich gepostet habe auch abgearbeitet.

Warum nur glaube ich, dass Hantek lügt, dass sich die Balken biegen?

Da sitzt doch wieder irgendwo ein Manager, der nur seinen Arsch retten 
will, und gut aussehen möchte.

> Nun ja, ich lasse mich überraschen.

Sogar wenn die jetzt einen neuen Programmierer gefunden haben, wird der 
mehr als die Zeit brauchen um sich einzuarbeiten, die vorhandene 
Software zu finden, zu verstehen, wichtige Teile neu zu schreiben, das 
Ergebnis testen zu lassen(*), usw.


(*) Testen lassen, nicht selber testen. Nur würde das bedeuten, dass 
Hantek in die Qualitätssicherung investieren müsste. Das machen die ums 
Verrecken nicht.

Thomas schrieb:
>> Es könnte aber günstiger sein so eine PCB von Tekway zu kaufen als selber 
machen
> Kann man die denn einzeln nachkaufen?

Tekway sagt "grundsätzlich ja". Deren grosstes problem dabei ist die 
tatsache das man wissen muss was man macht, spricht firmware backup und 
restore. Ich habe zwar den beschrieben dass dies kein problem sein
dürfte für die meisten benutzer (da wir sowieso schon backups/restore
machen, und auch das tool von Peter Dreisiebner haben was datei kopieren
erleichtert) allerdings möchten die erst mit eigenen ingenieuren
nächste woche sprechen zu prüfen wie so ein vorgang aussieht.

Erst dann werden die mir die preise für das LA module sagen.

Seit kurzem bin ich nun auch unglücklicher Besitzer eines Hantek 
DSO5102B. Durch die Diskussionen hier und auf eevblog war ich ja 
vorgewarnt. Aber daß die aktuelle Software so ein Schrotthaufen ist, 
hätte ich nicht gedacht. Ich habe mir einfach nicht vorstellen können, 
daß sich ein Hersteller traut, so ein Gebastel frei zu geben.
So, daß mußte raus.

Aber das Gerät habe ich ja auch wegen des "hack value"s gekauft.
Deshalb habe ich die Kernelsourcen aus allen verfügbaren Quellen 
installiert.

Ich glaube, es müßte möglich sein, über die USB-Device-Schnittselle eine 
Netzwerk-Verbindung herzustellen. Herausgekommen ist statt dessen erst 
mal eine serielle Terminalschnittstelle über die USB-Host-Buchse (s. 
Anhang). Wenn man ein passendes Script über den Update-Mechanismus 
einspielt, könnte man darüber einen Shell-Zugang bekommen, ohne daß man 
die UART-Schnittstelle zugänglich machen muß. Also ohne 
garantiebeendenden Hardware-Eingriff (für mich zu spät :).

Die USB-Terminal-Schnittstelle kann aber auch zusätzlich zur UART-S ganz 
nützlich sein, da letztere durch /dev/console belegt ist, und die 
shell-job-control dort nicht ohne Verrenkungen funktioniert 
(http://www.busybox.net/FAQ.html#job_control).

Bei Interesse stelle ich das PL2303-Modul für den 2.6.13 Kernel gerne 
zur Verfügung. Ich kann auch Module für andere Adapter (z.B. ftdi) 
compilieren, aber leider nicht testen.

Leider habe ich mit der Kernelsource auch noch (mindestens) ein Problem:
"make menuconfig" hängt sich im Menü 'Device Drivers/USB support' auf. 
Wahrscheinlich weil Tekway/Hantek dort ihre eigenen Treiber reingemurkst 
haben.

Oder gibt es jemanden, der den Fehler nicht hat, bzw. behoben hat?

Die Konfiguration mit "make config" funktioniert, ist natürlich aber 
sehr mühsam.


Und dann noch vielen Dank an Peter Dreisiebner für das dso-usb-tool. Und 
zwar für die Linux-Version. Hier ist meine dazu passende udev-Regel

1

SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="049f", ATTRS{idProduct}=="505a", MODE="660", GROUP="dialout"

Wer's gebrauchen kann, kopiert diese Zeile in eine passende bestehende 
oder neue Datei in '/etc/udev/rules.d'. Statt 'dialout' kann man 
natürlich eine andere Gruppe nehmen (z.B. 'users').

Da das andere Posting schon lang genug war jetzt extra:

Großes Danke an Thomas R.
Danke aber auch an die vielen anderen, die hier und anderswo zum 
Mehrwert der Geräte bei(ge)tragen (haben).

Besonderer Dank, Thomas, daß Du Dich um die Fehler in der aktuellen 
Software kümmerst (Liste). 2 Fehler habe ich auf der Liste aber noch 
nicht gefunden:

Alternate Trigger.
Hier scheint überhaupt nichts richtig zu funktionieren. Insbesondere 
kann man den Level von Ch 2 nicht einstellen. Da 'Alternate Trigger' 
aber weder im Handbuch noch im Hilfesystem vorkommt, könnte man 
natürlich sagen, das daß ja garnicht zum Funktionieren gedacht ist. 
Vielleicht gehts mit der bestehenden Hardware ja auch gar nicht. Aber 
dann sollte Hantek die Funktion doch einfach wieder raus nehmen. Oder 
braucht jemand (bei einem DSO) alternate Trigger?

Zeitversatz der Kanäle.
Wenn man auf beide Kanäle das gleiche Signal gibt, werden die Kurven auf 
dem Bildschirm um ca. 1ns versetzt angezeigt (Ch2 nach Ch1). Bei 4 
ns/div (max. beim ungehackten 5102B) deutlich zu sehen. Der Fehler wurde 
auch auf eevblog diskutiert.

Peter Dreisiebner schrieb:
> so blind war ich auch schon einmal :-)
> Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

Oh je, was ich da alles ausprobiert habe...

Aber in dem Modus sind noch mehr Fehler drin. Mit der vorinstallierten 
Software (120224.0) ist die Kiste öfters abgestürtzt, wenn ich am 
Trigger-Level gedreht habe. Zur Zt. habe ich eine ältere Version 
installiert.

Mischmasch schrieb:
>> über die USB-Device-Schnittselle eine Netzwerk-Verbindung herzustellen.
>
> Das hat schon mal jemand gemacht:
>
> 
http://www.eevblog.com/forum/general-chat/hantek-tekway-dso-hack-get-200mhz-bw-for-free/msg83370/?topicseen#msg83370

Der macht das über die Host-Schnittstelle mit einem Adapter. Was ich 
meine, ist aber ein Posting weiter unten beschrieben.


Zur Zeit versuche ich den Kernel zu finden, den Tekway als Basis 
genommen hat. 2.6.13 ist es nicht. Der heißt auch "Woozy Numbat". Im 
Makefile steht aber "Affluent Albatross", und das wäre 2.6.14. Der ist's 
aber auch nicht, sondern irgendwas dazwischen. Die QQ2440-DVD tröpfelt 
gerade herein. Nur noch knapp 11 Stunden...

bong schrieb:
> natürlich ist es 2.6.13

Eben nicht. Jedenfalls nicht der "offizielle" 2.6.13, der am 29.8.2005 
released wurde[1].

Die DSO- bzw. QQ2440-Entwickler haben irgend einen Stand zwischen dem 
29.8. [2] und dem 13.9.2005 [3] gesaugt.

> Download links siehe (die Fußnoten)
> http://www.mikrocontroller.net/articles/Hantek_Protokoll

Danke, aber davon rede ich ja.


[1]http://www.kernel.org/pub/linux/kernel/v2.6/
[2]http://www.mail-archive.com/git-commits-head@vger.kernel.org/msg00684.html
[3]http://err.no/cgi-bin/gitweb.cgi?p=linux-2.6;a=commitdiff;h=refs/tags/v2.6.14-rc1

Leo C. schrieb:
> bong schrieb:
>> natürlich ist es 2.6.13
>
> Eben nicht. Jedenfalls nicht der "offizielle" 2.6.13, der am 29.8.2005
> released wurde[1].
>
> Die DSO- bzw. QQ2440-Entwickler haben irgend einen Stand zwischen dem
> 29.8. [2] und dem 13.9.2005 [3] gesaugt.
>


dürfte denoch halb so schlim sein.

Übrigens, hier findest Du ein paar interessante downloads:

http://203.81.29.13:7635/


z.b.
http://203.81.29.13:7635/dso_bench_120620.zip

Leo C. schrieb:

> Besonderer Dank, Thomas, daß Du Dich um die Fehler in der aktuellen
> Software kümmerst (Liste).
>
> Zeitversatz der Kanäle.
> Wenn man auf beide Kanäle das gleiche Signal gibt, werden die Kurven auf
> dem Bildschirm um ca. 1ns versetzt angezeigt (Ch2 nach Ch1). Bei 4
> ns/div (max. beim ungehackten 5102B) deutlich zu sehen. Der Fehler wurde
> auch auf eevblog diskutiert.

dieser fehler ist eigentlich auch (fast) keiner, die 500ps sind auch
als "trigger abweichung" in dem datenblatt angegeben. Ist natürlich
unschön dass statt den 500ps je nach model etwas mehr sind.

Ich habe hier gerade den Tekway MST, da sind es 800ps (nicht wundern
über die 500ps/DIV timebase, ich patche die firmware je nach bedürfnis).
Man sieht auf dem bild noch etwas, der trigger ist verschoben um 1250ps,
das ist auch model/factory cal und frequenz abhängig. Bei dem MST
passt es zimlich genau beim 50Mhz zu messenden signal (was auch sinn
macht für ein 100MHz gerät).

Nochmal zu den zeitversatz zwischen den kanälen, ich habe testweise eine 
delay line von Murata (LDH65500PAAA-400) am CH1 eingang eingebaut.
http://www.digchip.com/datasheets/parts/datasheet/314/LDH65500PAAA-400.php

Leider habe keine 800ps hier (nur 500 und 1000ps), damit komme ich auf
300ps zeitversatz. Das ist natürlich keine dauerlösung da die delay
lines nur 100mA vertragen. Zwischen dem R01_30 und dem AD8370 ist
eventuell auch keine gute idee wegen den self-cal, habe aber nicht
getestet. Ich habe auch am trigger mux getestet, das ist dem DSO völlig
egal, es ist also kein trigger zeitversatz sondern FPGA design bedingt.
Damit muss also die delay line irgendwo zwischen eingang und dem LMH6552 
ausgang (spätestens, damit der trigger nocht verschoben ist zum signal).

Eigentlich wäre besser wenn das FPGA design so angepasst wäre das der
zeitversatz zwischen den kanälen ohne delay lines auch passt.

EDIT: nur jetzt blos keine sammelbestellung für delay lines, diese
methode ist eigentlich nicht die beste und ungetestet.

Jdelphi schrieb:
> Ich selbst habe von Hantek einen LA5034 34 Kanal Logicana mit 500MSa/s
> (Dieser kann leider nur schöne Linien und Zeitdiagramme zeichnen, die
> dekodierung von I2c SPI oder ähnlich geht mal garnicht, also nutzlos).

Ebenfalls Hmpf (was immer das heißen mag ;)),

das Teil ist auch kein Messgerät sondern ein Spielzeug.

Wenn Du was Gescheites willst, musst Du zumindest eines von denen hier 
kaufen:

http://www.tech-tools.com/dv_main.htm

Damit arbeite ich seit einiger Zeit professionell...

Wenn Du nichts mit Highspeed Applicationen zu tun hast
(was in der Regel nicht der Fall sein wird..)
reicht die 100MHz Ausführung.

Ohne hier die Werbetrommel zu rühren (davon habe ich nichts):
Die Software ist erste Sahne und die Hardware sowieso.

Die Software gibt oben zum Ausprobieren und anschauen
nebst ausführlicher Beschreibung kostenlos zum Download ;)

Gruss
Peter

Jdelphi schrieb:
> Hmpf
> ...
> Probleme mit den anderen Hantek Produckte währen.
>

Hantek ist auch eine seltsame firma. Die meisten sachen die die
verkaufen sind irgendwie dazu gekauft (abgesehen von den ersten USB
DSOs und ich glaube sogar einem LA model).

Das mag ja auch "ok" für das management sein, bringt aber ein paar
nachteile mit sich da:
- irgendwann wird ein mitarbeiter der sich mal so ein dazu gekauftes
  ding angeguckt hat auch ein fahrad kaufen wollen (und job wechseln)
- support erschwert durch zu viele platformen
- bug fixes verlangsammt durch zu viele platformen (jedesmal undenken)
- bei fremdgeräten ist oft weiterentwicklung = neu entwicklung


> Ich selbst habe von Hantek einen LA5034 34 Kanal Logicana mit 500MSa/s
> (Dieser kann leider nur schöne Linien und Zeitdiagramme zeichnen, die
> dekodierung von I2c SPI oder ähnlich geht mal garnicht, also nutzlos).

ja, der war gar nicht soo schlecht (eigentlich direktes konkurent seit
5 jahren für LogicPort) - bis auf die software. Leider ist auch gute
hardware nix wert wenn die software nix taugt.

Ich sag "war" weil diese platform (wie auch LogicPort) mittlerweile
veraltet sind. Mittlerweile bekommt man auch LAs die schnell samplen
UND auch etwas/deutlich mehr speicher haben.

Wegen der protokol dekodierung, sicher das es kein benutzer fehler ist?
Mir hat mal jemand gesagt das die etwas "scheisse implementiert aber
funktionsfähig ist"


>
> Ein tolles DDS-3005
>
> Ein tot schickes DSO-5200A
>
> ein DSO 1060 Handhald Scope

ja genau .. eigentlich (rein hardwareseitig) sind diese geräte ok,
die probleme sind zur 99% bei der firmware/software und zur 99,5%
bei dem support.

Das war einer der grunde warum direkt nach dem rauskamm das Hantek
die Tekway DSOs produzieren/verkaufen wird ich sofort Tekway versucht
habe zu warnen. Leider hatte ich keine alternative: Tekway wollte
expandieren und Hantek hat nach einem Benchtop DSO gesucht.


> ein DSO 1060 Handhald Scope

noch vor einem jahr hat Hantek für diese (und 1200/8060) geworben,
mittlerweile verkaufen die nur noch lagerreste. Die nachfolger modele
sind alle auf den Benchtop DSO basierend (DSO1xxxB)


> Ein tot schickes DSO-5200A

auch bei den USB DSOs könnte Hantek glänzen (ein DSO3704A mit 700MHz bw
5GS/s und 4ch ist schon ein gutes stück hardware für ein USB scope)
leider wieder ist die software nicht gut genug (bis jetzt).


Allgemein gesagt baut Hantek keine schnlecht dinger (wobei manchmal
hauen die mich um, beispiel 20 cent netzteil beim DSO1060/8060/1200 UND 
DSO1062B/1102B/1202B : geeignet zum laden aber eine 20% fehlerquelle
für DMM - gut, man muss nicht laden und messen, schön ist es aber 
nicht).

Tekway DSOs waren viel besser, jetzt passen die "perfekt" zum Hantek,
leider im negativen sinne. Ich denke die meisten benutzer würde auf Bode
funktion und (nicht dokumentierte) Hantek eigenes .hws format mit
export/import für waveforms verzichten aber dafür ein/zwei weniger
dumme bugs haben (wie z.b. artefakte beim long mem, <400ns/DIV und
dual window).

Peter schrieb:
> Was für technische Gründe hast du für diese Behauptung? Das ist keine
> rhetorische Frage oder so, ich bin wirklich an den Kritikpunkten
> interessiert.

Die Frage beantwortet sich von allein, wenn
Du mit beiden Geräten arbeitest.

Während Du mit dem Scope wie Du selbst sagst,
nicht einmal simple Protokolle decodieren kannst,
geschweige denn exakte Timing Analysen durchzuführen,
ist dies mit dem DigiView problemlos und äußerst
exakt möglich. Zudem kannst Du mit dem Digiview eigene
Analysetools in die Software einbinden, sprich
eigene Protokolle und/oder, es gibt da eine
Art Library, die anderer mit einbinden. Dafür
gibt es ein extra Tool, das man auch kostenlos
runterladen kann.

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

Mit dem Scope schaust Du nette Rechtecke an,
während Du mit dem Analysetool dann das machst, wofür
es entwickelt wurde: Ernsthafte Analyse von
Codes/Protokollen und Timings.

Was ich meine, siehst Du z.B. u.a. am Triggerversatz,
wenn Du mehrere Kanäle darstellen musst (und das geht mit
DigiView....nein ich bekomme keine Verkaufsprovision!!...
auf 16 Kanälen gleichzeitig und mit voller Speed.)
der mit dem Scope eine Analyse unmöglich macht.


Zur Software:

Ich glaube kaum dass Du die Funktionen der Software in
ein, zwei Stunden erfasst hast (oder ich bin der Doofe)

Allein das Handbuch durchzuarbeiten dauert Tage...

Ein Scope mit D-Funktion ist wie ein Multimeter,
man kann alles mit sehen, aber nichts genaues weiss
man nicht...

Prof. Geräte haben halt ihren Preis...

Mit einem 10,- Radio kann ich auch gucken, welche Sender da sind,
um deren Signal aber zu analysieren, brauche ich schon etwas besseres ;)

Ob man die Funktionen echter Analysetools
braucht und nutzt, muss jeder für sich
selbst entscheiden.


Gruss
Peter

Hi,

Peter schrieb:
> Die Software sieht ja nett aus und so, aber ich persönlich finde z.B.
> die USBee Suite vom User Interface her intuitiver und netter.

Wobei die USB Suite halt auch einfach fast keine Funktionen bietet. Das 
alleine macht es es natürlich schon deutlich einfacher.
Davoin abgesehen ist der USBee einfach nur ein kleines Spielzeug das man 
gut nehmen kann wenn man einfache RS232/SPI/ oder I2C mit langsamer 
Geschwindigkeit länger mitschneiden will. Aber ansonsten...
Wenn man dann die Originalhardware betrachtet gnadenlos überteuert!
(Über den RX kann ich nichts sagen, aber fast 2000 Euro für ein 16Kanal 
Gerät...)

ICh habe mit dem Dingen experimentiert, nur Probleme gehabt. Mehr als 
16Mhz SamplingFrequenz habe ich so gut wie nie erreicht. Und überhaupt: 
mit Maximalgeschwindigkeit zuverlässig Samplen wie man es für ein 
Mitschneiden von LowSpeed USB braucht hat im gesamten Bekanntenkreis 
niemand dauerhaft hinbekommen, mal ein paar Sekunden nach X Versuchen...

Es ist für so einige Sachen ok wenn man die NAchbauhardware benutzt. 
Materialwert 5 Euro, mehr ist im Original ja auch nicht drin.!
Wobei die nutzung mit der Saleae Software da Sinnvoller ist, die lief 
damals gefühlt stabiler (Keine wie es jetzt aussieht) und das was 
angegeben war hat auch funktioniert.

Peter Krengel schrieb:
> Prof. Geräte haben halt ihren Preis...
>
> Mit einem 10,- Radio kann ich auch gucken, welche Sender da sind,
> um deren Signal aber zu analysieren, brauche ich schon etwas besseres ;)

Das stimmt definitiv, wobei das ja nicht nur Weiß und Schwarz gibt.
Um mal bei den Radiobeispielen zu bleiben:
Für viele Messungen die man machen will braucht man aber da auch nicht 
sofrt den R&S ESAI-D oder (wie er hier bei mir steht) den HP85940A-UFPR 
wie die BNATZA es mal eine ZEitlang in den Wagen hatte.

Es gab beispielsweise ja lange ZEit auch "Messempfänger" derDEUTLICH 
unter 5000DM Klasse, sowohl für Radio als auch TV, die einiges an 
Analysefunktionen boten. Gedacht waren die für R&F TEchniker die auch 
Antennenbau machten in einer Zeit als die Signale noch lange nicht so 
stark waren das ein feuchter Finger an der Antennenbuchse reichte 
sondern eine Vernüftige Ausrichtung und einpegelung der gesamten, 
teilweise aus mehreren zusammengechalteten Antennen bestehenden 
HAusanlage in vielen Regionen unerlässlich war.
(Wobei wir bezogen auf die terrestrische Versorgung in ländlichen 
Gebieten wieder in diese Zeit zurückgefallen sind. Glücklicherweise 
interessiert das dank Sat-Analge kaum noch ein Schwein. Nur wenn man mal 
den TV im Garten -z.B. weil man da mit Freunden beim Grillen und 
gemütlichen Biertrinken in großer Runde das mheutige EM Spiel sehen 
möchte, dann stört es doch. "Früher" haben wir den TV einfach 
rausgetragen, in eine schattige Ecke gestellt und mit einem Stück draht 
dann den Sender empfangen. Heute muss man erst einmal Zig meter 
Koaxkabel durchs halbe Haus ziehen...)

Worauf ich raus wollte:
Auch solche einfachen Messempfänger boten schon viele Möglichkeiten und 
man könnte einiges damit machen. Manche hatten sogar einen internen 
Panoramabildschirm! Aber halt nicht alles was dann der für den 
Laboreinsatz gedachte "echte" Messempfänger der 10 00 - 50 000 DM klasse 
konnte.

Im Bezug auf die LOGIK Analyzer würde ich als günstige aber wirklich 
brauchbare Lösung mal die ZEroplus LAP-C in den kleineren Versionen ins 
Spiel bringen...
Der Lap C 16032 als kleinstes Modell mit 16 Kanälen kostet etwa 100 Euro 
und ist durch ein einfaches Software-Update auf das Modell 16128 
erweiterbar, wo der LA dann pro Kanal 128kb Sample Speicher hat (gleich 
2MB gesamt) und bis zu 200Mhz Sampletakt.
Insgesamt bekommt man dazu fast 40 ProtokollanalyzerPlugins, von denen 
eine kleine ZAhl (glaube 7 oder 8, müsste nachsehen) grundsätzlich frei 
sind und man sich dann 30 weitere aus einem Gesamtpool von etwa 70 
möglichen zusätzlich kostenlos auswählen kann.

Die darstellung und Protokollanalyse funktioniert ganz passabel, die 
Software hat von der Bedienung bei den tieferen Funktionen so auch mal 
ihre Eigeneheiten, aber nicht gravierend.
Natürlich sind bei einem solchen LowCost Gerät dann bestimmte Funktionen 
nicht so Ausgeprägt wie bei den teureren, insbesondere erweiterte 
Analysefunktionen bzogen auf das Physikalische Signal, untypische oder 
USerdefinierbare Schaltschwellen oder aber auch sehr komplexe 
Triggerfunktion hat er nicht...
Aber alles was ich bisher damit machen wollte hat bisher problemlos 
geklappt. Und wenn man das dann mit dem etwas gleichteurem "kleinstem" 
USBee oder dem Saleae vergleicht sind das einfach welten!

Aber zum Thema LA gibt es genug andere Threads, Insbesondere zu den 
Zeroplus (gerade vor zwei Tagen wieder aktuelle gewesen) dem Logiport 
und den beiden Cypress 8051 basierenden SAleae sowie Usbee.

Das einzige was ich dazu abschließend noch sagen möchte ist, das ich 
zwar auch Jahrelang mit der Technik des "BitZählen" ganz gut zurecht 
gekommen bin, heute aber für mich das Fehlen ein evtl. von mir später 
häufiger benutzten Protokollanalyse-Plugins und erst recht das 
nichtfunktionieren der analyse gängiger Protokolle ein definitives KO 
Kriterium sind.

Natürlich sollte ein LA weit mehr sein als nur ein Werkzeug zum Mitlesen 
der Datenströme, aber wenn man ehrlich ist so ist das in der Heutigen 
ZEit doch wohl bei jedem der absolute Löwenanteil der Anwendung... Und 
die schönste Analyse des Signalverhaltens und die tollsten einstellbaren 
Spannungspegel usw. nützen mir nicht viel wenn ich die vielleicht einml 
alle 6 Monate brauche, ich aber mindestens jede Woche mal mitlesen Muss 
was so zwischen meinen Baugruppen hin und her läuft. Da schaut man 
einmal kurz ob es physikalisch passt, dnach interessiert nur noch der 
dekodierte Inhalt!

Gruß
Carsten

Hallo Carsten, Hallo Thomas!

Carsten Sch. schrieb:
> Der Lap C 16032 als kleinstes Modell mit 16 Kanälen kostet etwa 100 Euro
Wo find ich den um 100 EUR?

Thomas R. schrieb:
> für die hw1007 braucht man nur die LA PCB

Wie funktionirt den das? Ich habe ein Voltcraft, würde ich mir dann mit 
der LA PCB den  Lap C 16032 sparen?
Wenn ich die PCB einbaue brauch ich ja eine software.


Robert

Robert Walli schrieb:

> Thomas R. schrieb:
>> für die hw1007 braucht man nur die LA PCB
>
> Wie funktionirt den das? Ich habe ein Voltcraft, würde ich mir dann mit
> der LA PCB den  Lap C 16032 sparen?
> Wenn ich die PCB einbaue brauch ich ja eine software.
>
>

im prinzip braucht man so eine LA PCB und die software (firmware).
Eigene DSO PCB muss man dann ausbauen, eine i/o header (1.27mm pitch)
löten, die LA PCB draufstecken und dann die DSO PCB wieder einbauen.

Dann die eigene firmware über mein backup tools sichern,
falls man zeit sparren möchte (oder keine ausstattung hat) die
werks kalibrierung auf USB stick kopieren und schon kann man
anfangen mit MST firmware flashen (UART/USB oder JTAG).
Nach dem flashen DSO rebooten, USB stick wieder rein und die 
werkkalibrierung rüber kopieren (damit die MST firmware auch sauber mit
deiner DSO PCB wieder läuft).

Das wars dann schon ... fast :)

Man muss dummerweise loch in der gehäuse machen um die LA buchse
einzubauen - das ist etwas was ich versuche zu ersparren. Eventuell
könnte Tekway die ganzen front teile mitliefern (was kann so stück
plastik mit aufklebern kosten, 5EUR?).

Möglicherweise wird auch Tekway sagen "nein es muss händler xyz oder
jemand der mit uns ein entsprechendes vertrag unterschrieben hat 
einbauen
damit die garantie für DSO PCB waeiterhin besteht", wie du siehst sind
da einige themen die ich mit Tekway diskutieren muss.

Für mich persönlich wäre es egal, ich kann selber ein loch machen und
LA einbauen - ich brauche auch keine garantie für DSO. Das gilt
aber für mich, die meisten werden garantiert die beste lösung wollen:
- günstig
- mit garantie
- nix selber machen
- keine wartezeit

 :)

Thomas R. schrieb:
> anfangen mit MST firmware flashen

Verstehe, die firmware wird mit der PCB mitverkauft.
Klingt ja gut! d.h ich brauche den PC nicht mehr.

Und die MST firmware bringt ungefähr das selbe wie das "Lap C 16032"?
Mit allen gängigen Protokollen?

Weiss man ganz ungefähr in welchem Preisbereich sich das bewegen wird?

Robert

Thomas R. schrieb:

>> Jedenfalls nicht der "offizielle" 2.6.13, der am 29.8.2005
>
> dürfte denoch halb so schlim sein.

Vielleicht wäre es dann einfacher, das kaputte menuconfig zu reparieren. 
Inzwischen editiere ich .config direkt, mit anschließendem 'make 
oldconfig'.

> Übrigens, hier findest Du ein paar interessante downloads:
> z.b.
> http://203.81.29.13:7635/dso_bench_120620.zip

Danke für den Hinweis. Von diesem Server hatte ich schon einiges 
herunter geladen, aber diese Datei war ganz neu und wäre mir sicherlich 
entgangen. Es gibt bei Hantek also doch jemanden, der sich bemüht, den 
Sourcecode vollständig zusammen zu bekommen und zu veröffentlichen.

Obwohl das Interesse am Shell-Zugang über USB-Seriell-Adapter am 
Host-USB auf der Frontplatte 
(Beitrag "Re: TEKWAY DST1xx2B Oszilloskop") nicht 
gerade "überwältigend" (Euphemismus ;) war, habe ich dazu mal ein Paket 
zusammen gestellt, das per Firmware-Update installiert werden kann.

Achtung : Das ist das erste Mal, das ich ein solches Paket gebaut 
habe. Obwohl es bei mir wie gewünscht funktioniert, könnte es noch 
Fehler enthalten und im schlimmsten Fall dazu führen, daß das DSO nicht 
mehr bootet. Deshalb kann ich das Paket vorläufig nur Leuten empfehlen, 
die genau wissen was sie tun, und ggf. in der Lage sind, ihr DSO per 
Backup wiederherzustellen.

Im Paket sind nur Module für FTDI- und PL2303-Adapter. Mit anderen 
Adaptern kann es also (noch) nicht funktionieren. Außerdem habe ich nur 
mit PL2303-Adaptern getestet, weil ich keinen FTDI hier habe.

Vielleicht mag ja mal jemand drüber schauen, der sich auskennt. 
(Thomas?)
Über Kommentare würde ich mich freuen.

Hallo Leo?

Leo C. schrieb:
> Obwohl das Interesse am Shell-Zugang über USB-Seriell-Adapter am
> Host-USB auf der Frontplatte
> (Beitrag "Re: TEKWAY DST1xx2B Oszilloskop") nicht
> gerade "überwältigend" (Euphemismus ;) war, habe ich dazu mal ein Paket
> zusammen gestellt, das per Firmware-Update installiert werden kann.
>

Das Interesse ist schon da nur ich hab's nicht ganz kapiert.
Brauch ich da einen PL2303-Adapter für das Oszi und einen für den 
Computer verbunden mit einen Null-Modem-kabel?

Robert

Robert Walli schrieb:
> Brauch ich da einen PL2303-Adapter für das Oszi und einen für den
> Computer verbunden mit einen Null-Modem-kabel?

Für's Oszi einen PL2303-Adapter. FTDI geht wahrscheinlich auch, und für 
andere Adapter müßte man noch das Kernelmodul compilieren.

Für die andere Seite brauchst Du ein Terminal mit serieller 
Schnittstelle.
Wenn das ein PC sein soll und dieser keine (freie) serielle 
Schnittstelle hat, brauchst Du noch einen (beliebigen) 
USB-Seriell-Adapter und ein passendes Kreuz-/Nullmodem-Kabel bzw. 
-Adapter.

Kurze Antwort: ja.

Hallo Peter,

da ist nichts auskommentiert. Das ist ja kein GW-Basic oder so. ;-)
Die Änderung von rcS macht ein awk-Script. Das Script wird zwischen den 
beiden ' auf der Befehlszeile an awk übergeben. Es kopiert zeilenweise 
von rcS nach rcS.new. Dabei werden Zeilen, die von einer eventuellen 
früheren Installation stammen, heraus gefiltert, und an einer (imho) 
passenden Stelle einige Zeilen (neu) eingefügt. Die printline-Funktion 
brauche ich, um aufeinander folgende Leerzeilen zu filtern. Sonst würden 
bei mehrfacher Ausführung des Scripts immer mehr Leerzeilen in rcS 
kopiert.

Wenn das awk-Script erfolgreich beendet wurde, und die 
Zugriffsrechte von rcS.new geändert werden konnten, wird rcS.new nach 
rcS umbenannt, und damit das alte Script gelöscht.


Peter Dreisiebner schrieb:
...
> Der BEGIN/END-Block verwirrt mich, und die
> letzte Zeile ist auskommentiert, oder?

$man awk

Danke fürs Testen.

Peter Dreisiebner schrieb:
> danke, Sachen gibt es - kommt mir so vor wie 'warum einfach wenn es auch
> kompliziert geht' ;-)

Und ich dachte, ich hätte es einfach gemacht. Ok, statt awk hätte ich 
auch sed verwenden können, aber das liegt mir nicht. Bitte mach einen 
Vorschlag, wie es noch einfacher geht, und ich baue das 
Installationsscript gerne um.

> Vielleicht solltest du die original rcS-Datei nicht löschen, sondern nur
> umbenennen und aufheben.

Könnte man machen.
Allerdings gibts schon eine Backup-Datei (rcS~), die in der Regel mit 
aktueller rcS identisch ist, weil sie vom Hersteller-Update-Script 
gleich mit installiert wird.

> Könnte bei einem Fehler hilfreich sein zum
> wiederherstellen oder vergleichen.

Bei einem Fehler ist zum Vergleichen aber möglicherweise nichts da, weil 
das root Dateisystem nicht mehr gemountet werden kann, und man dann 
nicht mal mehr über die UART-Schnittstelle rein kommt. Gut, man könnte 
über JTAG oder VIVI vor dem Restore die kaputte root-Partition sichern 
und danach analysieren...

Micha schrieb:
> Noch eine kleine Bemerkung zum Loch in der Frontplatte fuer die
> LA-Buchse:
>
> bei meinem Voltcraft ist das schon drin, nur mit einem Aufkleber
> zugepappt, der natürlich an der Stelle auch nicht richtig hält und sich
> deswegen immer ablöst.

Bei meinem Hantek löste sich die Folie auch immer ab, weil sie etwas zu 
lang ist, und deshalb am rechten Rand der Vertiefung anstieß und etwas 
unter Spannung stand. Ich habe sie nach ein paar Tagen von der Mitte her 
so angedrückt, daß sie rechts über den Rand hinaus steht. Bisher hält 
sie so, und es fällt kaum auf. Die Alternative wäre, die Folie um 1-2 mm 
zu kürzen.

rs232 schrieb:
> kannst du bitte auch für CP210x compilieren?

cp210x gibts wohl erst bei späteren Kernels. Würde es das cp2101-Modul 
auch tun?

1

  Say Y here if you want to use a CP2101/CP2102 based USB to RS232

2

  module will be called cp2101.

Neues Paket, auf besonderen Wunsch einer einzlnen Schnittstelle. ;-)
Gegenüber der letzten Version ist nur das Modul cp2101.ko hinzu 
gekommen. Wer keinen CP2101 Adapter hat, braucht es also nicht.

Das Modul wird geladen, aber ob es funktioniert, kann ich mangels 
passender Hardware nicht testen.

Thomas R. schrieb:
> Robert Walli schrieb:
>
>> Thomas R. schrieb:
>>> für die hw1007 braucht man nur die LA PCB
>>
>> Wie funktionirt den das? Ich habe ein Voltcraft, würde ich mir dann mit
>> der LA PCB den  Lap C 16032 sparen?
>> Wenn ich die PCB einbaue brauch ich ja eine software.
>>
> im prinzip braucht man so eine LA PCB und die software (firmware).
> Eigene DSO PCB muss man dann ausbauen, eine i/o header (1.27mm pitch)
> löten, die LA PCB draufstecken und dann die DSO PCB wieder einbauen.

Hallo Thomas,

hast Du zur LA-Erweiterung schon neue Infos?

Danke, Thomas

Thomas Sch. schrieb:
>
> Hallo Thomas,
>
> hast Du zur LA-Erweiterung schon neue Infos?
>
> Danke, Thomas

ja, leider (ich schreibe morgen warum das).

anbei neueste firmware für Tekway/Hantek/Voltcraft

Beseitigt sind bugs 1,2,3,9,10,11,12,17

Man kann sehen das am bug 4 wird gearbeitet, filter geht jetzt
bis 495MHz statt 249MHz (funktion ist aber noch aus).

Bug 14 habe nicht getestet.

Nicht erschrecken, die main window scala zeigt manchmal falschen wert
beim einschalten von F7 - hat aber kein einfluss auf funtion/stabilität
- es korrigiert sich von alleine wenn man timebase oder andere controls
umschaltet.

Bug 1 habe nicht überall getestet, die hilfe datei ist aber deutlich 
grösser - kann also sein das wirklic alle topic funktionieren.

Thomas R. schrieb:
> anbei neueste firmware für Tekway/Hantek/Voltcraft

Danke.

> Bug 1 habe nicht überall getestet, die hilfe datei ist aber deutlich
> grösser - kann also sein das wirklic alle topic funktionieren.

Jetzt auch portugiesische Hilfe. Vorher gabs English und Chinesisch.

1

sqlite> select * from sqlite_master;

2

table|tb_en|tb_en|2|CREATE TABLE tb_en(id integer primary key,nindex varchar(100),alias varchar(100) null,topic varchar(100),content varchar(2500))

3