Forum: Mikrocontroller und Digitale Elektronik TEKWAY DST1xx2B Oszilloskop


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


Bewertung
0 lesenswert
nicht lesenswert
Mischmasch schrieb:
> Ansonsten Tektronix WFM, das ist binär und daher kürzer, und viele
> kommerzielle Tools können es lesen, weil es eben von Tektronix kommt.

Natürlich habe ich einen Link zu einer Spec vergessen :-( 
http://www.scopeshop.de/File_1499/001137802.pdf

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für die Antworten und das PDF.
Gibt es für CSV auch einen Standard für Messdaten oder macht jeder wie 
er will.Der Nachteil den ich sehe ist, dass wieder dokumentiert werden 
muss was welche Spalte usw. bedeutet. Der Vorteil ist natürlich das es 
von jedermann bearbeitet werden kann.

Peter

von Mischmasch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter Dreisiebner schrieb:
> Gibt es für CSV auch einen Standard für Messdaten

Nein.

> oder macht jeder wie
> er will.

Ja.

> Der Nachteil den ich sehe ist, dass wieder dokumentiert werden
> muss was welche Spalte usw. bedeutet.

Jein.

Für das Hantek würde ich das CSV-Format nachbauen, dass Hantek zum 
Speichern von CSV-Dateien auf einem USB-Stick verwendet. Typisch für 
Hantek ist allerdings, dass das ziemlich scheiße ist. Es enthält fast 
keine Meta-Informationen über die DSO-Einstellungen.

> Der Vorteil ist natürlich das es
> von jedermann bearbeitet werden kann.

Ja.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
das wars, alle remote kommandos die diese DSOs kennen sind dokumentiert:

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

Die debug meldungen :

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

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

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

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


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

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

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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Thomas R. schrieb:
> das wars, alle remote kommandos die diese DSOs kennen sind dokumentiert:

super, danke!

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

Peter

von Thomas R. (tinman) Benutzerseite


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

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

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

ich habe jetzt die DSO-Einstellungen nach deiner Excel-Liste erweitert. 
Nur ist mir jetzt aufgefallen das z. B. die Volt/Div nicht stimmen. In 
der Liste geht es bis 2 mV runter, das DSO geht nur bis 20 mV und das 
wäre der Wert 3. Dafür geht das DSO hoch bis 50 V, in der Liste hört es 
bei 5 V auf.
Da ist etwas um 3 Zeilen verschoben, der Wert 10 entspricht 50 V, und 0 
dann 20 mV.

Ich stelle die neue Version gleich auf meine Seite, vielleicht fallen 
anderen auch noch Fehler auf.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

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

Peter

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

da ich noch an den Sample-Daten herumkaue, anbei ein Abfallprodukt. Die 
Anzahl der Samples pro Kanal für 1 und 2 aktive Kanäle und alle 
Speichertiefen.
Ich habe die Samples mit meinem DSO-Tool von jeder Einstellung gelesen, 
funktioniert sehr gut. Nur bei 400 ms und 512k/1M muss schon oft 
probieren, das DSO reagiert da fast nicht.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich schon wieder, eine Frage zu den Sample-Daten und den Werten die man 
vom DSO einlesen kann.

Ausgangspunkt ist 'Autoset' und Kanal 1 hängt am 'Probe Check'.

[HORIZ-WIN-TB] = 15, Window-Timebase ist 200 us,
[CONTROL-DISP-MENU] = 1, sichtbar sind 16 DIVs bei Menü ein,
gelesen werden 3200 Samples (bei 4 k)

Berechnung:
200 us * 16 DIV = 3,2 ms
3,2 ms / 3200 Samples = 1 us
1 us = 1 MHz

Wenn das Menü ausgeblendet ist, sind 19,2 DIVs sichtbar, und es werden 
3840 Samples gelesen.

200 us * 19,2 DIV = 3,84 ms
3,84 ms / 3840 Samples = 1 us
1 us = 1 MHz

Das heißt ich komme nur über die Anzahl der DIVs zur Sample-Frequenz. 
Erst dann kann man den Zeitpunkt jedes Samples berechnen.
Oder geht das auch ohne den DIVs mit einen anderen Wert aus den 
DSO-Einstellungen?

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

man muss die Main-Timebase [HORIZ-TB] berücksichtigen denke ich, und 
nicht die Window-Timebase.
Aber warum bekommt man eine verschiedene Anzahl der Samples wenn das 
Menü ein oder aus ist. Bei gleicher Main-Timebase, dann müsste ja mit 
unterschiedlicher Frequenz gesampled werden? Ich versteh' es im Moment 
nicht.

Peter

von egonotto (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

MfG
egonotto

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo egonotto,

danke, aber die Pixel sind das nicht.

Ich denke es stimmt schon so, man kommt um die Anzahl DIVs nicht herum, 
z.B.:

kleinste Main-Timebase = 200 ns
Menü Ein = 16 DIVs
Window-Timebase 2 ns bis 40 ns
gelesen werden 640 Samples

200 ns * 16 DIV = 3,2 us
3,2 us / 640 Samples = 5 ns
5 ns = 200 MHz

Menü aus
200 ns * 19,2 DIV = 3,84 us
3,84 us / 768 Samples = 5 ns
5 ns = 200 MHz

Mit einer Window-Timebase von 2 ns bis 40 ns kann man sich in der 
Main-Timebase bewegen, sprich den horizontalen Trigger verschieben.
Den horiz. Trigger kann man beim Speichern der Samples berücksichtigen, 
alle Samples davor haben eine negative Zeit und alle danach sind 
poisitiv.

Wie immer, Kopf schief halten, dann rinnt das Hirn zusammen :-)

Peter

von Philipp (Gast)


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

von Thomas R. (tinman) Benutzerseite


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

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

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

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

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

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

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

von Thomas R. (tinman) Benutzerseite


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

benutze suchfunktion

von Philipp (Gast)


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

in dem trhead gibts nur 2 oder 3 beiträge mti dem wort audio und da 
steht nichts interesanes

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Thomas R. schrieb:
> Eigentlich sind es nur display punkte die den postprocessed
> ...

danke für die Erklärung, ich werde den Kopf jetzt in die andere Richtung 
schief halten, vielleicht hilfts.

Ich bleib dran.

Peter

von Thomas R. (tinman) Benutzerseite


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

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

von Thomas R. (tinman) Benutzerseite


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

Peter,

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

43 05 00 00 01 01 01 4B

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

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


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

Das hilft für die samplerate berechnung auch etwas.

von Thomas R. (tinman) Benutzerseite


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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Thomas R. schrieb:
> Was wir noch wissen ist die feste anzahl der ADCs, beim zwei kanälen
> immer je 4ADCs, bei einem kanal immer 8 ADCs von 2ns/div bis 800ns/div
> und 4ADCs ab 2us/DIV bis 40s/div.
>
> Das hilft für die samplerate berechnung auch etwas.

ich weiß jetzt nicht, wie das mit den Sample-Daten die ich auslesen 
kann, zusammen paßt.
Du sprichst jetzt von den 'echten' Sample-Daten von den ADCs?

Ich sende gleich noch ein Posting, wie ich das jetzt verstanden habe und 
verwenden würde.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

einmal noch. hier zwei Bespiele wie ich das jetzt vertanden habe und 
unten wie ich die Sample-Daten als CSV speichern würde.


Hardware 83e9
1 Kanal
Speicher 4 k
Timebase 8 ns/DIV
Main-Timebase 200 ns/DIV

Info im Menü 'Sys Status':
Sample Rate: 1.00 GS/s
Sample Dots: 160 (bezogen auf die internen 20 DIVs)
Display Dots: 800 (bezogen auf die internen 20 DIVs)

Berechnung:
1 GS/s = 1 ns/Sample
8 ns/DIV = 8 Samples je 1 ns
8 Samples/DIV * 20 DIVs = 160 Samples (wie in 'Sys Status')

Speicher:
Main-Timebase 200 ns/DIV * 20 DIVs = 4000 ns Sample-Zeit
bei 1 Sample/ns = 4000 Samples - der 4 k Speicher ist voll.

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

Die Sample-Daten die ich bei dieser Einstellung auslese, sind 
hochgerechnete 'Display Dots', von den 160 Samples auf die sichtbaren 
Pixel, also 640 oder 768 je nachdem ob das Menü sichtbar ist oder nicht.
An die 4 k Samples komme ich nicht.

Jetzt eine andere Einstellung:

1 Kanal
Speicher 1 M
Timebase 400 us
Main-Timebase 400 us


Info im Menü 'Sys Status':
Sample Rate: 100 MS/s
Sample Dots: 800.000 (bezogen auf die internen 20 DIVs)
Display Dots: 800.000 (bezogen auf die internen 20 DIVs)

Berechnung:
100 MS/s = 10 ns/Sample
400 us/DIV = 40.000 Samples je 10 ns
40.000 Samples/DIV * 20 DIVs = 800.000 Samples (wie in 'Sys Status')

Speicher:
Main-Timebase 400 us/DIV * 20 DIVs = 8000 us Sample-Zeit
bei 100 Sample/us = 800.000 Samples - der 1 M Speicher ist 'fast' voll.

Mit dem horizontalen Trigger kann man nicht scrollen, die Timebase sind 
ja gleich groß.

Die Sample-Daten die ich jetzt auslese sind 768.000 und nicht mehr die 
erfundenen Bildschirmpunkte, es sind ja genügend Daten vorhanden.


Das heißt, die Sample-Daten die ich auslese, beziehen sich immer auf die 
Window-Timebase und die sichtbaren DIVs, denn die Samples sind ohne 
sichtbaren Menü mehr.
Egal von welcher Hardware die Samples stammen, es gibt jetzt eine Zeit, 
eine Anzahl Samples und die DIV-Anzahl. Es sind nur nicht mehr die 
'echten' Samples von den ADCs.

Für das Speichern der Sample-Daten als CSV bedeutet das, z.B. das letzte 
Beispiel von oben:

Timebase 400 us * 19,2 DIVs = 7680 us
768.000 Samples / 7680 us = 100 Samples/us = 1 Sample alle 10 ns

Ich kann also für jedes Sample einen Zeitpunkt berechnen und auch den 
horiz. Trigger berücksichtigen, denn kann man ja auch auslesen.

Habe ich das jetzt alles richtig verstanden und würden die CSV-Daten so 
verwendbar sein?

Peter

von Thomas R. (tinman) Benutzerseite


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


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

bench

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

und ab da alle geliestetet fw funktionieren

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

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


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

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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Dreisiebner schrieb:

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

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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

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

das hatte ich wirklich probiert, man kurbelt ganz schön lange.
Aber bei der minus-Seite kann man nur bis zum Ende scrollen, bei der 
plus-Seite weiter als Daten vorhanden sind, man sieht aber keine.

Peter

von egonotto (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mal was zum csv-Export.

Einstellung:
 1 Kanal
 40 kSsample
 2  ns/Div

Signalfrequenz:   25 kHz

Man bekommt damit eine Samplerate von 500 MSamples/s (1 GSamples/s geht 
nur bei 4 k-Speicher)
In der csv-Datei sind 40100 Samples. Der Abstand von 2 Samples ist 2 ns
Daher umfasst die csv-Datei etwa 80 µs.

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

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

Die Kurvenform und die csv-Datei ist in der Anlage

MfG
egonotto

von Thomas R. (tinman) Benutzerseite


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

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

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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
egonotto schrieb:


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

> In der csv-Datei sind 40100 Samples.


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

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

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

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

von Lukas P. (parsley)


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

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

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


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

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

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

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

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

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

von P. K. (dg4ek)


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

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

Hast Du auch etwas konstruktives?

von kunze (Gast)


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

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


Bewertung
0 lesenswert
nicht lesenswert
Peter Krengel schrieb:
> Hast Du auch etwas konstruktives?

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

von P. K. (dg4ek)


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

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

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

Gruss
Peter

von Thomas R. (tinman) Benutzerseite


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

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

Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

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

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

von Thomas R. (tinman) Benutzerseite


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

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

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

Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe das Speichern der 'Window-Timebase'-Samples als CSV-Datei 
fertig. Ob die Daten richtig berechnet werden muss ich erst richtig 
testen. Anbei ein paar Screenshot, schaut vorerst nicht so verkehrt aus.
Das DSO-USB-Tool gibts hier:
http://www.dreisiebner.at/dso-usb-tool/

Peter

von Thomas S. (doschi_)


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

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

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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

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

ich habe es nicht ausprobiert, aber ich glaube du kannst den Code mit 
jeder Version öffnen, nur die Teile für die Professional/Enterprise 
Version nicht ändern. Das sind die Container-Controls und noch ein paar 
Objekte wie z.B. IPC-Controls usw. Einen genauen Überblick habe ich 
nicht, ich kann ja alles benutzen :-)

Die Trial-Versionen sind aber unbeschränkt, nur die Laufzeit der Exe ist 
dann bis 5 Minuten limitiert. Kann man aber immer wieder starten.

Peter

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert

von Lukas P. (parsley)


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

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

von Lukas P. (parsley)


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

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

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

von Lauren (Gast)


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

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

von Thomas S. (doschi_)


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

von Pascal H. (pase-h)


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

Mfg

von Thomas S. (doschi_)


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

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

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

Alois,

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

gruss

Thomas

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

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

ich habe mir die Sample-Daten nochmals angeschaut. Kann es sein das 
nicht 10 DIVs sondern 10,2 DIVs verwendet werden? Umgerechnet wären das 
510 Pixel, die kann ich nämlich auch auslesen. Wenn man z. B. auf 2 ns 
und 1 V/DIV geht und einen Kanal auf GND schaltet, dann hat man eine 
ziemliche Gerade. Jetzt kann ich bis +5,08 V und -5,08 V 255 
unterschiedliche Sample-Daten auslesen, als von +127 bis - 127 plus der 
Null.
Da ergibt dann pro Sample schöne 2 Pixel und genau 40 mV. Bei 10 DIVs 
wird es unrund mit 39,22 mV.

Peter

von Thomas R. (tinman) Benutzerseite


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

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

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

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

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe die live Anzeige der Sample-Daten soweit, dass man was sieht. 
Die Anzeige ist auch skalierbar und ziemlich vollständig konfigurierbar.

Nur fehlt es mir an Wissen, wie man die Samples richtig zur Anzeige 
zusammenfasst. Wenn also mehr Samples als Pixel vorhanden sind und 
umgekehrt. Den Mittelwert bilden ist zuwenig denke ich, da gehört ja 
sowas wie Peak-Detect dazu.
Hat jemand vielleicht passende Stichwörter oder einen 'verständlichen' 
Link?

Veröffentlicht habe ich die aktuelle Version noch nicht. Die Anzeige 
stimmt eben nicht, und ich habe auch oft 'Hänger' im Programm wenn am 
DSO fleißig gekurbelt wird, während die Daten gelesen werden.

Peter

von egonotto (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

zu
"
Nur fehlt es mir an Wissen, wie man die Samples richtig zur Anzeige
zusammenfasst. Wenn also mehr Samples als Pixel vorhanden sind und
umgekehrt. Den Mittelwert bilden ist zuwenig denke ich, da gehört ja
sowas wie Peak-Detect dazu.
"

Wenn zu wenig Daten vorhanden sind, kann man interpolieren. Die 
einfachste Art ist die lineare Interpolation (die Nachbarpunkte mit 
einer Strecke verbinden).

Wenn viel mehr Daten verhanden sind, könnte man die Daten in disjunkte 
Teile zerlegen und in jedem Teil das Minimum mit dem Maximum verbinden.
Dazu ein Beispiel:
Vorhanden sind 40000 Werte im Zeitintervall [0,1]ms 
(y[0],y[1],...,y[39999])
Man möchte 1000 Punkte auf der x-Achse haben (x[0],x[1],...,x[999]).
Nun teilt man die y-Werte:
t0 = {y[0],y[1],...y[39]}
t2 = {y[40],y[41],...y[79]}
t3 = {y[80],y[81],...y[119]}
.
.
.
t999 = {y[39960],...y[39999]}
und bildet min[0] = min(t0); max[0] = max(t0)
und malt alle Punkte (x[0],min[0]),(x[0],min[0]+1),(x[0],min[0]+2),....
...,(x[0],max[0])
.
.
.
und bildet min[999] = min(t999); max[999] = max(t999)
und malt alle Punkte 
(x[999],min[999]),(x[999],min[999]+1),(x[999],min[999]+2),.....,(x[999], 
max[999])

Noch besser könnte man die Sache vielleich machen, indem man mit 
sin(x)/x-Interpolation arbeitet. Dazu müsste man sich aber vorher noch 
Gedanken machen, z.B. über die Frequenzbandbegrenzung.

MfG
egonotto

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo egonotto,

danke, ganz habe ich es nicht kapiert.

Bei zuwenig Samples einfach eine Linie zeichnen ist klar, das werde ich 
vorerst auch so machen.

Bei zuvielen Samples die Daten aufteilen pro Pixel, dann pro Teil das 
Minimum und Maximum ermitteln. Und jetzt kapiere ich das Zeichnen nicht.
Zeichne ich dann pro Teil auf derselben x-Koordinate vom Minimum zum 
Maximum, also eine Senkrechte. Dann von diesem Maximum zur nächsten 
x-Koordinate und Minimum vom nächsten Teil. Dann wieder eine Senkrechte 
zum Maximum und weiter zum nächsten x und Minimum und so fort?

Bei einem starken Rauschen ergibt das eine dicke horizontale Linie, bei 
keinem Rauschen eine feine Pixelline, Peaks gehen so auch nicht 
verloren. Habe ich das so richtig verstanden?

Peter

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


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

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

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

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

von egonotto (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

 ich würde nur die jeweils senkrechte Linie vom Minimum zum Maximum 
zeichnen.
Die benachbarten x-Werten liegen ja so nah zusammen dass man da nichts 
malen kann. (es wird ja zwischen x und x+1 gar keine Pixel geben)

Ich probier mal das mit Buchstaben.


  xx
 xxxx
xxxxxx
xxxxxxx
xxxxxxx
xxxxxx
 xxx
  x

Das könnte ein Teil einer Amplitudenmodulation sein.

Man könnte die Sache noch verbessern, indem man auch die y-Werte zu 
einem x-Wert in Teile zerlegt und damit die Helligkeit steuert.
Dann könnte man die Menge der Werte vergrössern, indem man neue Werte 
mit der sin(x)/x - Interpolation berechnet. Dazu braucht es aber eine 
Frequenzbandbegrenzung. Und ich weis nicht, ob diese vorhanden ist.
Dazu ein Link zu einem mathematisch nicht sauberen Artikel.
"http://i.cmpnet.com/planetanalog/2009/02/Sin(x)x_Agilent.pdf";


MfG
egonotto

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo egonotto und Hannes,

danke, ich werde mal schauen wie flott das ganze funktioniert. Jetzt 
beim einfachen weglassen der Samples ist es schneller als TTscope, also 
Luft ist noch.
Die Sample-Daten sind aber die gefilterten Daten aus dem 
Bildschirmpuffer vom DSO. Ob man da überhaupt noch was herausholen kann?

Peter

von Thomas R. (tinman) Benutzerseite


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

von Thomas R. (tinman) Benutzerseite


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

Hannes,

danke für die "Eindeutschung" des Artikels.

von Thomas R. (tinman) Benutzerseite


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


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

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Thomas R. schrieb:
> Es sind bildspeicher daten, immer mindestens ein punkt pro
> "DSO display" pixel. Wenn also deine anzeige fest auf
> 640x512 / 768x512 (oder beim handheld nur 600x512) steht ist
> alles gut wie es ist - einfach alles malen was gelesen war.

die Anzeige im DSO-Tool passt sich an die Fenstergröße an und an die 
Größe vom DSO, 16 oder 19 DIV.

Und Daten werden ja meist mehr gelesen als Pixel am DSO sind, bei 80 
us/DIV sind es ja schon 3840 Samples pro Kanal.

Anbei ein Versuch so wie Egonotto es beschrieben hat, es gibt noch 
Lücken bei den Samples, aber sieht schon gut aus und ist genauso schnell 
wie vorher bei 3840 Samples.

Peter

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo egonotto,

ich habe deinen Vorschlag jetzt umgesetzt, schaut sehr gut aus.
Habe der Prozedur fürs Zeichnen deinen Namen gegeben :-)

Ein paar Rundungsfehler gibt es noch, aber es wird.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

eine neue Version vom DSO-USB-Tool steht bereit:
http://www.dreisiebner.at/dso-usb-tool/

Die Kurvendarstellung ist noch Baustelle, aber funktioniert.
Einen Fehler beim DSO gibt es der sich auswirkt. Es werden manchmal die 
Daten vom falschen Kanal gesendet ohne das die Kanalnummer in den 
Datenpaketen angepasst wird. Man kann also nicht feststellen das die 
Sample-Daten vom anderen Kanal sind. Das merkt man wenn 40 K Speicher 
oder mehr aktiviert sind. Dann 'springen' die Kurven manchmal.
Das Abfragen ist stabiler, ich berücksichtige jetzt auch den 
Triggerstatus, das hat viel gebracht.

Peter

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich werde die 2 Prozeduren für die Protokollauswertung mit dem DSO 
überarbeiten müssen. Die Timeouts beim Programm liegen sicher auf meiner 
Seite, aber das DSO macht es einem nicht leicht. Anbei zwei kommentierte 
Screenshots vom USB-Protokoll mit seltsamen Anworten vom DSO.

Peter

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

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

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

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

> A host computer reads the waveform data flow

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

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

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


Bewertung
0 lesenswert
nicht lesenswert
Auf Linux lese ich Antworten vom Oszilloskop wie folgt:

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

2. Ein Paket lesen.

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

4. Längenbytes auswerten.

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

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

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

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

9. Weiter mit Punkt 6.

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


11. Eventuell gelesene Daten verwerfen.

12. Eingang flushen, falls noch irgendwas vom Oszilloskop kommt

12. Fertig mit Fehlermeldung.


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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas und Hannes,

also soweit runter wie Hannes geht, kann bzw. muss ich nicht. Ich 
bekomme per Windows-Funktion 'DeviceIoControl' schon z.B: die 10.000 
Byte Pakete bei den Sample-Daten.
Ich habe das Problem, wenn ich unpassende Antworten vom DSO bekomme, 
diese verwerfe und nochmals per 'DeviceIoContrrol' nachfrage ob jetzt 
vielleicht die gülte Antwort kommt, das Programm hängen bleibt wenn das 
DSO doch nichts sendet.
Wenn ich mich aber streng an das Protokoll halte und bei jeder 
Unregelmäßigkeit abbreche, bekomme ich fast keine Daten vom DSO. Also 
z.B: die Bildschirmkopien funktionieren so einfach nicht.
Ich werde aber nochmals von vorne beginnen, es sind ja nur zwei 
Prodzeduren die für das Protokoll zuständig sind. Als Alternative könnte 
ich mit dem Windows USB-Treiber 'winusb.sys' zugreifen, der kann auch 
asynchron arbeiten, nur ist der aber erst ab Vista standardmäßig dabei.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Thomas R. schrieb:
>> To read the with a PC the DSO waveform data, lock keypad and then
>> read the memory depth, waveform storage memory to allocate a large

Im Moment sperre ich das Bedienfeld nur während des Auslesens der 
DSO-Einstellungen.
Nicht wenn ich die Sample-Daten lese, darum gibt es auch die Probleme 
wenn während des Auslesens z.B. der Trigger-Kanal verschoben wird.

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

Ich werte eigentlich schon alles aus, die einzelnen Pakete sind nicht 
das Problem.
Eher der Ablauf der Kommunikation wegen dem Protokoll und den 
unbekannten Antworten.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hannes,

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

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Peter Dreisiebner schrieb:
> Hallo Thomas,
>
> Thomas R. schrieb:
>>> To read the with a PC the DSO waveform data, lock keypad and then
>>> read the memory depth, waveform storage memory to allocate a large
>
> Im Moment sperre ich das Bedienfeld nur während des Auslesens der
> DSO-Einstellungen.
> Nicht wenn ich die Sample-Daten lese, darum gibt es auch die Probleme
> wenn während des Auslesens z.B. der Trigger-Kanal verschoben wird.

Es ändert nichts wenn ich das Bedienfeld auch während dem Auslesen der 
Sample-Daten sperre, ich bekomme leider schnell einen Timeout wenn ich 
die Kanäle verschiebe. Bei anderen Einstellungen, wie Menü ein/aus, 
Volt/DIV ändern, Trigger ändern, Kanal ein/aus, gibt es soweit kein 
Problem.

Peter

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Peter,

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

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

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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe eine Testversion bereitgestellt, vielleicht mag sie jemand 
ausprobieren:
http://www.dreisiebner.at/dso-usb-tool/DSO-USB-Tool_Exe_20120408test.zip

Ich habe alle Vermutungen beim Protokoll entfernt und halte mich an die 
Vorgaben. Prüfsumme, Paketgröße, Antwort auf richtige Nachricht usw. 
wird geprüft, bei Fehler wird abgebrochen. Das Ding funktioniert noch 
immer, was mich jetzt wundert. Ich habe aber einen Timer eingefügt, der 
wie TTscope jede halbe Sekunde die DSO-Einstellungen einliest. Der Timer 
wird bei der Bedienung noch nicht berücksichtigt, man muss also manchmal 
mehrmals auf eine Schaltfläche klicken bis sie reagiert. Bei der 
Kurvendarstellung 'Wave' geht auch alles besser, sogar Autoset und 
Speicher umstellen funktioniert. Nur wenn ich oft und flott die 
sichtbaren Kanäle im Programm in der vertikalen verschiebe gibt es noch 
Timeouts. Dann hilft bei mir nur das Programm zu beenden, die 
USB-Verbindung zu trennen, und die 'dso.exe' am DSO neu starten. Ohne 
Neustart der 'dso.exe' gibt es auf der Konsole eine Fehlermeldung mit 
'rpc' und ungültigen Buffer, habe es mir jetzt nicht genau gemerkt.Will 
den Fehler gerade provozieren und es gelingt mir nicht :-)
Schaut also gut aus.

Peter

von Thomas R. (tinman) Benutzerseite


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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Thomas R. schrieb:
> Peter,
>
> anbei bilder von dem was dein tool macht und was eine
> einfache write und zwei mal read verursachen.
> Wie gesagt, mit deinem tool kommet ein paket der eigentlich zwei
> beinhaltet, einfaches write/2xread tut es wie es sein sollte.
>
> Wenn ich zwischen jedem write/2xread block 50ms lasse
> kann ich 100mal hintereinander lesen und jedesmal sind die daten
> sauber (jedes read saubere paket, checksum ok).
>
> Anbei noch log von deinem tool (im debug mode), habe nur gestartet
> und direkt versucht protocol.inf zu lesen.

ja, ist eindeutig ein Fehler von mir, wenn ich mir den Code jetzt nach 
einiger Zeit wieder anschaue, sehe ich die Fehler sofort. Da war ich am 
Beginn mit dem Protokoll und den vielen Unbekannten überfordert. 
Theoretisch müsste es mit der Testversion besser sein, wobei ich mir 
alles nochmals anschauen werde.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Peter Dreisiebner schrieb:
> Hallo Thomas,
>
> Thomas R. schrieb:
>> Peter,
>>
>> anbei bilder von dem was dein tool macht und was eine
>> einfache write und zwei mal read verursachen.
>> Wie gesagt, mit deinem tool kommet ein paket der eigentlich zwei
>> beinhaltet, einfaches write/2xread tut es wie es sein sollte.
>
> ja, ist eindeutig ein Fehler von mir, wenn ich mir den Code jetzt nach
> einiger Zeit wieder anschaue, sehe ich die Fehler sofort. Da war ich am

nur zur Klarstellung, ich habe den Fehler gemacht noch Daten vom DSO zu 
lesen obwohl es keine passende Antwort vom DSO gab, dadurch der Timeout.
Aber das zusammengestückelte Paket ist nicht von mir, das kommt so vom 
USB-Treiber bzw. vom  'DevideIoControl'-Aufruf zurück. Da habe ich 
keinen Einfluss.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

jetzt habe ich auch wieder sofort einen Timeout bei der 
Kurvendarstellung, obwohl ich nichts geändert habe und es gestern so gut 
funktioniert hat. Aber hier ist die erwähnte Fehlermeldung von der 
Konsole:

usb_recv: RPC for non-existent buffer

Ohne Neustart der 'dso.exe' geht dann nichts mehr. Schön langsam glaube 
ich, ich sollte es bleiben lassen.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

so einen Versuch noch:
http://www.dreisiebner.at/dso-usb-tool/DSO-USB-Tool_Exe_20120408btest.zip

Ich lese jetzt die Kanäle getrennt ein, also Bedienfdeld, sperren, 
DSO-Einstellungen lesen, Sample-Daten für Kanal x lesen, Bedienfeld 
entsperren, Kurve anzeigen, dann das gleiche für den anderen Kanal. 
Jetzt geht es wieder ohne Probleme, nur wer weiß wie lange?
Bei den anderen Funktionen im Programm gibt es ansont bei mir keine 
Fehler.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

sorry, falls ich mit den vielen Postings lästig bin.
Ich habe die Exe vom letzten Link nochmals aktualisiert. Die Anzeige der 
Kurven ist jetzt gleichzeitig, das verwirrt sonst. Getestet habe ich 
auch unter Windos 7, im Moment lauft es wie es soll. Ich kann am DSO 
kurbeln wie ich will, kein Hänger.
Nur ab 4 ms/DIV wird das Triggern träge, da gibt es Aussetzer, ich lese 
die Daten bei Triggerstatus Triggered, Auto- und Scan Modus.

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

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die aktuelle Version ist mit Code wieder online:
http://www.dreisiebner.at/dso-usb-tool/

Peter

Edit: Nebenbei lauft das Tool unter Windows 7, und ich ändere immer 
wieder die Kanäle am DSO, jetzt sind es 8400 Kurven die ohne Fehler in 
einem Stück gelesen wurden. Sieht man wenn man die 'Debug'-Option 
anklickt.

von Thomas R. (tinman) Benutzerseite


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

unsinn

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

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

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

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

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

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

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

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

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

von Thomas R. (tinman) Benutzerseite


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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Thomas R. schrieb:
> jo, soweit alles ok auf dem bench. Für handheld leider keine
> veränderungen sichtbar.

wenn es dieselben Fehler in den USB-Datenpaketen sind wie du schon 
gepostet hast, weiß ich im Moment nicht was ich tun kann.

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

Mit autostop meinst du 'Single Sequenz'? Jetzt verwende ich Auto (2), 
Triggered (3) und Scan (4).

> - im roll mode wird eine linie gezeichnet zwischen alten/neue daten,
> da sollte eigentlich nix sein.

Ja, habe ich auch bemerkt, da müsste ich die Daten extra untersuchen, 
muss ich mir anschauen.

> -im stop mode kann man die letzte wave nicht verschieben, wobei ich
> denke hier bist du noch gar nicht fertig (wegen zoom usw.)

Fertig? Ha, ein Scherz :-)
Vor lauter Ideen weiß ich gar nicht wo ich anfangen soll. Ich habe nur 
keine Erfahrung mit dem verarbeiten und aufbereiten von Messdaten. Ich 
mache das alles nur weil es mich interessiert, von können ist keine 
Rede.

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

