Welches Oszilloskop für Anfänger ?

Hallo,
da ich ja jetzt schon länger mit Elektronik bastele und kleine Roboterprojekte hinter mir habe, bei denen mir ein oszi schon viel geholfen hätte, möchte ich mir jetzt doch ein recht günstiges oszi anschaffen.
Doch habe ich in diesem Forum keine neueren Beiträge zu diesem Thema gefunden. Deshalb habe ich es mir mal erlaubt, einen neuen Beitrag zu eröffnen.

Also mein preislicher Rahmen liegt so bei max. 360€ (ca.).
Ich möchte das Oszi für z.B. PWM-Glättung, AVR-Signale usw. nutzen (auf keinen Fall HF und so ;) ), Anfängersachen eben. Wie viel Bandbreite werden denn da für das Oszi benötigt, damit ich sinnvoll Dinge ablesen kann ?

Bei meiner Suche bei Google bin ich oft auf das Rigol DS1052E gestoßen. Doch ist dies jetzt schon über 5 Jahre alt und es gäbe da schon von Rigol das Rigol DS1054Z für ca. hundert Euro mehr...
Taugen diese Geräte was, oder sollte man eine andere Marke wählen ?

Ich würde mich über eure Erfahrungsberichte sehr freuen.
Der Einsteiger

Hallo!

Zitat:

---

Zitat von Der Einsteiger

Wie viel Bandbreite werden denn da für das Oszi benötigt, damit ich sinnvoll Dinge ablesen kann ?

---

Die Bandbreite muss gleich 10-facher max. als Rechteck beobachteter Frequenz sein. ;)

Zitat:

---

Die Bandbreite muss gleich 10-facher max. als Rechteck beobachteter Frequenz sein.

---

Dann bin ich ja mit 50 Mhz gut bedient (PWM bei mir ca. 10khz...).

Und was sagst du zu dem Rigol ?
Oder lieber was anderes ?

Ich kenne Rigol gar nicht, habe profesionel mit Tektronix und privat mit Hameg gearbeitet._.

Zitat:

---

Ich kenne Rigol gar nicht, habe profesionel mit Tektronix und privat mit Hameg gearbeitet._.

---

Ja, so viel Geld habe ich nicht für ein Oszi über... ;D (1500€ +)
Hast du sonst noch Tipps, was ein Oszi an Eigenschaften haben sollte ?
Vielleicht kennen andere ja Rigol... ?

Je einfachere Bediennung um so schneller geht das Basteln. ;)

Zitat:

---

Je einfachere Bediennung um so schneller geht das Basteln.

---

Das stimmt auf jeden Fall :)

Weiß keiner was zum Rigol ??
Was habt ihr denn dann alles so für Oszis ? Außer Hameg und co... :D

Ich hab ein DSO-2090 mit afaik 100MHz Bandbreite (wers glaubt) ;) . Hat um die 300€ gekostet. Hat aber Schwächen:
http://fabiobaltieri.com/2013/07/10/...-oscilloscope/

- Anzeige nur am Pc
- Usb Masse = Signal Masse Ch1 = Signalmasse Ch2
- Max Spannung 35V

Für meine Bastelzwecke ideal.

Beruflich setze ich Fluke Scope Meter ein.
http://www.fluke.com/fluke/dede/prod...zilloskope.htm

Das Fluke ist dem DSO in jedem Belang weit überlegen!

Wie wärs damit? http://www.dreamsourcelab.com/

mfg

Hi,

klingt nach einem blöden Rat (ist es aber nicht ;-)): google das Thema mal vernünftig, das "Problem" taucht ja immer wieder auf, Du findest viele ähnliche Threads in diversen Foren. Du kannst ja insbesondere auch mal nach Meinungen zu den Rigol Scopes gucken. Ich habe mich vor einiger Zeit für ein Rigol aus der DS2000 Serie entschieden und es bis heute nicht bereut. Mein Eindruck ist nach wie vor (auch wenn ich die Diskussionen nicht mehr sonderlich aufmerksam verfolge), dass diese Scopes als Einsteigergeräte einen guten Ruf haben. Aber verlass Dich nicht auf den Rat von einer Person sondern gucke Dir verschiedene Meinungen an.

Gruß
Malte

- - - Aktualisiert - - -

Nachtrag:

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

Zitat:

---

Zitat von schorsch_76

Ich hab ein DSO-2090 mit afaik 100MHz Bandbreite (wers glaubt) ;) . Hat um die 300€ gekostet.

---

Braucht man auch nicht glauben. Hat eine Sampelrate von 100 MHz aber eine Bandbreite von 40 MHz und kost bei Amazon heute ca. 150€. Man findet da aber auch Geräte für unter 100€ möglicherweise mit geringerer Bandbreite. Wer Geräte ohne Bildschirm mag, kann sich dann für den Rest der 300€ noch einen kleinen gebrauchten Laptop/Netbook zulegen und hat dann ein gegebenenfalls mobiles, netzfreies Scope mit einem für ein Billigscope relativ großen Display. Aber nicht jeder mag so einen Mess-PC.

MfG Klebwax

Zitat:

---

