Hi, ja ich weiss, das Thema gab es hier schon einige Male, aber vlt. mag ja doch jemand noch etwas dazu sagen: Ich möchte mir als Gelegenheitsbastler ein USB Oszilloskopvorsatz kaufen. Ich weiss, das es darüber geteilte Meinungen gibt, ich würde es aber aus Platzgründen einem extra Gerät vorziehen - auf bzw. unter meinem Basteltisch steht eh der PC. Eigentlich interessieren mich folgende beiden Geräte, die auch preislich gerade noch so passen: Rigol VS5042 (ohne D) Picoscope 2205 Beide gibt's bei C, aber ansonsten in Deutschland kaum (günstigere Quelle?). Welches von den beiden ist empfehlenswerter? Für das Rigol sprechen m.E. die besseren technischen Daten, beim Picoscope nutzt die Software besser die Möglichkeiten der Darstellung am PC aus, ausserdem ist noch ein Funktionsgenerator (wenn auch nur begrenzt leistungsfähig) enthalten. Rigol: + Bandbreite 40 MHz + Samplerate 400 Ms/s + Buffer 1 Ms + Min. Timebase 10 ns/div - Software nutzt nicht Möglichkeiten des PCs Picoscope: - Bandbreite 25 MHz - Samplerate 200 (100) Ms/s - Buffer 16 Ks - Min. Timebase 50 ns/div + AWG ++ Software sieht ziemlich gut aus Das ich damit keine Messungen an HF-Schaltungen vornehmen kann ist mir schon klar, aber für einfache Analogschaltungen und ein bisschen Digitaltechnik <= 20 MHz sollten die Teile doch ausreichen? Nur welches der beiden?! Danke für eure Meinungen... Markus EDIT: Wenn jmd. einen Vorschlag/Angebot (kann auch gebraucht sein) für ein günstiges standalone DSO hat, welches nicht schlechter als die og. ist, würde mich das dennoch interessieren, vielleicht kippt ja meine Meinung noch :-)
Beim Rigol darf man wohl davon ausgehen, dass dieses Teil technisch deren echten DSOs entspricht, nur eben mit reiner PC-Fernbedienung ohne LCD und Knöpfe. Die hier gelegentlich als Quelle genannte Firmy Sky Messtechnik bietet lt. Webseite "alle Rigol Geräte".
USB-Geräte mit zu erwartender langer Lebensdauer haben ein Problem: Wenn der Hersteller für dein schönes neuen Betriebssystem deines schönen neuen Notebooks keine Software mehr für das nicht mehr vertriebene Gerät bietet, dann sitzt du in der Tinte. Wenn man sanft mit ihnen umgeht haben Oszis in Bastelkreisen oft ein recht langes Leben, deutlich länger als ein Notebook. Allein das wär's mir wert, nach einem Standalone zu suchen. Das Rigol DS1052E ist ausser Reichweite?
Hi, stimmt, so kann/muss man es natürlich auch betrachten. Also zum Neu-Listenpreis ist ein DS1052E nicht drin :-( Evtl. in der Bucht irgendwo... Diese Owon Dinger sind eher unbrauchbar, oder? Ciao... Markus
Die Suchfunktion sollte dir helfen, diese Frage taucht öfter auf. Hängt wohl von den Ansprüchen ab, unbrauchbar sind sie wohl nicht.
Hallo ich knüpfe mal an diesen Thread an... welches USB Oszi würdet ihr denn empfehlen bei den folgenden Infos: - 4 Kanal analog - >=200MHZ analoge bandbreite - Win 10 optional: 1. 8 Kanal digital Eingang 2. Protokoll analyse für CAN / SPI /I2C ... merci
H. D. schrieb: > Hallo > ich knüpfe mal an diesen Thread an... Stimmt, der alte ist ja erst 10 Jahre alt, da kann man schon mal an eine "laufende" Diskussion anknüpfen :-)
H. D. schrieb: > Hallo > ich knüpfe mal an diesen Thread an... > > welches USB Oszi würdet ihr denn empfehlen bei den folgenden Infos: > > - 4 Kanal analog > - >=200MHZ analoge bandbreite > - Win 10 > > > optional: > 1. 8 Kanal digital Eingang > 2. Protokoll analyse für CAN / SPI /I2C ... > > merci Ich hab hier ein PicoScope aus der 2000er Serie, gibt es in verschiedenen Ausbaustufen. Für Debuggen neben der Software-Entwicklung ist es praktisch, besonders, weil es wenig Platz braucht und man z. B. Screenshots schnell in die Design-Dokumentation einarbeiten kann. USB-Protokollanalyse ist gut und hilfreich, alleine dafür war es sein Geld wert. Zu anderen Protokollen kann ich nichts sagen. An ein echtes Oszilloskop kommt es (leider) nicht heran. Die mitgelieferten Probes sind grenzwertiger Chinakram. Die Bedienerführung ist bemüht, aber teilweise britisch-skurril, Trigger-Menüs überdecken z. B. gnadenlos das Signal, so dass man nicht sieht, was man da einstellt. Trigger Holdoff gibt es anderswo seit Generationen, hat sich aber noch nicht bis Britannien herumgesprochen, sehr lästig, wenn man repetierende Signale mit komplexerem Verlauf hat. Interessant wäre ein Vergleich mit Alternativen. Leider kenne ich da nichts.
Markus M. schrieb: > Rigol VS5042 (ohne D) > Picoscope 2205 Rigol USB-Oszi - noch nie gehört. Zu Picoscope habe ich Reviews gefunden. Die Software ist für alle Modelle gleich. https://www.youtube.com/watch?v=fqyOuWzK3go https://www.youtube.com/watch?v=hP2FJPidNow Was willst du denn üblicherweise messen ? Lass mal hören.
üblicherweise: CAN, Flexray, LIN, SPI, I2C analog, digital bis etwa 200MHZ analog (DSO) 500MS/s minimum vllt besser 1GS/s
H. D. schrieb: > üblicherweise: > > CAN, Flexray, LIN, SPI, I2C > analog, digital bis etwa 200MHZ analog (DSO) > 500MS/s minimum vllt besser 1GS/s Ist ja schon etwas jenseits von Minimalausstattung. Ab Picoscope 3000er Serie sollte das gehen. Preise ab ca. 2.000 € bis erheblich darüber. Ich würde versuchen, einen deutschen Distributor zu finden und mit dem eine Teststellung zu vereinbaren. Wenn du dann mal berichten könntest, inwieweit das Ergebnis deinen Anforderungen genügt, wäre das hilfreich.
Schau dir noch die Saleae Logic pro 8 und 16 an: https://www.saleae.com/de/ 500Ms digital, 50Ms analog
Kater schrieb: > > 500Ms digital, 50Ms analog Das ist aber kein Oszilloskop, sondern auf der Analog-Seite ein Witz. Ich bin jetzt übrigens mächtig angepisst von Picotech: Im Forum wird seit mehr als 5 Jahren vehement Trigger Holdoff gefordert. Die Briten ignorieren aber konsequent jede Frage danach. Ich habe jetzt zweimal versucht, im Forum wieder danach zu fragen. Resultat: meine Posts werden nicht veröffentlicht. So kann man natürlich auch vermeintliche Kundenzufriedenheit präsentieren, indem man kritische Nachfragen unterdrückt. Trotzdem scheinen die Dinger wohl so ziemlich das Einzige zu sein, was es auf mäßigem Preisniveau gibt. Wenn man was ordentliches haben will, bleiben doch wohl nur die üblichen Verdächtigen und ein höherer finanzieller Einsatz.
Dieter R. schrieb: > Ich hab hier ein PicoScope aus der 2000er Serie, gibt es in > verschiedenen Ausbaustufen. Für Debuggen neben der Software-Entwicklung > ist es praktisch, besonders, weil es wenig Platz braucht und man z. B. > Screenshots schnell in die Design-Dokumentation einarbeiten kann. Bei Picoscope sollte man aber dran denken, dass die Software unter OS/X nur mit sehr großen Schmerzen und kaum brauchbar läuft und der Hersteller auch offensichtlich kein Interesse daran hat, daran irgend etwas zu ändern.
Dieter R. schrieb: > Trotzdem scheinen die Dinger wohl so ziemlich das Einzige zu sein, was > es auf mäßigem Preisniveau gibt. Wenn man was ordentliches haben will, > bleiben doch wohl nur die üblichen Verdächtigen und ein höherer > finanzieller Einsatz. Kannst Du da ein paar USB-Geräte aufzählen? Ich wäre bereit auch etwas mehr Geld in die Hand zu nehmen, wenn es dann funktioniert.
Torsten R. schrieb: > > Kannst Du da ein paar USB-Geräte aufzählen? Ich wäre bereit auch etwas > mehr Geld in die Hand zu nehmen, wenn es dann funktioniert. Es gibt was von Keysight: https://www.keysight.com/de/de/products/oscilloscopes/handheld-modular-and-usb-oscilloscopes.html Ist aber derzeit (leider) nicht meine Preisklasse, deshalb habe ich absolut Null Ahnung davon. Ich will nicht mal ausschließen, dass die zugekauft sind. Ich weiß es einfach nicht.
Dieter R. schrieb: > Trotzdem scheinen die Dinger wohl so ziemlich das Einzige zu sein, was > es auf mäßigem Preisniveau gibt. Wenn man was ordentliches haben will, > bleiben doch wohl nur die üblichen Verdächtigen und ein höherer > finanzieller Einsatz. Ich hab' so ein Ding und es ist für meine Zwecke (meist mehr als) ausreichend. Allerdings bin ich auch kein Hardcore-Hardwarefreak, sondern schaue höchstens mal, ob an einem m68k/Coldfire alle Signale so aussehen, wie sie sollen. Das Gerät betreibe ich an einem Linux-PC. Die Verfügbarkeit der entsprechenden Software für Linux war für mich ein wesentliches Auswahlkriterium. Übrigens kann man statt beim "großen C" (z.B.) auch bei Meilhaus kaufen. Zumindest zum damaligen Zeitpunkt war das Gerät dort (deutlich) günstiger.
Markus F. schrieb: > Ich hab' so ein Ding und es ist für meine Zwecke (meist mehr als) > ausreichend. Tja, das hängt eben ganz stark von der Applikation ab. Ich arbeite zur Zeit an einem Projekt, das "bloß" netzsynchron arbeitet, also schlappe 100 Hz Halbwellenfrequenz. Aus schaltungstechnischen Gründen sind allerdings beide Halbwellen nicht exakt gleich, was dazu führt, dass die Anzeige wegen fehlendem Holdoff wild hin und her springt und die (wichtige) Analyse der Unterschiede im Verhalten beider Halbwellen nahezu unmöglich macht. Äußerst nervig. Leider stellt sich Picotech hier völlig stur, die wissen es halt besser als die Anwender.
Dieter R. schrieb: > was dazu führt, dass die > Anzeige wegen fehlendem Holdoff wild hin und her springt Hm, bei meinem alten Hameg würde ich in dem Fall eher "Line Sync" triggerung anstelle hold off verwenden. Wegen fehlendem 50Hz Netztrafo ist das bei einem USB-Oszi leider nicht intern möglich. Aber vielleicht hilft ja ein altes 6-9V AC Steckernetzteil und ein BNC Stecker am Triggereingang. Dieter R. schrieb: > Im Forum wird > seit mehr als 5 Jahren vehement Trigger Holdoff gefordert. Die Briten > ignorieren aber konsequent jede Frage danach. Ich habe jetzt zweimal > versucht, im Forum wieder danach zu fragen. Auch schon mal ein Ticket bei der Hotline erstellt? Wobei ich fürchte daß sich der Hold off mit anderen Funktionen (Software-Tiefpaßfilter) in die Quere kommt. Andere Oszis zeigen bei aktivem Filter kompletten Unsinn (Einschwingstörungen) am linken Bildschirmrand an. (siehe Hameg Thread). Das PicoScope hat dieses Problem nicht (und schneidet vermutlich links vom Bildschirmrand den Bereich des Einschwingen ab). Gruß Anja
Anja schrieb: > > Aber vielleicht hilft ja ein altes 6-9V AC Steckernetzteil und ein BNC > Stecker am Triggereingang. Du hast (sorry) nicht viel Ahnung vom Thema und vom Picoscope gar keine. Das hat keinen Triggereingang. Vermutlich erfolgt die Trigger-Signalaufbereitung direkt im digitalen Signalzweig. Das könnte erklären, warum man ein Holdoff vermeiden will wie der Teufel das Weihwasser. Es erklärt auch zwanglos, weshalb die Triggerung sowieso etwas instabil ist, sie hängt halt am Rauschen des A/D-Wandlers. Wäre es so (was ich nicht weiß, aber stark vermute), dann hätte das ganze Gerätekonzept einen fundamentalen Designfehler. Bei einem ordentlichen Oszilloskop ist das getrennt. Sicher könnte man auch das nachrüsten, aber es wäre ein Riesenaufwand und würde die FPGA-Logik sprengen, weshalb man dann andere Features abschalten muss (das habe ich jetzt nicht frei erfunden, sondern Äußerungen der Moderatoren zu früheren Anfragen legen dies nahe). Kann man alles tun und sollte man bei einem ordentlichen Gerät auch machen, aber den Briten ist es wohl lästig, seit mehr als fünf Jahren.
Anja schrieb: > Wobei ich fürchte daß sich der Hold off mit anderen Funktionen > (Software-Tiefpaßfilter) in die Quere kommt. Andere Oszis zeigen bei > aktivem Filter kompletten Unsinn (Einschwingstörungen) am linken > Bildschirmrand an. (siehe Hameg Thread) Kannst du etwas konkreter werden. Hameg Threads gibt es wie Sand am Meer. Dieter R. schrieb: > Das hat keinen Triggereingang. Wenn ich mich recht entsinne, meine ich auch schon mal Pico Modelle mit Ext. Trigger In gesehen zu haben. Das weiß Anja aber mit Sicherheit besser.
Markus F. schrieb: > Übrigens kann man statt beim "großen C" (z.B.) auch bei Meilhaus kaufen. > Zumindest zum damaligen Zeitpunkt war das Gerät dort (deutlich) > günstiger. du weißt aber schon, dass Meilhaus-Preise ohne Mwst. sind ?
Schrauber schrieb: > Wenn ich mich recht entsinne, meine ich auch schon mal Pico Modelle mit > Ext. Trigger In gesehen zu haben. Das weiß Anja aber mit Sicherheit > besser. Sorry, ich hätte es nochmal wiederholen sollen, ich sprach hier von der 2000er Serie. Die 3000er Serie hat lt. Website (nicht bei allen Modellen) einen Triggereingang. Als potenzieller Anwender würde ich ohne eigene Tests aber NICHT davon ausgehen, dass der besser funktioniert. Im Beschreibungstext ist Picotech nämlich mächtig stolz auf seine schon 1991 erfundene volldigitale Triggerung, während andere immer noch einen getrennten Signalzweig haben, Zitat: "The majority of digital oscilloscopes still use an analog trigger architecture based on comparators." Die Helden bei Picotech haben offenbar bis heute nicht verstanden, warum andere das so machen.
Dieter R. schrieb: > und vom Picoscope gar keine. > Das hat keinen Triggereingang. .. sitzt bei meinem PicoScope 5444A direkt zwischen Kanal D und Signal-Generator-Ausgang. Schrauber schrieb: > Kannst du etwas konkreter werden. Hameg Threads gibt es wie Sand am > Meer. Beitrag "Re: Rohde Schwarz RTM3004 - merken, wollen oder können die das nicht?" Beitrag "Re: Rohde Schwarz RTM3004 - merken, wollen oder können die das nicht?" Gruß Anja
Anja schrieb: > > .. sitzt bei meinem PicoScope 5444A direkt zwischen Kanal D und > Signal-Generator-Ausgang. > Dann hast du ja Erfahrung damit. Hat der denn die gleichen Beschränkungen wie der digitale Signalzweig, siehe oben, oder ist der separat und ordentlich aufgebaut? Dann wäre es allerdings noch unverständlicher, warum es Picotech seit 1991 nicht geschafft hat, Trigger Holdoff zu implementieren.
Schrauber schrieb: > Anja schrieb: >> Wobei ich fürchte daß sich der Hold off mit anderen Funktionen >> (Software-Tiefpaßfilter) in die Quere kommt. Andere Oszis zeigen bei >> aktivem Filter kompletten Unsinn (Einschwingstörungen) am linken >> Bildschirmrand an. (siehe Hameg Thread) > > Kannst du etwas konkreter werden. Hameg Threads gibt es wie Sand am > Meer. Vermutlich diesen Beitrag "Rohde Schwarz RTM3004 - merken, wollen oder können die das nicht?"
Dieter R. schrieb: > Markus F. schrieb: > >> Ich hab' so ein Ding und es ist für meine Zwecke (meist mehr als) >> ausreichend. > > Tja, das hängt eben ganz stark von der Applikation ab. Ich arbeite zur > Zeit an einem Projekt, das "bloß" netzsynchron arbeitet, also schlappe > 100 Hz Halbwellenfrequenz. Aus schaltungstechnischen Gründen sind > allerdings beide Halbwellen nicht exakt gleich, was dazu führt, dass die > Anzeige wegen fehlendem Holdoff wild hin und her springt und die > (wichtige) Analyse der Unterschiede im Verhalten beider Halbwellen > nahezu unmöglich macht. Äußerst nervig. > > Leider stellt sich Picotech hier völlig stur, die wissen es halt besser > als die Anwender. You are holding it wrong!!! Beide Halbwellen auf den Schirm; bessere (direkte) Vergleichbarkeit, und dein Problem (2019) im Thread (2009) ist gelöst?
Ich habe ein Analog Discovery 2 und bin zufrieden. Allerdings habe ich keine Vergleichsgeräte, außer meinem uralten 20MHz Ananlog Oszi. Gruß Daniel
2 Cent schrieb: > Beide Halbwellen auf den Schirm; bessere (direkte) Vergleichbarkeit, und > dein Problem (2019) im Thread (2009) ist gelöst? Genau, und beim nächsten Mal triggert er auf die ZWEITE Halbwelle statt auf die erste! Und danach wieder auf die erste, oder auch die zweite. Einfach zufällig verteilt. Und was machst du übrigens bei Signalen, bei denen gerade drei Wellenzüge auf den Schirm passen? Ablenkfrequenz raufdrehen, damit es nur zwei sind? Das ging nur bei alten Analog-Oszilloskopen mit variabler Zeitbasis. Wir reden hier aber nicht von einem Analog-Oszilloskop, sondern von einem digitalen. Da funktioniert die Datenaquisition leider anders, nur ein UNABHÄNGIGES Trigger-System mit Holdoff würde hier helfen. Die Picotech-Leute sind aber mächtig stolz darauf, dass sie beides integriert haben. Das ist eine offensichtliche Design-Fehlentscheidung. Von Keysight gab es mal vor vielen Jahren ein Grundsatzpapier, als die Firma noch HP hieß, das genau diesen Ablauf beschrieb. Das Papier ist mit Sicherheit älter als die Picoscope, offenbar haben deren Entwickler es aber entweder nicht gelesen oder nicht verstanden.
Dieter R. schrieb: > Interessant wäre ein Vergleich mit Alternativen. Leider kenne ich da > nichts. Dieses USB-Scope hier hat laut Datenblatt auch Trigger hold-off https://www.welectron.com/TiePie-Handyscope-HS6-DIFF-USB-Oszilloskop-Serie https://www.welectron.com/mediafiles/datasheets/tiepie/TiePie-Handyscope-HS6-DIFF-Datasheet.pdf
Chris K. schrieb: > Dieses USB-Scope hier hat laut Datenblatt auch Trigger hold-off > https://www.welectron.com/TiePie-Handyscope-HS6-DIFF-USB-Oszilloskop-Serie > > https://www.welectron.com/mediafiles/datasheets/tiepie/TiePie-Handyscope-HS6-DIFF-Datasheet.pdf Danke für den Hinweis. TiePie aus den Niederlanden. Ich habe von der Firma noch nie etwas gehört, aber es klingt interessant. Nach der Beschreibung (Holdoff gekoppelt an Abtastrate) scheinen sie etwas ähnliches wie Picotech gemacht zu haben, Triggerauswertung nach dem A/D-Wandler, aber wohl unabhängig vom Rest der Signalverarbeitung und deshalb kontinuierlich durchlaufend. Das könnte ein brauchbarer Kompromiss sein.
Daniel B. schrieb: > Analog Discovery 2 Der hat m.E. ein paar tolle Features und kann echt viel, aber leider aht er keine BNC-Buchsen.
Das Hantek 6022be/bl hat zumindest unabhängige Opensource Software als Alternative, falls beim Hersteller was fehlt?
Kurz gesagt, ich hab mir das Hantek 6022BE hier geholt: https://www.ebay.de/itm/Hantek-6022BE-Car-Automotive-48MSa-s-USB-Digital-Oscilloscope-PC-Based-2CH-20MHz/183238477801?epid=2256173125&hash=item2aa9dd47e9:g:APkAAOSwLNpblfYi (bitte bei Interesse auch selber gucken, eventuell gibt es noch günstigere Anbieter) Alles zusammen ca. 50€ 8bit/48ms/s, hat ein paar Schwachstellen (kann keine Spannungen > 5V messen), ansonsten für den Hobbybereich bei dem Preis super. Wenn man den Tastkopf von 1x auf 10x stellt, kann man Spannungen bis max. 50V messen. Man kann sich dann auch Sachen wie Frequenz, RMS, max. Peak usw. direkt anzeigen lassen, weswegen ich mein eigentlich besseres Analogoszi nur noch für HF-Messungen rauskrame.
1 | Item Description: |
2 | |
3 | Features: |
4 | - Small size, easy to carry. |
5 | - High refresh rate and high sampling rate. |
6 | - More than 20 kinds of automatic measurement functions,built-in multiple languages can be operated, convenient to measure. |
7 | - Two channels, both economical and high performance. |
8 | - The shell adopts anodized aluminum, which is not only beautiful, but also greatly improves the surface hardness of aluminum alloy, with good heat resistance and abrasion resistance. |
9 | - The USBXITM standard interface is convenient to insert the USBXITM chassis, which comprises a combination of instruments, USB2.0 interface, power free, and desktop oscilloscope similar to interface, easy to handle. |
10 | - High performance, 48MS/s real-time sampling, 20MHz Bandwidth. |
11 | - Be suitable for notebook computer, product line maintenance, be used easily on business. |
12 | - Operating System: Windows 7, Windows NT, Windows 2000, Windows XP, VISTA, Windows 8. |
13 | - 23 measurement functions, PASS/FAIL Check, be suitable for technical application. |
14 | - Waveform average, persistence, intensity, invert, addition, subtraction, multiplication, division, X-Y plot. |
15 | - Save waveform in the following: text file, jpg/bmp graphic file, MS excel/word file. |
16 | - One computer can connect many DSO, extend channel easily. |
17 | Model: Virtual Oscilloscope |
18 | Channel: 2 Channels |
19 | Band Width: 20MHZ |
20 | Record Length: 10-60K/CH |
21 | Input Impandence: 1MΩ 25pF |
22 | Max Sample Rate: 48MS/s |
23 | Vertical Resolution: 8 Bit |
24 | Gain Range: 20mV-5V, 8Steps |
25 | DC Accuracy: ±3% |
26 | Timebase Range: 1ns-9000s, 39 Steps |
27 | Vertical Adjustable: Yes |
28 | Input Protection: Diode clamping |
29 | X-Y: Yes |
30 | Trigger Mode: Auto, Normal and Single |
31 | Trigger Slope: +/- |
32 | Trigger Level Adjustable: Yes |
33 | Trigger Type: Rising edge, falling edge |
34 | Pre/Post Trigger: 0-100% |
35 | Waveform Display: Port/line, waveform average, persistence, intensity. |
36 | Network: Open/Close |
37 | Vertical Mode: CH1, CH2, Dual, ADD |
38 | Math: FFT, addition, subtraction, multiplication, division. |
39 | Cursor: Frequency, Voltage |
40 | Compensation Range: 15~45pF |
41 | Operation Environment: 0~50°C,0~80%RH |
42 | Storage Environment: -20~60°C,0~90%RH |
43 | Product Weight: 716 G / 25.26 Ounces |
44 | Product Dimensions (L*W*H): 230*170*75 MM / 9.06*6.69*2.95 Inches |
45 | Package Weight: 716 G / 25.26 Ounces |
46 | Package Dimensions (L*W*H): 230*170*75 MM / 9.06*6.69*2.95 Inches |
47 | Retail Packaging: Yes, Colored Box |
48 | |
49 | Package Including: |
50 | |
51 | 1 x Virtual Oscilloscope |
52 | 1 x USB Data Cable |
53 | 2 x Oscilloscope Probes |
54 | 1 x Plastic Parts |
Andreas Rückert schrieb: > Das Hantek 6022be/bl hat zumindest unabhängige Opensource Software als > Alternative, falls beim Hersteller was fehlt? z.B. fehlt beim Hersteller die SW für Linux und MacOSX, die gibts als Free Open Source im Netz, beides läuft auch unter Windows, beides wird aktiv weiterentwickelt: https://github.com/OpenHantek/OpenHantek6022 https://sigrok.org/wiki/Hantek_6022BE
Markus F. schrieb: > jürgen schrieb: >> Retail Packaging: Yes, Colored Box > > toll. Ein echtes k.o.-Kriterium ;) € 51,98. Das scheint mir eher das K.O.-Kriterium zu sein ;-)
Noch zwei Fragen: 1. Anja hat sich leider nicht mehr dazu geäußert, ob die Leistungsfähigkeit der externen Triggerung beim Picoscope besser ist als die interne. Bleibt also die Vermutung, dass beides bestenfalls gleich ist. 2. Die mitgelieferten Probes beim Picoscope (zumindest bei meinem mit 100 MHz Bandbreite) sind ziemlich simple Dinger und außerdem riesig, jedenfalls für alles mit < 2,54 mm Raster. Kennt jemand bezahlbare 10:1 Probes, mit 100 bis vielleicht 300 MHz Bandbreite, die besser SMD-geeignet sind?
Hantek 6022BE Ich zitiere mal " - Software unzulänglich und defizitär - Kopplung AC/DC nicht umschaltbar - hoher Rauschanteil bei 20mV/DIV - Minimum sind nur 20mV/DIV - fehlerhafte Darstellung bei 5V/DIV-Einstellung - fehlerhaft verkürzte Signaldarstellung bei Zeitbasis >1s/DIV " Wen der Rest noch interessiert, kann den Testbericht lesen http://www.afug-info.de/Testberichte/Hantek_6022BL/ Den USB-Owon für 80 € habe ich momentan auf dem Schirm. Wen den hat, lasst mal was hören.
Max P. schrieb: > Der hat m.E. ein paar tolle Features und kann echt viel, aber leider aht > er keine BNC-Buchsen. Das Basisgerät nicht, aber es gibt verschiedene Ansteckmodule: https://shop.trenz-electronic.de/de/24946-Analog-Discovery-BNC-Adapter-Board?c=29 Ich habe es damals als Bundle gekauft. Gruß Daniel
@Alexander: im eevblog Thread gibt es massig Tipps zum 6022 und dort findet man mehrere freie Software Projekte, die einige Probleme beheben.
Alexander schrieb: > Ich zitiere mal > > " > - Software unzulänglich und defizitär > - Kopplung AC/DC nicht umschaltbar > - hoher Rauschanteil bei 20mV/DIV > - Minimum sind nur 20mV/DIV > - fehlerhafte Darstellung bei 5V/DIV-Einstellung > - fehlerhaft verkürzte Signaldarstellung bei Zeitbasis >1s/DIV > " > > Wen der Rest noch interessiert, kann den Testbericht lesen Das sind überwiegend Macken der original Hantek Software, dafür gibt es FOS Software. 1. Hantek SW 2. Stimmt, ich plane eine HW-Modifikation dazu (ein 74HC4052 oder 53 als dead-bug und etwas Hühnerfutter) und werde es in meine SW (OpenHantek6022) einbauen, aber erst im Winter ;) 3. 8-bit sind halt 8-bit, aber mit 10x Oversampling (OpenHantek6022) kommt man auf effektive 9.6 bit und 10 dB mehr SNR bei FFT. 4. ja, das Leben ist hart. 5. Hantek SW 6. Hantek SW Mann, wollt ihr tüfteln oder "maken"? Wir sind hier im Mikrocontroller-Forum und nicht bei "Cool Maker in 3 Tagen". Es ist alles gut vorgekaut vorhanden, HW, SW, etc; ein Fest für Nachrichtentechniker. Außerdem sind hier im Thread (mindestens) zwei OpenHantek-Entwickler unterwegs und wer mehr wissen will schaut bei unseren Freunden von Down-Under. Ciao, Martin
Danke Anja für den Link, da nehme ich jeden Pico mit Handkuss. > Beitrag "Rohde Schwarz RTM3004 - merken, wollen oder können die das > nicht?" Martin H. schrieb: > wer mehr wissen will schaut bei > unseren Freunden von Down-Under. "Down-Under" habe ich früher gerne geschaut, halte es aber mittlerweile für komplette Zeitverschwendung und die Reviews für reine Narrerei. Der sagt halt auch was, dass die Werbung was abwirftt "Da drunten" habe ich noch kein Review gesehen, das so viele Infos bietet und Bugs aufdeckt wie dieser eine deutsche Kanal. 6022 Entwickler hier bei µC? Na und? Deshalb taugt die Gurke auch nicht viel. Die OpenHantek Software ist zwar anscheinend besser als das Original, aber mit 20mV kannst du noch nicht mal die Restwelligkeit messen.
Martin H. schrieb: > (mindestens) zwei OpenHantek-Entwickler Na und? schrieb: > 6022 Entwickler hier bei µC? Na und? Deshalb taugt die Gurke auch nicht viel. Nicht die HW-Entwickler (die sitzen in China bei Hantek), sondern neben mir auch daybyter, die was zur Open-Source-Software (OpenHantek bzw. OpenHantek6022) sowie zur Firmware (Hantek6022API) beitragen. Bitte unterscheiden: - Hantek6022 -> Hardware - OpenHantek -> Free Open Source Software für div. Hanteks sowie speziell fürs 6022 (OpenHantek6022) - Hantek6022API -> Free Open Source Firmware Na und? schrieb: > "Da drunten" habe ich noch kein Review gesehen, das so viele Infos > bietet und Bugs aufdeckt wie dieser eine deutsche Kanal. Hast Du den 6022-Thread komplett gelesen? Da ist sehr viel mehr Info als hier im µC. https://www.eevblog.com/forum/testgear/hantek-6022be-20mhz-usb-dso/
Na und? schrieb: > Die OpenHantek Software ist zwar anscheinend besser als das Original, > aber mit 20mV kannst du noch nicht mal die Restwelligkeit messen. Ich sammle sinnvolle Anregungen für die nächsten Releases. Was hättest Du den gerne an Auflösung und Abtastrate? Mit 10x Oversampling kommt OpenHantek6022 bei effektiven Abtastraten <= 1MS/s fast auf effektive 10 bit, also ca. 1mV Auflösung auf 1V. Für langsamere Raten ist da noch Steigerung möglich, je 4x Oversampling gibt es ein Bit dazu *); Randbedingungen sind halt max. 15 MS/s Rohdaten (damit zwei Kanäle stabil über USB laufen, das ist der HW-Beschränkung geschuldet, die Samples in Echtzeit ohne großen Puffer zum PC zu übertragen). *) https://www.cypress.com/file/236481/download
Na und? schrieb: > "Down-Under" habe ich früher gerne geschaut, halte es aber mittlerweile > für komplette Zeitverschwendung und die Reviews für reine Narrerei. Der > sagt halt auch was, dass die Werbung was abwirftt Full Ack. _Aber_: Dortiges Forum ist frei von solchen Einflüssen (wie hier auch), und Stellenweise ein sehr gutes Nachschlagewerk (wie hier auch).
Angehängte Dateien:
-
Early_8060_Concept_.jpg
310 KB
2 Cent schrieb: > Stellenweise ein sehr gutes Nachschlagewerk Lesetip für's Wochenende: https://www.eevblog.com/forum/testgear/old-fluke-multimeters/ Wer ein 8060A sein Eigen nennt, findet dort jede Menge Neues direkt vom Vater des Instruments - drtaylor. P.S.: Und von den Umgangsformen dort könnten hier einige was lernen.
Kann man mit OpenHantek das USB-Oszilloskop eigentlich auch als Logic Analyzer nutzen? (so wie es z.B. mit dem Labnation SmartScope geht)
Bin sehr froh mit meiner PICO4444 weil er 4 DIFFERENTIAL input hat. Fuer meine anwendingen perfect weil ich oft differential signale oder gleichzeitig signalen die verteilt sind auf mehrere (potential-unabhangige) platinen messen musz Aber $$
Horgel schrieb: > Kann man mit OpenHantek das USB-Oszilloskop eigentlich auch als Logic Analyzer nutzen? Nein, das kann sigrok besser. Außerdem kann (wenn Du das 6022BL meinst) das Gerät entweder nur als Scope oder nur als LA arbeiten, je nach Schalter auf der Rückseite. Meine Hauptanwendungen sind Audio mit Line-Pegel und einstellige MHz Logikschaltungen, dahingehend habe ich OpenHantek6022 optimiert. Ansonsten nehme ich für logische Dinge wie I2C, I2S, CAN, etc. sigrok mit 'nem Saleae-Clone (das ist eigentlich ein break-out-board für EzUSB, Saleae hat für ihre HW auch nur die Cypress Applikation-Notes umgesetzt und eigene SW dazugeschrieben). Und wenn man an den Saleae-Clone zwei 8-Bit-Wandler hängt, bekommt man ein Hantek-kompatibles Scope. :)
Martin H. schrieb: > Na und? schrieb: > > Ich sammle sinnvolle Anregungen für die nächsten Release Eye Diagramm, manuelle bzw Auto Umschaltung von ADC, gain, attenuator. Merging Arduino Ozi (serial) MIT Hantek welche dieselben Daten ansehen, sowie optional mehr low speed channels und LA bits
Chris schrieb: > Eye Diagramm > manuelle bzw Auto Umschaltung von ADC, gain, attenuator. > Merging Arduino Ozi (serial) MIT Hantek welche dieselben Daten ansehen, > sowie optional mehr low speed channels und LA bits 1. Dazu gibt es die Funktion "digital phosphor", Du kannst den Wert "Digital phosphor depth" in Config/Scope hochsetzen. Ich nehme mal die Anregung mit, zusätzlich zu den Flanken / und \ auch X zu programmieren -> Eye. 2. Auto mag ich nicht, schnell mal mit der Maus auf dem Gain-Feld gerollt geht genauso schnell. 3. Ich implementiere nur Dinge, die ich auch habe (und daher auch testen kann). 4. Das ist 'ne HW-Sache im Hantek - schau Dir mal die EzUSB-Doku an: https://www.cypress.com/file/44956/download (Seite 1-6) https://www.cypress.com/file/126446/download (darf's ein bisschen mehr sein?)
Martin H. schrieb: > 1. Dazu gibt es die Funktion "digital phosphor", Du kannst den Wert > "Digital phosphor depth" in Config/Scope hochsetzen. > Ich nehme mal die Anregung mit, zusätzlich zu den Flanken / und \ auch X > zu programmieren -> Eye. Eye ist schon was mehr als "digital phosphor". Es ist sehr praktisch bei I2C oder RS485 um zu sehen ob Terminierungen passen oder nicht. Auch bei RF , LI-FI usw wird dies gebraucht, bzw wenn man es hat kann man sehr schnell eine Aussage auf die Qualität schliessen. Auch interessant bei Hausbus wo andere Leitungen, speziell 230V mit Dimmer nebenher laufen. > > 2. Auto mag ich nicht, schnell mal mit der Maus auf dem Gain-Feld > gerollt geht genauso schnell. Auto meinte ich was anderes, die Schalter welche man dazuinstalliert, INA117, AC, 4:1 Attenuator, +Offset, SGA, ... über z.B. eine codierte Bereichsumschaltung zu machen wo ein uC sitzt, diese die Codierung auswertet und dann die reed Relay umschaltet anstelle der Mäusetastatur oder Schalter für die Reed-Releays. Im Prinzip wollte ich hier nur mal Anklingeln ob ein Optionfeld mit Häkchen für Relays bzw OptionGroup für z.B. SGA (1x, 2x, 5x, 10x, 25x, 50x, 100x 250x) und entsprechendes einstellbares Oversampling, (da ja teilweise die Bandbreite geschmälert wird) möglich wäre. Ich habe, AC 0.1uF, 4:1 Attenuator, Offset von +- auf -1V aufwärts oder manual einstellbar, SGA (2x hintereinander, stufen sind oben), INA117 , Ich habe 2x SGA benutzt, damit ich Sensoren direkt einfach messen kann, sonst würde mir auch eine Stufe reichen.
Dieter R. schrieb: > ob die > Leistungsfähigkeit der externen Triggerung beim Picoscope besser ist als > die interne. Die externe Triggerung ist auf jeden Fall "anders". Es gibt weniger Einstellmöglichkeiten (keine Hysterese, keine RUNT Triggerung). Ob das jetzt "besser" ist kann ich nicht sagen. Meistens verwende ich einen der 4 Kanäle für den Trigger. Gruß Anja
Martin H. schrieb: > Was hättest Du den gerne an Auflösung und Abtastrate? > Mit 10x Oversampling kommt OpenHantek6022 bei effektiven Abtastraten <= > 1MS/s fast auf effektive 10 bit, also ca. 1mV Auflösung auf 1V. 1mV/DIV wären super. 5mV/DIV würden mir notfalls acuh reichen.
Markus M. schrieb: > Nur welches der beiden?! Soll es eigentlich auch einen Logic Analyzer haben? Da ist das Picoscope ist überwältigend. Von so viel Platz auf dem Schirm können Benchtops träumen. https://www.youtube.com/watch?v=hP2FJPidNow
Stromwandler schrieb: > 1mV/DIV wären super. > 5mV/DIV würden mir notfalls acuh reichen. Das ist Anzeige, nicht Auflösung.
Hallo zusammen, da es thematisch passt, hänge ich mich hier mal ran. Ich habe beruflich und privat diverse stationäre Oszis und suche für mich privat noch ein mobiles, das ich z.B. einfach in meine Werkstatt tragen kann. Beruflich nutze ich noch ein Mittelklasse-Picotech, deren Software finde ich akzeptabel (würde aber jederzeit ein Standalone-Gerät vorziehen). Anschluss an ein Windows-10-Laptop (Linux, Mac sind kein Thema). Anwendung: Alles was so anfallen kann. Budget: Ca. bis 200 EUR. Dafür würden die kleine Picoscopes 2204 und 2205 bekommen. Wobei ich 10 (!) bzw. 25 MHz Bandbreite schon grenzwertig niedrig finde. Das Hantek6022 wurde weiter oben diskutiert und scheint keinen variablen Eingangsverstärker zu haben - ein no-go. Da wäre das PS besser (https://www.picotech.com/oscilloscope/2000/picoscope-2000-specifications - immerhin 50 mV fullscale im kleinsten Bereich). Das Hantek 6254 dagegen sieht schon nach mehr aus: https://www.aliexpress.com/item/32719506364.html - kennt das jemand? https://www.eevblog.com/forum/testgear/hantek-6254bc-usb-oscilloscope-250mhz/ Ich sehe momentan zwei Möglichkeiten: 1. was billiges (< 50 EUR) aus China, wobei ein variabler Eingangsverstärker ein Muss wäre oder 2. eben etwas "ordentliches" für bis 200 EUR. Noch jemand Ideen? Wenn ich bei Sigrok schaue, finde ich auch nichts, was mich vom Hocker reisst: https://sigrok.org/wiki/Supported_hardware#Oscilloscopes
Picoscope, nichts unter 100 MHz, 200 ist besser (man will ja auch mal Flanken sehen), auf Speichergröße achten. Viel hilft viel. Picoscope bei Ebay (kann man bei reinfallen). Oder sparen. Oder sich was dazu schenken lassen, damit es reicht. Weihnachten ist schneller, als einem lieb ist.
Angehängte Dateien:
Martin schrieb: > Das Hantek6022 wurde weiter oben diskutiert und scheint keinen variablen > Eingangsverstärker zu haben - ein no-go. Das 6022 hat x1, x2, x5, x10 für beide Kanäle, siehe Skizze.
Ich habe mir dieses USB-Scope zugelegt: https://www.ebay.de/itm/New-DSCope-C20-Basic-Version-2-Channel-USB-Oscilloscope-50MHz-200MSa-s/391610620075?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 ...und bin begeistert. Für meine Hobby-Belange mehr als ausreichend.
Lothar M. schrieb: > Ich habe mir dieses USB-Scope zugelegt: > https://www.ebay.de/itm/New-DSCope-C20-Basic-Version-2-Channel-USB-Oscilloscope-50MHz-200MSa-s/391610620075?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 > > ...und bin begeistert. > Für meine Hobby-Belange mehr als ausreichend. Schön. Vielleicht. Leider weiß man wenig, was deine Hobby-Belange denn ausmacht. Was mich aber irritiert, sind zwei Fragen: 1. Beim (angeblichen?) Hersteller kostet es fast das doppelte, siehe https://www.dreamsourcelab.com/shop/. 2. Hat das Gerät ein CE-Zeichen? Wenn nicht, könnte der Import zum Glücksspiel werden. Ich habe vor ein paar Tagen eine Sendung aus Kanada vom Zoll abgeholt, Gerät von Agilent, also eher unverdächtig. Das Wichtigste, was den Zoll interessierte, war das Vorhandensein des CE-Zeichens. Ich habe im Laufe der Jahre schon einige Geräte importiert. Dies war das erste Mal, dass der Zoll explizit danach gesucht hat.
Dieter R. schrieb: > Was mich aber irritiert, sind zwei Fragen: > > 1. Beim (angeblichen?) Hersteller kostet es fast das doppelte, siehe > https://www.dreamsourcelab.com/shop/. > Nö, nicht das Doppelte, es kostet in deinem Link ~163€ Da habe ich wohl ein Schnäppchen gemacht, aber es ist immernoch für 100 Tacken zu haben. > 2. Hat das Gerät ein CE-Zeichen? Wenn nicht, könnte der Import zum > Glücksspiel werden. Ein CE-Zeichen konnte ich nicht darauf finden, ist mir aber auch egal, CE-Zeichen-Aufkleber habe ich hier im Dutzend rumliegen. Was solls? Das Gerät wird von dem besagten Anbieter als Brief versandt, war relativ schnell bei mir angekommen, Zoll war nicht involviert. Schönes Gerät, tolle Software, was will ich mehr?
Martin H. schrieb: > Das 6022 hat x1, x2, x5, x10 für beide Kanäle, siehe Skizze. Das wusste ich nicht. Danke für die Info. Habe etwas im ellenlangen eevblog-Artikel gelesen... das Teil scheint ja ein saleae mit angeflanschten ADCs zu sein. Warum nicht. Mit den x1-x10 ist es etwas besser, aber hat immer noch 0.5 V FS im kleinsten Bereich, für kleine Signale immer noch nicht toll. Du legst Dich mit der Software ja richtig ins Zeug, wie ist die Wahrscheinlichkeit, dass die auch für Windows 10 problemlos funktioniert? Auf Deiner Github-Seite steht bei "supported OS" Windows (1) mit einer nicht referenzierten Fussnote. Sowas ist bei Handy-Verträgen üblich und weist idR auf einen Haken hin (iPhone XX gratis * (*: ab 2. Monat 100 EUR/Monat, Mindestlaufzeit 10 Jahre) Lothar M. schrieb: > Ich habe mir dieses USB-Scope zugelegt: Das hatte ich noch gar nicht auf dem Radar. Kickstarter aus China - mal ganz was neues. Guter Tip! Was hältst Du von der Software - ist sie brauchbar? ("Status: DSView software is in a usable state and has had official tarball releases. However, it is still work in progress. Some basic functionality is available and working, but other things are still on the TODO list") .Auf jeden Fall macht es einen viel besseren Eindruck (HW-mässig) als das Hantek. Dieter R. schrieb: > 1. Beim (angeblichen?) Hersteller kostet es fast das doppelte, siehe Das fand ich auch seltsam. Versteh einer die Chinesen.
Martin schrieb: > Was hältst Du von der Software - ist sie > brauchbar? ("Status: DSView software is in a usable state and has had > official tarball releases. Ganz einfach: Lade dir die Software herunter und probiere sie aus. Wenn die Soft keine dazu passende Hardware findet, geht sie in den Test-Modus und du kannst Eingangssignale simulieren. Du kannst die Soft umfänglich auch ohne Hardware austesten. In dem Moment, wo die Soft eine Hard findet, stellt sie sich automatisch auf die gefundene Hard ein und die Bedienemente werden entsprechend dargestellt. Der Chinese verkauft die blanke Hardware, ohne jegliche Beschreibung, Bedienungsanleitung oder Software, auch ohne Hinweis wo man die Soft finden könnte, einfach im Briefkarton. Erst dachte ich, das ist ein Fake. Als ich dann aber die dazugehörige Soft im Netz fand, war/bin ich begeistert. Genauigkeit und Bedienerfreundlichkeit sind super. Alle dazugehörigen Informationen findest du hier: https://www.dreamsourcelab.com/download/
Martin schrieb: > Auf Deiner Github-Seite steht bei "supported > OS" Windows (1) mit einer nicht referenzierten Fussnote. Sowas ist bei > Handy-Verträgen üblich und weist idR auf einen Haken hin (iPhone XX > gratis * (*: ab 2. Monat 100 EUR/Monat, Mindestlaufzeit 10 Jahre) Das ist die Startseite vom OpenHantek-Projekt, da habe ich leider keinen Schreib-Zugriff drauf. Bei OpenHantek sind zwei Unter-Projekte angesiedelt, das originale Repo openhantek (unmaintained) und mein Fork OpenHantek6022, der Text auf openhantek.org bezieht sich aktuell nur auf openhantek. Der grobe Unterschied: openhantek : Supported operating systems: Linux, MacOSX, Windows¹, Android Supported devices: DSO2xxx Series, DSO52xx Series, 6022BE/BL OpenHantek6022 : OpenHantek6022 is a DSO software for Hantek USB digital signal oscilloscopes 6022BE / BL. Development OS is Linux, but I got the feedback that the program also works under MacOSX and Windows. Ich entwickele und teste OpenHantek6022 unter Debian Linux, bei jedem Push nach github werden aber CI-Runs angestoßen, travis für Linux und MacOSX, (https://travis-ci.org/OpenHantek/OpenHantek6022) und appveyor/ für Win32 und Win64 (https://ci.appveyor.com/project/Ho-Ro/openhantek6022), so dass ich extreme Regressions sehe. Testen für die Exoten müssen aber leider die User, ich habe auf keinem Rechner ein MacOSX oder Windows (mit Ausnahme eines rudimentären virtuellen Win7, das ich dann und wann starte, um nach großen Änderungen (vor allem am UI) einen Smoke-Test durchzuführen und einen Screenshot aufzunehmen.
Martin H. schrieb: > Das ist die Startseite vom OpenHantek-Projekt, da habe ich leider keinen > Schreib-Zugriff drauf. Ich hab' eine Änderung vorgeschlagen und mein Pull-Request wurde akzeptiert, http://openhantek.org/ ist up-to-date und verweist jetzt auf https://github.com/OpenHantek/openhantek als auch auf https://github.com/OpenHantek/OpenHantek6022 Danke für den Hinweis an Martin (Gast) Ciao, Martin
Lothar M. schrieb: > Ich habe mir dieses USB-Scope zugelegt: > Ebay-Artikel Nr. 391610620075 Sieht attraktiv aus. In der Artikelbeschreibung wird Linux erwähnt, aber manchmal bedeutet das bei Chinesen soviel wie "der Kernel erkennt das Device" oder "man könnte Linux Software dafür schreiben". Ist Software für Linux mitgeliefert (oder downloadbar)?
Stefanus F. schrieb: > Ist Software für Linux mitgeliefert (oder downloadbar)? Source code for Linux: https://github.com/DreamSourceLab/DSView/archive/0.99.tar.gz https://github.com/DreamSourceLab/DSView says: DSView is an GUI programe for supporting various instruments from DreamSourceLab, including logic analyzer, oscilloscope, etc. DSView is based on sigrok project.
Martin H. schrieb: > DSView is an GUI programe for supporting various instruments from > DreamSourceLab, including logic analyzer, oscilloscope, etc. DSView is > based on sigrok project. den Commits nach, ist die Arbeit aber von einem Jahr eingestellt worden...
Martin H. schrieb: > DSView is an GUI programe for supporting various instruments from > DreamSourceLab Cool, gefällt mir. Ich habe aber schon ein Tischgerät, sonst würde ich das jetzt kaufen.
Martin H. schrieb: > Ich entwickele und teste OpenHantek6022 unter Debian Linux... .. > Testen für die Exoten müssen aber leider die > User, ich habe auf keinem Rechner ein MacOSX oder Windows.. Oh, danke für die Blumen. Nun ja, das ist eben der große Graben zwischen Linux und dem winzigen Rest der Welt. Für die Belange von Linux kann ich das ja auch voll verstehen, da gibt's keinen Gerätetreiber vom Hersteller. Also mußt du auf sowas wie LibUsb etc. zurückgreifen, um quasi außen um das OS herum auf den Hantek zugreifen zu können. Aber bei Windows ist das anders, da sollte man entweder auf den originalen Gerätetreiber aufsetzen (der wird schließlich vom OS verwaltet) oder sich der Mühe unterziehen, einen besseren und zugleich zum original voll kompatiblen Gerätetreiber zu schreiben (quasi ein Update des Originals) - was du verständlicherweise wohl eher nicht tun möchtest. Und nun kommt das Übel: Du versuchst, mit genau derselben Methode wie bei Linux auch bei Windows vorzugehen. Das ist so etwa dasselbe, als wenn du mit einer Brechstange versuchst, deine Taschenuhr zu reparieren. Die linuxartige Software zum Umgehen des OS wird von Windows freiwillig nicht akzeptiert, weil sie eben kein konformer Gerätetreiber ist. Und deswegen müßte man zur Brechstange (Zadig) greifen, um es dennoch hinzubiegen. Das wiederum geht nur, wenn man alle ordentlichen Wege beseitigt, also alles an Originaltreiber-Zeugs eliminiert. Verstehe mal bitte, daß so etwas nicht die richtige Vorgehensweise bei Windows ist und deshalb ganz sicher auch von fast allen Leuten abgelehnt wird. Immerhin kommt da ein Stück Treibersoftware ins System, von der man eben nicht weiß, ob sie sauber läuft, kein versehentliches Einfallstor für Schadsoft mit sich bringt und so weiter. Fazit: Wenn du eine Anwendung für Windows schreiben willst, dann sollte diese auf das Windows-API und damit auf die darunter werkelnden Original-HW-Treiber aufsetzen - und nicht auf sowas wie LibUsb und Konsorten. Das ist eben anders als bei Linux. Ansonsten kostet ein altes Notebook mit einem Win7..10 drauf kein großes Geld und es wäre hilfreich zum Austesten. Aber das ist deine Angelegenheit. W.S.
Naja W.S., deshalb hat ja Martin auch geschrieben, das er es nur für Linux schreibt und es auch nur dort ausgiebig testen kann. Wenn es denn so ist, das man es auch unter Win oder Mac zum Laufen bekommt, auch wenn der Weg vielleicht etwas steinig ist, dann ist das für mich in Ordnung. Es wird auch keiner gezwungen die Software zu benutzen. Für mich ist das so schon in Ordnung, muß aber fairerweise dazu sagen das ich diesbezüglich derzeit keinen Bedarf habe, weder für Win noch für Linux oder Mac. Ich denke um Schadsoftsoftware muß man sich unter Linux deutlich weniger Gedanken als unter Linux machen. Das ist eher ein Windowsproblem, aber dafür hat man ja entsprechende Software am Laufen und lebt mit der damit verbundenen Performanceeinbuße.
Zeno schrieb: > Ich denke um Schadsoftsoftware muß man sich unter Linux deutlich weniger > Gedanken als unter Linux machen. Muß natürlich so sein: Ich denke um Schadsoftsoftware muß man sich unter Linux deutlich weniger Gedanken als unter Windows machen.
W.S. schrieb: > Wenn du eine Anwendung für Windows schreiben willst, dann sollte > diese auf das Windows-API und damit auf die darunter werkelnden > Original-HW-Treiber aufsetzen - und nicht auf sowas wie LibUsb und > Konsorten. Das ist eben anders als bei Linux. Ansonsten kostet ein altes > Notebook mit einem Win7..10 drauf kein großes Geld und es wäre hilfreich > zum Austesten. Aber das ist deine Angelegenheit. Warum sollte ich eine Anwendung für Windows schreiben wollen, wenn ich keinen Windows-Rechner habe, auf dem die läuft? - Ach nee, ich kann mir ja einen kaufen für kleines Geld. :) Nochmal zum Verständnis der Historie: Das Programm (openhantek) wurde von den ursprünglichen Entwicklern seit 2010 unter Linux entwickelt und als freundliche Geste wurde auch Mac und Win unterstützt. Es begann mit dem DSO-2090 und später kamen die Modelle 2XXX und 5XXX dazu, es erfolgte der Umstieg auf Qt5, letzter Zuwachs waren die Modelle 6022, die sich aber deutlich anders verhielten und daher immer wieder Probleme bereiteten, viele Fallunterscheidungen etc. README (von 2010):
1 | The UI is written in C++/Qt 4 and uses OpenGL to draw the graphs. It was tested with the DSO-2090, test results with other models are welcome. |
Ich hab's Anfang des Jahres geforkt, nachdem der Maintainer sich verabschiedet hat und ich einige Erweiterungen implementieren wollte. Alle Nicht-6022-Komponenten habe ich aus der SW entfernt, weil ich sie nicht testen kann, dadurch wurde die Struktur auch einfacher. Die Zeilen mit "#ifdef Win/Mac" halten sich in Grenzen, auch Dank des einheitlichen Treiber-Modells, deshalb blieben die drin. Ich achte stets darauf, dass sich die Win- und Mac-Versionen übersetzen lassen und bekomme auch positives Feedback bezüglich deren Funktion. Wenn Du eine Software möchtest, die sich orthodox windowsmäßig verhält, die gibt es doch; was spricht gegen das Original vom Hersteller anstelle einer "von fast allen Leuten abgelehnten Lösung"?
Zeno schrieb: > auch unter Win oder Mac zum Laufen > bekommt, auch wenn der Weg vielleicht etwas steinig ist Mac ist auch unixoid und setzt komplett und native auf libusb auf. Es ist sogar noch unixoider als Linux, denn es basiert auf BSD Unix. Auf jeden Fall ist dort nichts steinig.
Martin H. schrieb: > Warum sollte ich eine Anwendung für Windows schreiben wollen, wenn ich > keinen Windows-Rechner habe, auf dem die läuft? Martin H. schrieb: > Wenn Du eine Software möchtest, die sich orthodox windowsmäßig verhält, > die gibt es doch; was spricht gegen das Original vom Hersteller anstelle > einer "von fast allen Leuten abgelehnten Lösung"? Du hast eine Version für Windows im Portfolio, die du selbst nicht auszutesten vermagst. Das hattest du ausdrücklichst in einem anderen Zusammenhang hier mal geschrieben. Ebenso auch, daß du keinen Bedarf sehen würdest, unter Windows auch den für Windows gedachten Treiber verwenden zu wollen. Ich habe mir das gemerkt und habe die daraus erwachsenden Probleme, die du ja auch im o.g. eevblog gelesen hast, mal auf den Punkt gebracht. Einfach der notwendigen Klarheit willen. Das ist alles. Meine persönlichen Belange sind hier offtopic. Aber ich sehe durchaus die Probleme, die Leute haben werden, wenn sie auf das Hantek angewiesen wären, weil sie z.B. nicht das Geld für einen richtigen Oszi ausgeben können - und die auch mal deine Anwendung benutzen wollen. Oder die nur mal sehen wollen, wie sich denn dein Programm so macht im Vergleich zum Original. Also nochmal: 1. Punkt: Warum solltest du was für Windows schreiben... Antwort: Nein, keine Rede vom Sollen, allenfalls vom Wollen - und das ist deine Entscheidung. Aber wenn die darin steckende arbeit nicht vergebene Mühe sein soll, dann sollte das auch ordentlich unter Windows laufen. 2. Punkt: Wenn ich eine Software möchte... Nein, ich persönlich nicht, siehe oben. Es ärgert mich, wenn Leute persönlich werden, wenn ich ihnen einen Sachverhalt zu erläutern versuche. Bleibe lieber auf der Sachebene und versuche mal, das eigentliche Treiber- und Software-Problem aus Sicht von Windows und dessen Benutzern zu verstehen - jedenfalls sofern du eine Windows-Version im Portfolio hast. W.S.
Martin H. schrieb: > Mac ist auch unixoid und setzt komplett und native auf libusb auf. Es > ist sogar noch unixoider als Linux, denn es basiert auf BSD Unix. > Auf jeden Fall ist dort nichts steinig. Das muß ich Dir erst mal so glauben, da ich es nicht ausprobiert und sehr wahrscheinlich mangels Hantek USB Oszi auch nicht ausprobieren werde. Auch wenn Mac unixoider als Linux ist, so geht man doch an einigen Stellen den Weg etwas anders. Für Linux gemachte Programme funktionieren oft nicht ohne Weiteres auf dem Mac, selbst dann nicht wenn sie für Mac kompiliert wurden. Die Installation von Gimp z.B. verlief seinerzeit nicht so glatt. Da mußte man erst noch etwas anpassen. Es gibt nicht umsonst diverse Software, die helfen soll die Installation einiger Programme auf dem Mac zu erleichtern (z.B Homebrew).
Zeno schrieb: > Das muß ich Dir erst mal so glauben, ... Stimmt, glauben heißt nicht wissen. Ich kann dich aber erleuchten. ;) Ein (alter) Screenshot eines Mac-Users (ra1nb0w): https://user-images.githubusercontent.com/1543838/55322443-ab696600-547c-11e9-9b23-61cdc183d0cf.png Zeno schrieb: > Für Linux gemachte Programme funktionieren > oft nicht ohne Weiteres auf dem Mac, selbst dann nicht wenn sie für Mac > kompiliert wurden. Die Installation von Gimp z.B. verlief seinerzeit > nicht so glatt. Da mußte man erst noch etwas anpassen. Es gibt nicht > umsonst diverse Software, die helfen soll die Installation einiger > Programme auf dem Mac zu erleichtern (z.B Homebrew). ...oder macports, aktiv gepflegt von ra1nb0w: https://ports.macports.org/port/openhantek/summary
W.S. schrieb: > Aber wenn die darin steckende arbeit nicht > vergebene Mühe sein soll, dann sollte das auch ordentlich unter Windows > laufen. Danke für die mitfühlenden Worte! Es ist schon daher keine vergebene Mühe, weil es bei mir auf meinem Linux-Laptop so läuft, wie es mir gutdünkt. W.S. schrieb: > jedenfalls sofern du eine > Windows-Version im Portfolio hast. Ich sehe das nicht als Portfolio, sondern eher als Abfallprodukt, das aber zu 100% recycelt werden kann. https://de.wikipedia.org/wiki/Abfallprodukt : Ein Abfallprodukt bezeichnet generell einen Stoff, der erwartungsgemäß bei einem Umwandlungsprozess entsteht und im Sinne des Prozesses keinen weiteren Nutzen darstellt. Abfallprodukte müssen meist in einem Entsorgungsprozess entfernt werden, können aber auch Quelle eines neu zu verwendenden Produktes werden (Recycling).
W.S. schrieb: > Die linuxartige Software zum Umgehen des OS wird von Windows freiwillig > nicht akzeptiert, weil sie eben kein konformer Gerätetreiber ist. Und > deswegen müßte man zur Brechstange (Zadig) greifen, um es dennoch > hinzubiegen. Das ist der Grund, weswegen ich bei meinen Basteleien aus USB-UART Chips oder CDC setze, soweit es geht (was bisher immer der Fall war).
W.S. schrieb: > Die linuxartige Software zum Umgehen des OS wird von Windows freiwillig > nicht akzeptiert, weil sie eben kein konformer Gerätetreiber ist. Und > deswegen müßte man zur Brechstange (Zadig) greifen, um es dennoch > hinzubiegen. Das wiederum geht nur, wenn man alle ordentlichen Wege > beseitigt, also alles an Originaltreiber-Zeugs eliminiert. Zur Funktionalität von libusb, der "linuxartigen Software zum Umgehen des OS" (im Windows-Jargon auch Treiber genannt) gibt es unter Windows u.A. das Pendant WinUSB.sys, das - Überraschung! - von Microsoft kommt: Windows provides Winusb.sys that can be loaded as a function driver for a custom device... (und nix anderes als ein Custom-Device ist OpenHantek6022, denn es ist weder eine Maus oder ein Drucker, noch ein Audio-Interface oder ein Scanner (oder was sonst noch so genormt ist). Damit das funktioniert braucht es ein *.inf-File, das man von Hand erstellen kann gemäß der Anleitung vom Microsoft; dieses Vorgehen wird auch bei OpenHantek6022 beschrieben. Wer möchte kann nach dieser Anleitung vorgehen. Oder man lässt die Erstellung der *.inf-Datei und die Zuordnung der HW zu WinUSB von einem Programm ausführen - genannt Zadig (bzw. Zadic für die Konsole). Nix Brechstange, sondern Automatisierung einer Handarbeit.
Martin H. schrieb: > Zur Funktionalität von libusb,... Du hast eine eigenartige Ansicht über Teile von Windows. Warum also läuft dann dein Programm unter Windows mit WinUsb und dem Originaltreiber denn nicht? Soll ich dir das nette Bild (Dont brick your...) aus dem eevblog hier noch mal posten? Martin H. schrieb: > Ich sehe das nicht als Portfolio, sondern eher als Abfallprodukt, OK, eben ein Abfallprodukt. Damit dürfte die Sache dann final erledigt sein. W.S.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.