Beim Auslesen hat sich nichts geändert, müsste gleich funktionieren.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Thomas R. schrieb:
> Das es träge wird ist klar. Zwei kleine kosmetische fehler habe
> entdeckt:
> - im roll mode wird eine linie gezeichnet zwischen alten/neue daten,
> da sollte eigentlich nix sein.

ich habe bemerkt, dass ich um ein Pixel zu weit unten zu zeichnen 
beginne, ist geändert.
Die Daten die ich zeichne bekomme ich so wie dargestellt. Ich habe 
keinen Anhaltspunkt für alt und neu, zumindest in den Settings finde ich 
keine passenden Wert dazu. Und wenn Samples auf Null liegen kann ich 
nicht entscheiden ob die jetzt richtig oder falsch sind. Wenn ich die 
Samples nicht verbinde, gibt es Lücken in der Darstellung.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich glaube das mit dem Protokoll passt jetzt. Habe auch unter Windows 7 
64 bit getestet, lauft ohne Probleme. Es gibt zwar manchmal Timeouts, 
aber nur wenn man am DSO viel herumschaltet. Übrigens kann man am DSO 
die FFT- oder XY-Darstellung aktivieren und das Programm zeigt die 
normalen Kurven, an das habe ich gar nicht gedacht.
Wenn das jetzt so stabil bleibt könnte man schon einiges mit den 
Sample-Daten anfangen.