Ich habe mich vor einiger Zeit für ein Rigol aus der DS2000 Serie entschieden und es bis heute nicht bereut. Mein Eindruck ist nach wie vor (auch wenn ich die Diskussionen nicht mehr sonderlich aufmerksam verfolge), dass diese Scopes als Einsteigergeräte einen guten Ruf haben. Aber verlass Dich nicht auf den Rat von einer Person sondern gucke Dir verschiedene Meinungen an.

---

Genau das habe ich ja auch getan. Dabei herausgekommen ist, dass Rigol einen recht guten Ruf für Einsteiger haben soll...

PC-Oszis kommen für mich nicht in Frage, da ich dann auf einen PC angewiesen bin und nicht mal eben schnell etwas nachschauen kann.

Durch Zufall kam gerade vor etwa 5 Tagen eine neue Folge mit genau dem Thema, was ich gesucht habe, bei dem EEVBlog heraus.
Falls es euch interessiert : https://www.youtube.com/watch?v=kb9P...11URZqWBigcVOQ

Also so wie ich es jetzt sehe, werde ich mir wohl dieses Oszi kaufen und dann hier darüber berichten... :)

Ich würde dir empfehlen noch vor dem Kauf (sonst könnte es zu spat sein) ein paar praktische Berichte durchlesen: https://www.google.de/?gws_rd=ssl#q=...vid=2031165415 .

Zitat:

---

Zitat von Der Einsteiger

PC-Oszis kommen für mich nicht in Frage, da ich dann auf einen PC angewiesen bin und nicht mal eben schnell etwas nachschauen kann.

---

Kann man verstehen, wobei ich eher IDE und Debugger gleichzeitig mit dem Scope benutze. Deshalb schrieb ich auch

Zitat:

---

kann sich dann für den Rest der 300€ noch einen kleinen gebrauchten Laptop/Netbook zulegen und hat dann ein gegebenenfalls mobiles, netzfreies Scope mit einem für ein Billigscope relativ großen Display.

---

Ich find einen 2. PC bzw. Laptop zum Entwickeln eigentlich recht praktisch. Kann Scope, Logic Analyzer, Terminal, Programmer oder was auch immer sein, je nach Bedarf. Und wenn es nicht der neueste sein muß, kann man soetwas manchmal sogar for free abstauben.

MfG Klebwax

Als Einsteigergerät finde ich ältere Tektronix oder Hameg Geräte (Analog) immer noch empfehlenswert. Die können eine Menge, die Bedienung ist imho durchdacht und man kann sich auf die Ergebnisse verlassen. Das halte ich für sehr wichtig. Erfahrenere Nutzer wissen mit Bugs von manchen China-Krachern umzugehen, Einsteiger tun sich damit oft schwer, was ganz natürlich ist.

Noch vor kurzem hätte ich bei neuen Digitaloszis zu einem Marken-Gerät geraten. Heute sehe ich das nicht mehr so. Dieses Review aht mir zu denken gegeben. Auf den Preis allein kommt es wohl nicht an.

https://www.youtube.com/watch?v=cRYxKcES-tI
https://www.youtube.com/watch?v=YpCfgtU0lm8
https://www.youtube.com/watch?v=s0jvcY9BVZ0
https://www.youtube.com/watch?v=z3cIxybY_v4
https://www.youtube.com/watch?v=-v1e1oDLIzk
https://www.youtube.com/watch?v=IZoqLLesr1s

Das Gute dabei ist, dass man sich als sparsamer Rigol-Besitzer bei so vielen Bugs gleich viel besser fühlt.

Mal davon abgesehen, dass der Thread schon "etwas" älter ist, bleibt das Thema aber immer aktuell.

Die verlinkten Berichte sind auf jeden Fall mal interessant.
Bugs gibt es aber vermutlich in jedem Oszilloskop, egal welcher Hersteller.
Zudem werden bei den meisten Herstellern Softwareupdates angeboten.

Dennoch bin noch höchst zufrieden mit meinem "bezahlbaren" Rigol Oszilloskop.
und ehrlich gesagt mein erster Eindruck, als ich mein Rigol in Betrieb nahm:
"Da hat ja mal jemand mitgedacht" Dagegen ist mein älteres Modell von xxxx eine bedientechnische Katastrophe.
So war und ist immer noch mein Eindruck. Die Bedienung ist wirklich Abwenderfreundlich.

Ich möchte mein Rigol nicht mehr missen.
Bezahlbar, einfach zu handhaben und erfüllt die Aufgaben wofür ich es gekauft habe.

Ich bin auch eher ein Analog Freak was die Bedienung angeht.
Lieber 10 Knöpfe und Regler mehr, als mich durch Menüs zu hangeln
und den Bildschirm zu zerkratzen....

Ich kann mit wirklich gutem Gewissen ein (mein) Rigol MSO1104 empfehlen.
wobei ich grade sehe, dass es dieses Modell schon garnicht mehr gibt.

Den Logikanalyser in meinem habe ich noch nie benutzt, ist also eine Option die man (ich)
nicht jeden Tag braucht. I2C oder RS232 kann ich auch gut mit den 2 Kanälen prüfen.

Erstaunlich ist, dass es nur 2 und dann 4 Kanal Oszilloskope gibt.
Ich benötigte eigentlich öfters mal 3 Kanäle. Daten Clock und Chip Select.
Warum gibt es keine 3 Kanal Oszillioskope :confused: ich habe eine Marktlücke entdeckt.
Meinen 4 ten Kanal (ich weis garnicht ob der überhaupt funktioniert) habe ich noch nie benutzt.:)