Peter

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

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

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

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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

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

da schau her, es funktioniert sogar.

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

Klingt für mich jetzt unlogisch, aber ich schau mir das an. Es 
funktioniert ja beim Bench-DSO, da ändert sich in der Kommunikation 
zwischen Tool und USB-Worker ja nichts.

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

Ist da ein anderer USB-Teiber am PC notwendig? Kann der auch mit dem 
Bench-DSO kommunizieren, dann könnte ich den mal installieren zum 
Testen. Wenn das Protokoll gleich ist, woran soll es sonst liegen?

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

ich habe gerade das Programm ebenfalls mit pfDirectUSB kompiliert, die 
Update-Rate ist doppelt so schnell und es lauft ohne Hänger, hätte ich 
jetzt nicht drauf gewettet.
Muss wohl etwas mit dem USB-Treiber anders sein.

Peter

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

von Thomas R. (tinman) Benutzerseite


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

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

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

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

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


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

gute idee, danke.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

>> edit: Ich bau das als Option beim Log-Fenster ein.
>
> gute idee, danke.

ist online aktualisiert. Als Standard wird mit dem USB-Worker gestartet, 
man kann aber jederzeit umstellen. Hier funktioniert es bis jetzt sehr 
gut. Bei den 'Wave Options' -> 'Debug' gibt es auch eine Update/sec. 
Anzeige, da sieht man schön den Unterschied.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

ich habe den Code für die direkte Kommunikation jetzt mehrmals gelesen, 
ein paar Sachen sind mir augefallen.
Bei deinen Beitrag mit dem kaputten USB-Paket fällt mir folgendes dazu 
ein.
Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

Das DSO-Paket mit den knapp 4000 Bytes bekomme ich in einem Stück, da 
habe ich keinen Einfluss. Wenn jetzt zwei Pakete in einem sind, 
passieren Fehler weil ich von falschen Voraussetzungen ausgegangen bin.
Die Prüfsumme stimmt z.B dann nicht, ich lese nur das letzte Byte, aber 
nicht die Position von der Längenangabe im Protokoll wenn die Daten 
größer sind, somit wird das Paket verworfen. Das werde ich ändern. Was 
ich aber mit dem zweiten Paket machen soll weiß ich nicht, das würde 
einfach verloren gehen. Den in dem Moment wo ich das Paket empfange, 
erwartet die aufrufende Prozedur ein Paket zurück, die fragt nicht nach 
ob es noch eins gibt. Wenn das aber so normal ist, muss ich die Logik 
umbauen, geht sicherlich. Zum Glück sind es nur zwei Prozeduren die sich 
um die DSO-Pakete kümmern.

Peter

von Thomas R. (tinman) Benutzerseite


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

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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Thomas R. schrieb:
> wie gesagt, für handheld reicht wenn es ohne die usb worker geht.
> Wenn es also dabei bleibt das die app entweder ohne worker oder
> per option abschaltbar bleibt ist alles ok.