Ein PC Oszilloskop wäre für mich die "letzte" Wahl, bei den Problemen die
ich jeden Tag mit Windows habe, käme das nicht annähernd in Frage,
aber selbst die 20.000 und mehr Oszilloskope haben ja teils ein Windows im Hintergrund
Ausschnitt aus einer Bedienungsanleitung:

Code:

---

Da Ihr Oszilloskop unter einer PC-Plattform auf Windows-Basis läuft,
muß es gegen Virenbefall geschützt werden wie jeder PC in einem Netz.....

---

Hier kann ich mir ein "schmunzeln" nicht verkneifen...;) aber die liegen ja eh jenseits der Preismarke

Ich habe schon mit Hameg/Fluke/Phillips/Tektronix/LeCroy/Rigol gearbeitet
und ich glaube mit einem Rigol kann man als Einsteiger nix verkehrt machen.


Siro

Rigol MSO1104 kostet aber doch weit über 1000EUR, während im TOP doch von max. 360 EUR die Rede war... (ich selber würde z.B. nicht mehr als 120 EUR ausgeben wollen)
https://www.ebay.de/sch/i.html?_from...O1104&_sacat=0

was gibt es denn "GUTES" für UNTER 360 oder sogar UNTER 120 EUR?

(wer aber Windows Virenschutz hat wie Avira etc. und die Windows Sicherheitsupdates alle installiert inkl. Windows Defender, ist mE aber gut geschützt, und im schlimmsten Falle hängt viel mehr da dran für das private Windows-PC-Universum als nur ein angeschlossenes Oszilloskop)

PS,
statt ein digitales Oszi mit Windows-Software wäre aber doch z.B. auch eines für den Raspi sicher lohnend, per USB (und wenn der Raspi auch bereits schon einen fullHD HDMI-Bildschirm hat)?

Die MSO-Variante ist wesentlich teuer, hast Du völlig recht.

Das Rigol DS1054Z ist die Einsteiger Variante und ist die abgespeckte Variante meins MSO Modells
also ohne Logikanalyser und ohne Funktionsgenerator.
Die Bedienung scheint aber identisch zu sein und dieses Scope hat auch immer wieder sehr gute Bewertungen bekommen.
Momentan gibt es eine Sonderaktion mit allen Optionen inclusive:
https://www.batronix.com/versand/osz...l-DS1054Z.html

Einen Nachteil haben wohl alle Geräte bei Rigol,
dazu gehört auch das Multimeter DM3068 und ganz böse das Netzteil von Rigol
der "LÜFTER" :(

Das Multimeter und das Oszilloskop haben bei mir beide neue Lüfter bekommen.
Beim Einschalten hört man sie nun kaum noch, jedoch nach längerem Betrieb werden sie dann wieder lauter
da temperaturgeregelt. Aber dennoch Lohnenswert.


Auch in der Preisklasse ist folgendes Modell
Hantek DSO5102P Oscilloscope
Bewertungen laut Amazon sehen recht gut aus.
Hier sind auch Videos dazu
https://www.youtube.com/watch?v=luYJVTG7TJQ
https://www.youtube.com/watch?v=3rr2N4il33E

Ich selbst kann zu diesm Modell aber nichts sagen, habe nie eines in der Hand gehabt.

Hantek DSO5102P wäre wohl in der Preisklasse des OP, aber für mich ja war das Limit 120 EUR.

Wie kommst Du auf dieses (rein virtuelle?) Limit?

Zitat:

---

Zitat von Holomino

Wie kommst Du auf dieses (rein virtuelle?) Limit?

---

mein reelles nicht-virtuelle Portemonnaie ;)

Auch in dieser Presiliga gibt es Mini Oszilloskope
Ich hab mal ein DS-NANO ausprobiert.
Um mal festzustellen ob da was schwingt oder auch Servosignale sich anzuschauen ist das völlig okay.
Präzision darf man hier natürlich nicht erwarten und die Software war auch ein bissle Buggy.
Aber eigentlich ein Ossi zum "immer dabei haben" z.B. für den Modellbau.

Die gibt es jetzt sogar unter 100 Euro

Es gibt dafür auch Schaltplan und Open Source Software
Kannst Du Dir hier mal anschauen:
https://seeeddoc.github.io/DSO_Nano_v3/
https://elmicro.com/de/dso-nano-v3.html

Wenn man den Neuen nicht finanziert bekommt, möge man sich auf dem Gebrauchtmarkt umtun.
(alte Lipperlandweisheit)

Ein altes analoges Hameg mit 20MHz ist zwar vergleichsweise groß, tut allerdings seinen Dienst manchmal besser als ein DSO.

was ist von so etwas zu halten?
http://www.bitscope.com/product/BS05/
https://www.conrad.de/de/p/usb-oszil...t-1384493.html
oder doch lieber so etwas?
https://www.conrad.de/de/p/voltcraft...so-122465.html

Hmm,
ich brauche mein Hameg geschätzt etwa 3-4 mal im Jahr. Darum habe ich meinen Backstein mittlerweile im Schrank verstaut und muss ihn vor Gebrauch auf die Werkbank tragen, den Netzstecker einstecken und die Tastköpfe anschließen - HARD WORK.