ich gehe über das DSO-Modul nochmal drüber und möchte den USB-Worker 
dann los werden.
Nur mit der Oberfläche muss dann was machen, die wird träge weil die 
USB-Übertragungen blockieren, das übernimmt ja bis jetzt der USB-Worker.

> Klar, es gibt kleine unterschiede bei den DSO settings und dadurch
> geht alles was von den settings abhängig ist nicht, aber das kriege
> ich schon hin (und dann sende dir die lösung dafür).

Wenn du Infos hast, kann ich was einbauen zum Abfragen ob Bench oder 
Handheld.

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

ha, und Video schauen :)

Peter

von Alois N. (alois)


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

schau mal in dein Postfach.

Gruss Alois ;)

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Alois,

danke schön!

von Christoph B. (christoph_b)


Bewertung
0 lesenswert
nicht lesenswert
mal eine kurze Zwischenfrage.

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

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

Gruß Christoph

von Mischmasch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christoph B. schrieb:
> Trigger ist natürlich richtig gesetzt.

Berühmte letzte Worte.

Wie sollen das jemand überprüfen können, wenn du uns nicht einmal 
verrätst, wie der Trigger gesetzt ist?

von Christoph B. (christoph_b)


Bewertung
0 lesenswert
nicht lesenswert
muss er speziell gesetzt werden?

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Christoph,