Allerdings habe ich das Schätzchen vor etwa 25 Jahren gebraucht gekauft (für 200 DM, das Teil wurde damals vor der ersten Kalibrierung von der Bahn ausgemustert) - kein Treiberärger, keine Updates, stabile Funktion. Du drückst den Netzschalter und komme, was da wolle, es fängt an zu brummen und nach 15s siehst Du den Kathodenstrahl über die Röhre flitzen.

Vor ein paar Jahren habe ich mir noch für 15 Euro ein nettes Spielzeug gebaut: Ein 4-Kanal-Mini-Oszi mit 1MHz Samplerate, Akkuanschluss und Bluetooth-Modul, dazu noch ne C#-Applikation für Notebook/Tablet zur Anzeige. Mein Bruder hat sich dafür begeistert, die Anzeige/Bedienung als Java-App für nen Android-Phone zusammenzubasteln (haben wir nie gebraucht, aber interessant war es schon).

Was die Häufigkeit der Benutzung angeht: Ich habe selten Signale über 100kHz zu messen. Insofern wären beide Geräte gleich gut geeignet. Störungen auf ner Versorgungsleitung z.B. diagnostiziere und beseitige ich lieber mit dem Hameg. weil man kurze Nadelimpulse zuverlässiger erkennt. Andere Dinge, wie z.B. die Optimierung von nem Optokoppler oder der Phasenlage von nem Inkrementalgeber mache ich lieber mit dem Mini-Oszi. Das hat schlicht den Vorteil von CTRL+C, um nen Oszibild für die interne Doku zu erstellen (die einzige Funktion, die ich bei meinem Hameg wirklich schmerzlich vermisse!). Aber glaub mal nicht, dass ich das Mini-Oszi häufiger verwende als das Hameg. Schon alleine, dass in den letzten drei Jahren Windoof-Updates meine gesamte BT-Konfiguration zweimal komplett in den Orkus geblasen wurde, macht mich unwillig (jedes mal wieder neu koppeln und an ganz anderer Stelle im BS die COM wiederfinden. Das dauert dann auch schon mal zehn Minuten).

Gebäudetechnisch verglichen: Die Pyramiden von Hameg sind 4000 Jahre alt, sind nicht mehr die Höchsten. Nen Wolkenkratzer kannste höher bauen aber die Pyramiden stehen in 4000 Jahren immer noch und sind auch (fast) immer noch gleich hoch.

Es gibt aber auch noch andere Vorteile: Bei gehaltenem Tastkopf aus den Augenwinkeln den riesigen Drehschalter für die Zeitbasis zu finden und per haptischer Rückmeldung (das wertige Force-Feedback und das satte "Klack" eines mechanischen Schaltens) eine Stufe nach links oder rechts zu drehen, möchte ich in manchen Messsituationen nicht missen. Diesbezüglich, finde ich, sind diese Mäusekinos auf Displays (schlimmer sind noch "MENÜS", durch die man sich per Knöpfen durchhangeln muss. Aber der Gipfel sind die Auto-Tasten, die in komplizierten Triggersituationen regelmäßig versagen, auf die man sich aber schon so lange verlässt, dass man sich an die eigentliche Bedienung eines Oszilloskopes nicht mehr erinnert) ein echter Rückschritt.

Bezüglich Deiner Links:
Das Bitscope passt nicht in Dein reales Budget, Tastköpfe brauchst Du dazu ja auch noch und ein Gehäuse würde ich schon noch dazu empfehlen. Open Source klingt immer in diesem Bereich total nett, ist aber wie mit Linux auf'm Fernseh-Receiver: wenn man nicht der Nerd ist, wird das Konzept schnell ärgerlich für den Otto-Normalanwender.

Und lass die Finger von Voltcraft - sorry, meine Erfahrung, mag nicht der Standard sein, aber beide Geräte von dieser Firma waren in meinem Gebrauch nach recht kurzer Zeit verschlissen.

stimmt ja, an Tastköpfe hatte ich gar nicht gedacht - danke für die Tipps!

Zitat:

---

Zitat von Holomino

Hmm,
ich brauche mein Hameg geschätzt etwa 3-4 mal im Jahr.

---

Für mich ist es das wichtigste Messgerät. Wenn ich irgendetwas an der Hardware mache, ist es im Betrieb. Die Genauigkeit ist sicher nicht so toll, trotzdem benutze ich es sebst zur Spannungsmessung. Früher durch Abzählen der Kästchen, heute wird sie angezeigt. Dazu kommen noch ein Durchgangspiepser und ein Labornetzteil. Für Protokolle, Timings etc. benutze ich einen 10$ LA mit einem übrig gebliebenen (also kostenlosen) Netbook. Wenn ich z.B. eine Baudrate bei der seriellen einstelle, verlasse ich mich nicht auf meine Rechnung sondern lasse die Autobaudfunktion des LA das bestätigen.

So unterschiedlich sind die Arbeitsweisen.

MfG Klebwax

Zitat:

---

.. Hameg .. Backstein .. Andere Dinge, wie z.B. .. Drehschalter .. haptischer Rückmeldung (das wertige Force-Feedback und das satte "Klack" eines mechanischen Schaltens) ..

---

Ganz meine Meinung, sie klingt vielleicht wie Sehnsucht nach "der guten alten Zeit" - aber Haptik und Akustik moderner Geräte sind oft ein brutaler Rückschritt. Ich hatte trotzdem das ABB GOERTZ/ABB Metrawatt, 60 MHz, Typ M6003 (laut Platinenaufdruck ein HAMEG HM 604 Z 03U *gg*) weggegeben das ich während einer Verschrottungsaktion meines Arbeitgebers gerettet hatte - fast neu, dafür kostenlos - und stattdessen ein USB-Teilchen angeschafft (dies, kplt). Und ich bin total begeistert davon. Nur als kleines Beispiel (in diesem Bild) - einfach mit dem Mauszeiger in die Nähe einer möglichen Periode kommen und ohne langem Positionieren auf irgendwelche Signalspuren zeigt das Ding automatisch ne Menge ziemlich sinnvoller Daten; da sind Perioden s..schnell auf ihre Gleichmässigkeit zu kontrollieren (obs Sinn macht oder nicht). So gibt es ne Menge Funktionen die einfach da sind, wenn man sie sich wünscht - sehr durchdachtes Design, nicht überladen und zu einem noch mäßigen Preis.

Zitat:

---

.. Wenn ich z.B. eine Baudrate bei der seriellen einstelle, verlasse ich mich nicht auf meine Rechnung sondern lasse die Autobaudfunktion des LA das bestätigen ..

---

Ja! Diesen Luxus habe ich auch erst bei dem neuen Spielzeug kennen und schätzen gelernt genauso wie alphanumerische Anzeigen bei I²C-Messungen usw usf

Eigentlich gehe ich immer davon aus, dass meine Schaltungen funktionieren (hust).
Im Fehlerfall oder bei Optimierungsbedarf ist das Oszi manchmal unerlässlich, ist aber bei mir meist erst der nächste Schritt nach Leiterbahnen durchpingen und Software kontrollieren.

Anhang 34209
Allerdings muss ich auch sagen, ich bin kein Vollbluthardwareentwickler. Für so was, wie im Bild z.B. (unidirektionale UART von einer drehenden Plattform auf nen festen Träger über zwei Luftspulen, auf 8MHz moduliert) braucht man meiner Meinung nach hauptsächlich nen Simulator zum Entwurf des Ausgangsfilters.

Das Oszilloskop braucht man vielleicht, um die Kopplung der Spulen anzuschauen. Aber da reicht dann auch ein Blick, um zu sehen, dass 3V Peak bei 1cm Abstand an der Empfängerspule mehr als genug sind (mehr, als jemals in der Simulation eingespeist wurde). Vielleicht hält man noch den Tastkopf an den Signalausgang hinter dem Filter, um zu sehen, ob das auch gut aussieht, aber das erforderliche Timing kann man damit schon kaum noch erkennen (könnte man vielleicht mit so ner neomodernen OSD-Periodenanzeige, aber dann müsste man ja rechnen. Am Analogoszi ziehe ich mir die Bits über die variable Zeitbasis und den x-Pos so zurecht, dass ich sehe, ob 0 und 1 etwa gleich lang sind, aber hilft ja nix, durch ne bessere Messmethode wird der Filter auch nicht besser).

Der Rest ist dann für mich Software. Ist mir einfach zu blöd, mit nem anderen Gerät zu testen, wie weit man die Baudrate hochjubeln kann. Das sieht man besser, wenn man quasi am Anwendungsfall die Baudrate beider Controller hochdreht, bis der Empfängercontroller (mangels ausreichender Steilflankigkeit und Bitlatenz im durchaus nicht perfekten Filter) keine korrekten Daten mehr empfängt. Bis 38kBaud geht's wohl, auf 19200 hab ich's dann in der Praxis eingestellt - hat für die Anwendung gereicht und funktioniert nach mehrfachem Nachbau auch immer wieder.

Aber wie gesagt, es gibt auch Fälle, in denen ich das Oskar als absolut notwendig erachte: Nen Steckkontakt, der als Übergangswiderstand im Lastfall mal die Masse um 30mV von einer Platine (mit Akkus) zur Nächsten (just da sitzt dann auch der AD-Wandler mit Spannungsteilern, mit dem Du die Akkuspannungen messen willst) verschiebt, findest Du nicht so leicht ohne Oskar. Und wenn Du ihn nicht findest, wirst Du die Schaltung mit Kondensatoren totsieben (es ist immer nur die unterste Zelle, die wild in der Anzeige flackert, alle anderen Zellspannungen werden differenziell gemessen), ohne irgendeinen Erfolg, statt einfach die Masse des Lastteiles von der Masse des Messteiles über einen eigenen Steckkontakt zu trennen.

Aber das sind dann Designfehler. Vielleicht kann man dazu sagen: "Wer viel macht, macht auch viel Mist".
Und so viel mache ich auf dem Hardwaresektor nicht.
(Bei mir ist die Hardware eher Mittel zum Zweck. Das Messen ebenfalls, aber dann auch nur in zweiter Ebene, quasi ein Anhängsel 2. Ordnung.)

Zitat:

---

Zitat von Holomino