Christoph B. schrieb:
> muss er speziell gesetzt werden?

da hilft möglicherweise nur das DSO neu einzuschalten.
Ich habe hier auch, aber selten, Probleme mit dem Triggern. Da ich das 
DSO-Tool teste, drücke ich öfters AUTOSET, und habe nur beide Kanäle am 
Probe Check-Signal hängen. Wenn das DSO dann nicht triggerd, hilft auch 
kein manuelles nachbessern, nur das aus-/einschalten oder die 'dso.exe' 
neu starten. Kommt aber wie gesagt sehr selten vor.

Peter

von Christoph B. (christoph_b)


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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Christoph,

Christoph B. schrieb:
> Habe das DSO schon neu gestartet. An dem liegt es nicht

du könntest auch einen Screenshot senden, wo man das Signal und die 
Einstellungen sieht, vielleicht kann dann jemand helfen.

Peter

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
das klingt jetzt wirklich blah ...

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

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

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


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

von Peter D. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe eine neue Version online gestellt, es wird jetzt auf den 
USB-Worker verzichtet:
http://www.dreisiebner.at/dso-usb-tool/

Das Tool ist jetzt eigentlich genauso anfällig für das Einfrieren wie 
vorher, es geht aber ganz gut.
Nur bei der Kurvendarstellung hängt es oft wenn man die Kanäle vertikal 
verschiebt. Ansonst kann man alles machen, unter XP sogar Autoset, dass 
geht bei Windows 7 nicht.

@Thomas und Hannes:
Anbei auch ein Screenshot mit meinen Debug-Ausgaben. Wenn bei der 
Kurvendarstellung die Kanäle verschoben werden bekomme ich die Fehler 
mit falscher Antwort, und danach hängt das Programm direkt beim Aufruf 
des USB-Treibers bei 'DeviceIoControl. Nach Ab-/anstecken des USB-Kabels 
geht es weiter, aber nur kurz, dann kommt meist auf der DSO-Konsole die 
Meldung 'usb_recv: RPC for non-existent buffer'.
Ich weiß nicht wo der Fehler ist oder wie ich damit umgehen soll.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Peter Dreisiebner schrieb:
> Anbei auch ein Screenshot mit meinen Debug-Ausgaben. Wenn bei der
> Kurvendarstellung die Kanäle verschoben werden bekomme ich die Fehler
> mit falscher Antwort, und danach hängt das Programm direkt beim Aufruf
> des USB-Treibers bei 'DeviceIoControl.

also bei TTScope ist es genauso, ein paar mal die Kanäle verschieben und 
die Anzeige friert ein. Ein Neustart von TTScope zeigt dann einen 
Verbindungsfehler.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

so einmal noch, dann gebe ich Ruhe.
Die empfangenen DSO-Datenpakete sind vor dem Einfrieren immer kaputt, es 
fehlt die Prüfsumme.
Ich habe jetzt zehnmal hintereinander getestet, immer dasgleiche, auch 
mit SnoopyPro direkt die USB-Daten angeschaut.
Ich empfange z.B.: "53 04 00 82 02 01" als Antwort, die Längenangabe 
stimmt nicht bzw. die Prüfsumme fehlt. Die Antwort habe ich zuvor aber 
richtig empfangen, erst bei der nächsten Anfrage für z.B. Bedienfeld 
sperren kommt der Fehler zurück.
Es wird wohl ein Fehler in der Firmware sein denke ich, also heißt es 
abwarten.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe den Fehler möglicherweise gefunden, ich habe das Bedienfeld 
zweimal hintereinander entsperrt. Ein Testversion gibt es unter 
folgenden Link, vielleicht mag es wer testen und Rückmeldung geben. Es 
betrifft nur die Kurvendarstellung 'Wave', alles andere funktioniert 
eigentlich ohne Probleme.
http://www.dreisiebner.at/dso-usb-tool/DSO-USB-Tool_Exe_20120413test.zip

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich glaube ich habe einen neuen Fehler beim Alternate-Trigger entdeckt, 
Firmware 2.06.3(120224.0). Ich kann nicht die vertikale Triggerposition 
von Kanal 2 ändern, es wird immer nur Kanal 1 verändert.

Peter