Eigentlich gehe ich immer davon aus, dass meine Schaltungen funktionieren (hust).
Im Fehlerfall oder bei Optimierungsbedarf ist das Oszi manchmal unerlässlich, ist aber bei mir meist erst der nächste Schritt nach Leiterbahnen durchpingen und Software kontrollieren.

---

Leiterbahnen durchpiepen mache ich selten, Kurzschlüsse und Unterbrechungen finde ich mit dem Scope. Und Fehler in der Software find ich ebenfalls mit Scope und Debugger. Embeded Systeme haben typisch Ausgänge die man auf dem Scope ansehen kann.

Zitat:

---

Der Rest ist dann für mich Software. Ist mir einfach zu blöd, mit nem anderen Gerät zu testen, wie weit man die Baudrate hochjubeln kann. Das sieht man besser, wenn man quasi am Anwendungsfall die Baudrate beider Controller hochdreht, bis der Empfängercontroller (mangels ausreichender Steilflankigkeit und Bitlatenz im durchaus nicht perfekten Filter) keine korrekten Daten mehr empfängt. Bis 38kBaud geht's wohl, auf 19200 hab ich's dann in der Praxis eingestellt - hat für die Anwendung gereicht und funktioniert nach mehrfachem Nachbau auch immer wieder.

---

"hochjubeln" war nicht mein Thema. Gefühlt die Hälfte aller UART Probleme in den Foren hat mit falsch eingestellter Baudrate zu tun. Und anstatt zu fragen "Ist in der neuesten Version von XYZ immer noch 19200 angesagt" oder "kann mir mal einer sagen, was ich in die Register für 9600 schreiben muß" habe ich das schneller ausgemessen. Aber richtig, das meiste ist Software. Ich benutze kleine 8-Pinner und Software gerne, wo andere einen 555 oä einsetzen. Aber was da raus kommt, verlängerter Puls, Servosignal oder PWM wird von mir mit dem Scope oder LA überprüft. Auch beim Debuggen benutzem ich Scope bzw. LA. An strategischen Stellen einen Output setzen oder löschen, den ich für solche Sachen versuche freizuhalten, hilft einem Softwarebugs zu finden. Ich schreibe gerade Timer und PWM Routinen so um, daß sie auch mit unterschiedlicher Prozessorclock gleich takten. Wie gut es funktioniert, messe ich mit dem LA nach.

Mein analoges Scope vermisse ich nicht, digitale können einfach mehr und sind kleiner und leichter. Ich hatte mal eins, das konnte beides. Irgendwann habe ich gemerkt habe, daß ich den Analogmodus nicht mehr benutze. Seitdem schreibe ich auch keine extra Testsoftware mehr, um ein Signal wiederholt zu erzeugen und analog anzuzeigen. Und statt dem analogen NF-Spektrumanalyzer, der die Tischplatte durchgebogen hat, reicht mir für die seltenen Fälle die FFT im Digitalscope.

Aber, wie ich schon schrieb, so unterschiedlich sind die Arbeitsweisen. Ohne Scope hätte ich das Gefühl, blind zu arbeiten.

MfG Klebwax

Vielleicht hat es bei mir schlicht mit den Augen zu tun, dass ich mich ohne Lupe gar nicht mehr traue, bei dem heutigen SMD-Gedöns nen Tastkopf auf ne Leiterbahn zu setzen. Darum baue ich einiges an Software um optische Kontrollen (LEDs) und Diagnosetelegramme herum.
Man braucht ja nicht für jede Funktion eine eigene LED, das kann man dann auch mal softwareseitig umstellen.

Zitat:

---

.. baue ich einiges an Software um optische Kontrollen (LEDs) und Diagnosetelegramme herum. Man braucht ja nicht für jede Funktion eine eigene LED ..

---

Ganz meine Praxis. Auf den Servoplatinen für meinen archie hatte ich u.a. zwei LEDs, HeartB und Tst, an einer markanten Stelle. Die grüne Heartbeat ist ein Blinkie mit 0,5 Hz (1 sec an, 1 sec aus) und ein gutes Instrument um Ausfälle oder Störungen zu erkennen (ne Heartbeat existiert auf fast allen meinen Platinen - Ausnahmen die minimal bestückten..). Daneben die rote Tst ist für Tests, Debugging und so. Nur eine, dafür ganz isoliert an einem einzigen Pin der wirklich nur für allfällige Diagnosen benutzt wird - auch nicht für ne Taste oder sonstiges Zeug.

Zitat:

---

Zitat von oberallgeier

Ganz meine Praxis. Auf den Servoplatinen für meinen archie hatte ich u.a. zwei LEDs, HeartB und Tst, an einer markanten Stelle. Die grüne Heartbeat ist ein Blinkie mit 0,5 Hz (1 sec an, 1 sec aus) und ein gutes Instrument um Ausfälle oder Störungen zu erkennen (ne Heartbeat existiert auf fast allen meinen Platinen - Ausnahmen die minimal bestückten..). Daneben die rote Tst ist für Tests, Debugging und so. Nur eine, dafür ganz isoliert an einem einzigen Pin der wirklich nur für allfällige Diagnosen benutzt wird - auch nicht für ne Taste oder sonstiges Zeug.

---

so mache ich es auch, zusätzlich auch Display-Anzeigen, wo relevante Werte zu Kontrollzwecken angezeigt werden (und manchmal auch zusätzlich noch Soundsignale), aber das sind ja eher Methoden für Monitoring und Debuggen und hat nichts mit dem Thema "Oszi für Anfänger" zu tun.

Zitat:

---

Zitat von HaWe

hat nichts mit dem Thema "Oszi für Anfänger" zu tun.

---

Doch, schon. Es stellt nämlich die Frage, lohnt sich ein Scope überhaupt, wenn ich nicht gerade analoge HW entwickle. Sollte man das verfügbare Geld nicht eher für etwas anderes ausgeben? Trotz aller genannten Debughilfen mit LEDs und serieller (die einem das Timing typisch komplett kaput macht), ist es dir z.B bisher nicht gelungen, die Ursache für die merkwürdigen Zeichen auf der seriellen zu finden (aus einem anderen Thread)

Zitat:

---

Zitat von HaWe

Restart, neuer output:

Code:

---

initializing...
starting UART loop...
§message from Arduino: 0gno: 618;
§message fr��message from Arduino: 615;
§message from Arduino: 616;
§message from Arduino: 617;
§message from Arduino: 618;
§message fr

---

dann bleibt es wieder stehen...

---

Mit einem 10$ LA wäre ich der Sache längst auf der Spur.

Einen belastbaren Ratschlag, welches man kaufen sollte, kann man eigentlich nicht geben. Braucht man besser mehr Kanäle, eine höhere Bandbreite, eine höhere Abtastrate oder eine größere Speichertiefe? Bei einem limitierten Budget muß man eines gegen das andere aufwiegen. Nur der Benutzer selber weiß, wozu er es einsetzt und vor allem einsetzen wird. Um die Arbeit, die Manuals zu lesen und die Features zu vergleichen, wird man nicht herumkommen. Da könnte auch rauskommen, daß man abwartet und anspart oder nach einem gebrauchten sucht.

Abraten würde ich von den DSO nano. Und das einfach aus praktischen Gründen. Display und vor allem Tasten sind sehr klein. Man braucht schon gute Augen und eine ruhige Hand um es vernünftig benutzen zu können. Anderenfalls liegt es auch meist im Schrank. Auch nur einen Kanal halte ich für zu wenig, ein externer Triggereingang wäre da nötig.

MfG Klebwax

Zitat:

---

Zitat von Klebwax

...und serieller (die einem das Timing typisch komplett kaput macht), ...

---

Wo macht einem die UART das Timing kaputt?

Zitat:

---

Zitat von Klebwax

Doch, schon. Es stellt nämlich die Frage, lohnt sich ein Scope überhaupt, wenn ich nicht gerade analoge HW entwickle. Sollte man das verfügbare Geld nicht eher für etwas anderes ausgeben? Trotz aller genannten Debughilfen mit LEDs und serieller (die einem das Timing typisch komplett kaput macht), ist es dir z.B bisher nicht gelungen, die Ursache für die merkwürdigen Zeichen auf der seriellen zu finden (aus einem anderen Thread)

---

ich bin da übrigens auch ein ganzens Stück weiter inzwischen, und es liegt mit großer Wahrscheinlichkeit am Raspi, nicht am Arduino
Ich aber glaube kaum, dass ich das Poblem mit einem Oszi eingrenzen könnte, denn dass es früher oder später mal hängt, ist klar, nur ob der Raspi nicht senden oder der Arduino nicht empfangen kann oder umgekehrt, kriege ich auch sicher mit einem Oszi nicht raus - allerdings bisher auch nicht mit anderen Mitteln https://www.roboternetz.de/community...l=1#post652616 ) .

Zitat:

---

Zitat von Holomino

Wo macht einem die UART das Timing kaputt?

---

Weil die serielle Ausgabe eigentlich immer zu lange dauert. Sie blockiert damit entweder die CPU oder erzeugt zusätzliche Interrupts. Beides bringt einem das Timing gründlich durcheinander. Aber das ist das kleine Einmaleins vom Entwickeln im hardwarenahen Bereich. Debug-Code darf das Timing nicht beinflussen, sonst verdeckt er Fehler oder erzeugt neue.

Ausnahmen bestätigen natürlich die Regel. Und mit einem Scope kann man dann nachweisen, daß die erzeugten Signale trotz serieller Debugausgabe immer noch ok sind.

Zitat:

---

Zitat von HaWe

Ich aber glaube kaum, dass ich das Poblem mit einem Oszi eingrenzen könnte, denn dass es früher oder später mal hängt, ist klar, nur ob der Raspi nicht senden oder der Arduino nicht empfangen kann oder umgekehrt, kriege ich auch sicher mit einem Oszi nicht raus

---

Weswegen ich bei Schnittstellen, wie geschrieben, lieber den LA nehme. Aber was als letztes wirklich auf der seriellen passiert, bevor es hängt, kann man mit außreichend Pretrigger auch auf einem (digitalen) Scope sehen. Und wenn man bei einem UART-Error ein Port-Bit setzt und damit triggert, bekommt man auch eine Ahnung, wie und warum die Daten kaput gehen. Aus beiden Informationen kann man vermutlich schließen, was wirklich schief geht und die Ursache finden und beseitigen.