von egonotto (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

 die Triggerposition von Kanal 2 kann man mit V0 einstellen.

MfG
egonotto

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo egonotto,

danke,

egonotto schrieb:
>  die Triggerposition von Kanal 2 kann man mit V0 einstellen.

peinlich, der Hinweis wird sogar eingeblendet wie jetzt erst sehe.

Peter

von Thomas R. (tinman) Benutzerseite


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

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

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

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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Peter

von Thomas R. (tinman) Benutzerseite


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

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

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

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

von Owen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wen ich save to usb drücke speichert er immer nur bilder, kan ich 
irgendwie die daten als xml file doer txt file oder so bekommen mit den 
einzelnen messpunkten?

LG
Owen

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert

von Thomas R. (tinman) Benutzerseite


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

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


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

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

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


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


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

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


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

Es lohnt auch die ersten GPL sources zu laden:

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

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

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

von Thomas R. (tinman) Benutzerseite


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

http://203.81.29.13:7635/

und nocheinmal nur 2.6.13 root_fs.

von Michael D. (mike0815)


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

Gruß Michael

von Lukas P. (parsley)


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

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ach was, seit einer stunde 70k durchgehend.

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

von Random .. (thorstendb) Benutzerseite


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

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

von Fritz S. (team151)


Bewertung
0 lesenswert
nicht lesenswert
Hallo

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

Mfg. team151

von P. K. (dg4ek)


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

Hallo Fritz,

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

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

Gruss
Peter

von yatko (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas R.

(Ich hoffe, es ist erwünscht)

kannst du bitte mal nen neuen Thread aufmachen ? Nach > 730 Beiträgen 
(Glückwunsch :) benötigen einige Browser schon viel Zeit um diesen 
interessanten Thread anzuzeigen.

Neuer Thread sollte vielleicht Link auf diesen Thread beinhalten und 
einen Zwischenstand: was geht und was nicht geht...

Danke an alle Entwickler und Leser
D

von Thomas R. (tinman) Benutzerseite


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

unsinn, geht super schnell, benutze einfach

"Seitenaufteilung einschalten"

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

von Michael D. (mike0815)


Bewertung
0 lesenswert
nicht lesenswert
> unsinn, geht super schnell, benutze einfach
> "Seitenaufteilung abschalten"

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

Gruß Michael

von Johannes R. (johannes_r29)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

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

Nach einer Kalibrierung geht wieder alles einwandfrei.

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

MFG Johannes

von Carsten S. (dg3ycs)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

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

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

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

Gruß
Carsten

von Thomas R. (tinman) Benutzerseite


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

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

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

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

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

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

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

von Johannes R. (johannes_r29)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

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


MFG Johannes

von Thomas R. (tinman) Benutzerseite


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

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

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

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

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

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

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

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

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

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

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

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

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

Was sind die 83E8, 83E9 ?

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Hantek hat ein paar Programmierer gefunden? :-)

von P. K. (dg4ek)


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

@Johannes:

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

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

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

Gruss
Peter

von Johannes R. (johannes_r29)


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

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

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

MFG Johannes

von P. K. (dg4ek)


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

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

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

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

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

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

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

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

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

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

http://203.81.29.13:7635/bootloader.zip

von Thomas R. (tinman) Benutzerseite


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

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

von P. K. (dg4ek)


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

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

Gruss
Peter

von Mischmasch (Gast)


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

von Thomas R. (tinman) Benutzerseite


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

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

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

Seit Samstag habe sogar den neuen Tekway MST:

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

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

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

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

von Gerd E. (robberknight)


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

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

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

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

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

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

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


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

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

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

> Nun ja, ich lasse mich überraschen.

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


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

von Thomas (Gast)


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

von Thomas R. (tinman) Benutzerseite


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

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

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

von Old P. (old-papa)


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

Gruß
Old-Papa

von Leo C. (rapid)


Angehängte Dateien:

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

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

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

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

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

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

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

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


Und dann noch vielen Dank an Peter Dreisiebner für das dso-usb-tool. Und 
zwar für die Linux-Version. Hier ist meine dazu passende udev-Regel
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="049f", ATTRS{idProduct}=="505a", MODE="660", GROUP="dialout"

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

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Da das andere Posting schon lang genug war jetzt extra:

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

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

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

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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leo,

Leo C. schrieb:
> Alternate Trigger.
> Hier scheint überhaupt nichts richtig zu funktionieren. Insbesondere
> kann man den Level von Ch 2 nicht einstellen.

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

Peter

von Mischmasch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Ich glaube, es müßte möglich sein, über die USB-Device-Schnittselle eine
> Netzwerk-Verbindung herzustellen.

Das hat schon mal jemand gemacht:

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

von Leo C. (rapid)


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

von bong (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Zur Zeit versuche ich den Kernel zu finden, den Tekway als Basis
> genommen hat. 2.6.13 ist es nicht.

natürlich ist es 2.6.13

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

von Leo C. (rapid)


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

von Thomas R. (tinman) Benutzerseite


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

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

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

von Jdelphi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hmpf,
das was ich hier so lese, hört sich ja alles sehr sehr positiv an. 
Bekome ja schon fast lust so ein Teil mir zuzulegen, wenn da nicht meine 
Probleme mit den anderen Hantek Produckte währen.

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

Ein tolles DDS-3005 USB Funktionsgenerator mit Zähler und co (Läuft kein 
Stück, das beste was man bei ihm rausbekommen hat, ist ein Sinus mit 
einem Selbstgeschriebenen Programm, die Soft von HAntek geht kein Stück)

Ein tot schickes DSO-5200A (USB Oszi). Man kann mit messen, und dan ist 
schon gut. Den unten beschriebenen Zeitfehler, hab ich hier noch nicht 
getestet.

Und das beste natürlich zum Schluss, ein DSO 1060 Handhald Scope. Mit 
dem war ich auch sehr sehr zufrieden, bis eines tages der Tag kam, an 
dem ich nen fießen Firmwarebug gefunden habe, mich würde es nicht 
wundern, wenn der noch immer vorhanden ist und das auch in anderen 
Scopes von denen. Wenn man mal sehr langsamme Signale beobachten will, 
so im bereich von 1/10 Herz also alle 10 Sekunden einen Impuls oder so, 
stimmt die Zeitbasis vorne und hinten nicht. Je nach dem wo man ist, 
sind Zeitfehler von 33% und mehr möglich.

Firmware oder Softwareupdates kommen für die oben genannten Produkte 
schon seit einem jahr nicht mehr raus.

von P. K. (dg4ek)


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

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter Krengel schrieb:
> das Teil ist auch kein Messgerät sondern ein Spielzeug.

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


> Wenn Du was Gescheites willst, musst Du zumindest eines von denen hier
> kaufen:
>
> http://www.tech-tools.com/dv_main.htm
...
> Die Software ist erste Sahne und die Hardware sowieso.

Und welche Punkte genau bringen dich zu dieser Aussage, im Vergleich zu 
deinem negativen Punkten beim DS05200A?

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

von Jdelphi (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei das Bilt mit dem Zeitfehler.

Deutlich sieht man es vor und nach dem Triggern. der Teil nach dem 
Triger stimmt :-) vorher ist es für die Tonne.

Als LA hab ich jetzt den Open Workbench Logic Sniffer, bekommt man bei 
http://www.watterott.com/ für nur runde 45 Teuro, er unterstütz auch so 
ziemlich alles was ich kenne, bis auf NIM und ECL signale.

Passend dazu gibt es noch den Bus Pirate, mit dem kann man ganz gut 
schalten und walten. Ebenfals hat er einen kleinen LA eingebaut. Der is 
so das schweizer Taschenmesser was Digitaltechnik angeht.

Aber gut das gehört ja eigentlich alles nicht hier her.

von Thomas R. (tinman) Benutzerseite


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

von P. K. (dg4ek)


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

von Jdelphi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kein komentar zu dem Bild oben, mit dem Timingproblem vor und nach dem 
Triger. Schade.

Könnte das villeicht mal jemand mit nem anderen Scope testen.

Naja, passend zu dem Theard, hab ich nochmal das DDS-3005 ausgekramt. 
Nachdem ich wieder mittels Delphi ein 1kHz signal rausholen konnte, ging 
es nicht mehr. Beim neu anschließen kam immer, USB Gerät nicht erkannt.

von Carsten S. (dg3ycs)


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

von Peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter Krengel schrieb:
> Die Frage beantwortet sich von allein, wenn
> Du mit beiden Geräten arbeitest.
>
> Während Du mit dem Scope wie Du selbst sagst,
> nicht einmal simple Protokolle decodieren kannst,
> geschweige denn exakte Timing Analysen durchzuführen,
> ist dies mit dem DigiView problemlos und äußerst
> exakt möglich.

Hm, ich glaube da gab es wohl ein Missverständnis.

Ich hatte den Eindruck mit "Spielzeug" hättest du den Hantek LA5034 
Logic-Analyzer gemeint (nicht das TEKWAY DST1xx2B Scope). Mich hatten 
eher die Kritikpunkte/Nachteile vom LA5034 gegenüber dem DigiView 
interessiert.

von Robert W. (rwalli)


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

von Thomas R. (tinman) Benutzerseite


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

 :)

von Robert W. (rwalli)


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

von Leo C. (rapid)


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

von Leo C. (rapid)


Angehängte Dateien:

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

von Robert W. (rwalli)


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

von Leo C. (rapid)


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

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leo,

ich habe dein Paket eingespielt und mit einem PL2303 getestet, 
funktioniert einwandfrei. Einen FTDI-Adapter habe ich auch hier, nur 
passen die Pegel nicht zusammen, das kann ich im Moment nicht testen.

Ich verstehe das "install.sh"-Skript nicht, kenne mich mit Linux und 
Shell-Skripten aber auch nicht aus. Wo änderst du die rcS-Datei, oder 
machst du das gar nicht. Der BEGIN/END-Block verwirrt mich, und die 
letzte Zeile ist auskommentiert, oder?

Peter

Edit: Die rcS-Datei wird verändert, nur das wie habe ich nicht kapiert.

von Leo C. (rapid)


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

von rs232 (Gast)


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


> Ich kann auch Module für andere Adapter (z.B. ftdi)
> compilieren, aber leider nicht testen.

kannst du bitte auch für CP210x compilieren?

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

übrigens, eine Toolchain für das Handheld-DSO und Windows habe ich hier 
gefunden:

https://sourcery.mentor.com/sgpp/portal/release845

Ich musste nur folgende Dateien im selben Verzeichnis kopieren:

..\ARM-2009q1\arm-none-linux-gnueabi\libc\armv4t\lib\libgcc_s.so.1 nach 
libgcc_s.so
..\ARM-2009q1\arm-none-linux-gnueabi\libc\armv4t\lib\libc-2.8.so nach 
libc.so.6

Kompiliert habe ich mit folgenden Parametern:

arm-none-linux-gnueabi-gcc.exe -msoft-float -mcpu=arm920t -mtune=arm920t 
-march=armv4t -o hello hello.c

'Hello World', Math-Test, Framebufferzugriff und Watchdog-Einstellung 
auslesen hat funktioniert.

Für das Bench-DSO habe ich leider nichts einfaches für Windows gefunden 
bzw. habe ich mit meinen Versuchen nichts zusammengebracht.

Peter

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leo,

Leo C. schrieb:
> Die Änderung von rcS macht ein awk-Script.

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

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

Vielleicht solltest du die original rcS-Datei nicht löschen, sondern nur 
umbenennen und aufheben. Könnte bei einem Fehler hilfreich sein zum 
wiederherstellen oder vergleichen.

Peter

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Noch eine kleine Bemerkung zum Loch in der Frontplatte fuer die 
LA-Buchse:

bei meinem Voltcraft ist das schon drin, nur mit einem Aufkleber 
zugepappt, der natürlich an der Stelle auch nicht richtig hält und sich 
deswegen immer ablöst.

Gruss Micha

von Leo C. (rapid)


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

von Leo C. (rapid)


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

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nein, die Länge stimmt bei mir. Sie hält nicht, weil darunter das große 
Loch fuer die LA-Buchse ist und wahrscheinlich für die Steifheit der 
Folie die Klebefläche zu klein ist

Gruss Micha

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
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?
  Say Y here if you want to use a CP2101/CP2102 based USB to RS232
  module will be called cp2101.

von rs232 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Würde es das cp2101-Modul auch tun?

ja bitte.

von Leo C. (rapid)


Angehängte Dateien:

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

von Thomas S. (doschi_)


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

von Thomas R. (tinman) Benutzerseite


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

ja, leider (ich schreibe morgen warum das).

von Peter Lustig (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> ja, leider

Lass mich mal raten: Der LA-Zusatz wird nicht an Endkunden verkauft oder 
nur in Neugeräte eingebaut. :(

von Thomas R. (tinman) Benutzerseite


Angehängte Dateien:

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

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
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.
sqlite> select * from sqlite_master;
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))
table|tb_cn|tb_cn|453|CREATE TABLE tb_cn(id integer primary key,nindex varchar(100),alias varchar(100) null,topic varchar(100),content varchar(2500))
table|tb_por|tb_por|889|CREATE TABLE tb_por(id integer primary key,nindex varchar(100),alias varchar(100) null,topic varchar(100),content varchar(2500))

sqlite> select content from tb_por where id=2;
Você pode usar o menu AQUISIÇÃO para controlar como o osciloscópio adquire os dados da forma de onda. Opções:
◆^34<Amostragem> (padrão): representa com mais exatidão as formas de onda.
◆^35<Detecção de Pico>: detecta falhas e reduz a possibilidade de falhas <serrilhado>.
◆^36<Média>: reduz o ruído aleatório (não relacionados ao trigger).
Para usar o menu AQUISIÇÃO pressione o botão ACQUIRE.
...

von Martin (Gast)


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

Vielen Dank!

von Yatko J. (denim)


Bewertung
0 lesenswert
nicht lesenswert
wo findet man denn die erwähnte bug liste ?


und danke für die neue version

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Yatko Jaens schrieb:
> wo findet man denn die erwähnte bug liste ?

Etwas weiter oben:
Beitrag "Re: TEKWAY DST1xx2B Oszilloskop"

von Christoph B. (christoph_b)


Bewertung
0 lesenswert
nicht lesenswert
habe die neueste FW Version jetzt oben und ich finde das das Oszi etwas 
besser und schneller reagiert. Vieleicht ist es aber auch Einbildung ;-)

Neu ist auch das das Oszi automatisch nach dem FW Update neu startet.

Auch funktioniert nun die Refresh Rate im Menü ;-)

von Thomas S. (doschi_)


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:

>  Thomas R. (tinman) Datum: 11.07.2012 18:28
>  dst1kb_2.06.3_15202b_fact_120625.0_.up (2,7 MB, 35 Downloads)
>  anbei neueste firmware für Tekway/Hantek/Voltcraft
>
> Beseitigt sind bugs 1,2,3,9,10,11,12,17
>
> Man kann sehen das am bug 4 wird gearbeitet, filter geht jetzt
> bis 495MHz statt 249MHz (funktion ist aber noch aus).

Hallo Thomas,
Vielen Dank dafür!

von Klaus D. (kdre)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

darf ich fragen woher die FW kommt?
Gibt es sie irgendwo offiziell?
Hast Du sie selbst modifiziert?

Gruß,
 Klaus

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Klaus D. schrieb:
> Hi,
>
> darf ich fragen woher die FW kommt?

hersteller

> Gibt es sie irgendwo offiziell?

ja hier

> Hast Du sie selbst modifiziert?
>

nein

von Klaus D. (kdre)


Bewertung
0 lesenswert
nicht lesenswert
Danke! Werde die FW heute Abend testen :-)

von Klaus Dieter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:
> ja, leider (ich schreibe morgen warum das).

Jetzt spannst du uns aber ganz schön auf die Folter :-D Spaß beiseite, 
was gibts denn für Neuigkeiten? Entschuldige, dass ich nochmal frage, 
aber ich bin so gespannt ;-)

von Nicht neu (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich setze 10 Euro darauf, dass Hantek, Tekway das alles nicht so gemeint 
hat, es sich anders überlegt hat, vorgibt nie so etwas vorgehabt zu 
haben, dass alle Ansprechpartner gewechselt haben, man von irgendwelchen 
Absprachen nichts mehr weiß, usw. usw. Der ganz normale Chinesische 
Wahnsinn eben.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

Betrifft Firmware 120625:

Thomas R. schrieb:
> Beseitigt sind bugs 1,2,3,9,10,11,12,17
> ...
> Bug 14 habe nicht getestet.

also den Bug 14 kann ich nicht mehr feststellen, dürfte wirklich 
beseitigt sein.

Peter

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
oha, das ist nett wenn der wirklich weg ist.

von John (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe da mal was gebastelt, damit die Beschriftung zu den erweiterten 
Innereien passt...
Farbton des Hintergrunds passt noch nicht 100%, ohne farbkalibrierten 
Scanner/Drucker ist das schwer zu treffen.
Falls Interesse besteht kann ich es wenns fertig ist als PDF oder Corel 
Draw posten.

von Peter D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Betrifft Firmware 120625:
Wenn man das Menü ein/ausblendet, pendelt sich das Signal erst wieder 
nach kurzer Zeit zum horizontalen Trigger ein. Bei der 120423 Firmware 
geht das sofort. Stört nicht, fällt aber auf. Irgendwie kommt mir die 
Signaldarstellung weicher/flüßiger vor.

Bei FFT wird das Gitter jetzt so angezeigt wie im Displaymenü 
ausgewählt, also nicht mehr nur die Linien.
Bei höheren Frequenzen, so ab 20 MHz ist die FFT-Darstellung schon um 
einiges anders, vorallem bei Sinussignalen, bei Rechteck sehe ich nicht 
soviel Unterschied.

Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.