Zitat:

---

ich bin da übrigens auch ein ganzens Stück weiter inzwischen, und es liegt mit großer Wahrscheinlichkeit am Raspi, nicht am Arduino

---

Das klingt erstmal plausibel. Zwischen deinem Programm und der seriellen hängt beim Raspi die Laufzeitlibrarie und der Linux Kernel, und beide drehen so ihr eigenes Ding. Gerade da wäre es wichtig, wie die Zeitbeziehung zwischen deinem Programm (GPIO-Bit direkt setzen) und der wirklichen seriellen ist.

MfG Klebwax

Zitat:

---

Zitat von Klebwax

Weil die serielle Ausgabe eigentlich immer zu lange dauert. Sie blockiert damit entweder die CPU oder erzeugt zusätzliche Interrupts. Beides bringt einem das Timing gründlich durcheinander. Aber das ist das kleine Einmaleins vom Entwickeln im hardwarenahen Bereich. Debug-Code darf das Timing nicht beinflussen, sonst verdeckt er Fehler oder erzeugt neue.

Ausnahmen bestätigen natürlich die Regel. Und mit einem Scope kann man dann nachweisen, daß die erzeugten Signale trotz serieller Debugausgabe immer noch ok sind.

Weswegen ich bei Schnittstellen, wie geschrieben, lieber den LA nehme. Aber was als letztes wirklich auf der seriellen passiert, bevor es hängt, kann man mit außreichend Pretrigger auch auf einem (digitalen) Scope sehen. Und wenn man bei einem UART-Error ein Port-Bit setzt und damit triggert, bekommt man auch eine Ahnung, wie und warum die Daten kaput gehen. Aus beiden Informationen kann man vermutlich schließen, was wirklich schief geht und die Ursache finden und beseitigen.

Das klingt erstmal plausibel. Zwischen deinem Programm und der seriellen hängt beim Raspi die Laufzeitlibrarie und der Linux Kernel, und beide drehen so ihr eigenes Ding. Gerade da wäre es wichtig, wie die Zeitbeziehung zwischen deinem Programm (GPIO-Bit direkt setzen) und der wirklichen seriellen ist.

MfG Klebwax

---

Sorry, verstehe kein Wort.
der Mega sendet und empfängt per UART/USB, und der Raspi empfängt und sendet per UART/USB, und so soll es auch bleiben. Inwiefern mir da ein Oszi helfen könnte, verstehe ich nicht - aber du kannst es ja mal austesten!

PS
update, offtopic, nur zur Ergänzung:
ich vermute, ich habe das UART Problem gelöst!
Ich habe die UART-Kommunikation in einen extra pthread mit prio 60 ausgelagert, jetzt läuft es seit knapp 1 1/2 Stunden stabil ohne Unterbrechungen! 8)

Zitat:

---

Zitat von Klebwax

Weil die serielle Ausgabe eigentlich immer zu lange dauert. Sie blockiert damit entweder die CPU oder erzeugt zusätzliche Interrupts. Beides bringt einem das Timing gründlich durcheinander. Aber das ist das kleine Einmaleins vom Entwickeln im hardwarenahen Bereich. Debug-Code darf das Timing nicht beinflussen, sonst verdeckt er Fehler oder erzeugt neue.

---

Hmm, kann ich nicht nachvollziehen.
Der Ablauf der UART-ISRs liegt bei mir auf'm 8MHz AVR im einstelligen µs-Bereich, das Kopieren einer Telegrammstruktur in den Sende-Fifo dauert vielleicht mal 20µs. Das Lesen des Empfangs-Fifo mache ich zyklisch aus nem Timer oder aus der main() als ASAP (as soon as possible). Bei einer 115kBaud-UART kommt man so nicht höher als 20..30% Auslastung für eine UART unter Volllast (Teufel, was soll das für eine Mörderapplikation sein, die aus nem Controller wirklich kontinuierlich 10kB/s sinnige Daten erzeugt?!).

Ich wüsste nicht, was das kaputt machen sollte. Wenn es vom Timing her so kritisch ist, muss man für die anderen Funktionen halt mal die Peripheriemodule (InputCapture/PWM/ADC/...) konsequent nutzen.

Zitat:

---

Zitat von Holomino

Hmm, kann ich nicht nachvollziehen.
Der Ablauf der UART-ISRs liegt bei mir auf'm 8MHz AVR im einstelligen µs-Bereich, das Kopieren einer Telegrammstruktur in den Sende-Fifo dauert vielleicht mal 20µs. Das Lesen des Empfangs-Fifo mache ich zyklisch aus nem Timer oder aus der main() als ASAP (as soon as possible). Bei einer 115kBaud-UART kommt man so nicht höher als 20..30% Auslastung für eine UART unter Volllast (Teufel, was soll das für eine Mörderapplikation sein, die aus nem Controller wirklich kontinuierlich 10kB/s sinnige Daten erzeugt?!).

Ich wüsste nicht, was das kaputt machen sollte. Wenn es vom Timing her so kritisch ist, muss man für die anderen Funktionen halt mal die Peripheriemodule (InputCapture/PWM/ADC/...) konsequent nutzen.

---

Na dann hast du ja alles im Griff und brauchst weder Scope noch LA.

MfG Klebwax