Solange ich nicht genug Kohle zusammen habe, bis ich mir wieder ein ordentliches Oszi leisten kann, muss ich improvisieren und kleine Brötchen backen.
In diesem Sinne habe ich gestern damit angefangen, mir einen minimalistischen Oszi-Ersatz mit Arduino zu basteln. Der aktuelle Stand ist hier zu sehen. Das Display zeigt die Kurve einer Schwingung mit 100 Hz, wie lange das Aufzeichnen der Kurve gedauert hat (oben links, µs) und bei welchem analogRead()-Wert getriggert wird (oben rechts, „T:xxx“). Mit dem Schalter links kann ich die Trigger-Funktion ein- und ausschalten. Die Knöpfe rechts neben dem Display dienen dazu den Triggerwert zu erhöhen oder zu verringern.
Ganz rechts ist zwar ein kleines Taschen-Oszi zu sehen, aber dessen Buchsen für die Tastköpfe haben einen Wackelkontakt (typisch billiger China-Scheiß, den ich nur noch als Signalgenerator benutze).
Als nächstes wird noch eine BNC-Kupplung gekauft, damit ich statt Messschnüren auch einen richtigen Tastkopf anschließen kann. Und natürlich kommen noch weitere Knöpfe hinzu, damit ich irgendwann auch einen „Cursor“ im Display bewegen kann.
Ich habe im Netz zwar noch ein paar andere Beispiele für derartige Basteleien gefunden, aber weil die mit anderen Displays arbeiten (u. A. auch mit Processing), habe ich mein Gebastel bislang „frei Schnauze“ aufgebaut.
Falls jemand mit Links zu ähnlichen Projekten dienen kann: Immer her damit! Alle Seiten werden zumindest quergelesen. Kommentare und Ideen/Vorschläge sind ebenfalls hochwillkommen!
Schönes Rest-WE!
Gregor
PS: Spaßhalber mal gerechnet: Es werden 121 Pixel der Kurve gezeichnet. Wenn das 19360 µs dauert, sind das 160 µs je Pixel.
Warum postest du dein Bild nicht wie üblich hier im Forum ?
Dann kann man dies wenigstens vernünftig größer ziehen und dich evtl. auf schlechte Lötstellen aufmerksam machen.
HotSystems:
Warum postest du dein Bild nicht wie üblich hier im Forum ?
Dann kann man dies wenigstens vernünftig größer ziehen und dich evtl. auf schlechte Lötstellen aufmerksam machen.
Auf jeden Fall ist es geil, weil man so zwar ein sehr einfaches aber innerhalb gewisser Grenzen geniales Werkzeug hat, das einem bei weiteren Basteleien hilft. Nuja ... wir machen uns Werkzeuge, um uns noch bessere Werkzeuge machen zu können
Hast Du Ideen, was man da noch machen könnte? Der Nano hat noch haufenweise freie Pins.
Also ich habe einen Trio 30MHz 2 Strahl “CS 1570” den ich nicht mehr brauche. Und einen Speichervorsatz von Conrad Elektronik auch nicht mehr der jüngste. Aber beides funktioniert und ist gerne gratis abzugeben.
Abzugeben gegen Abholung. Wenn dann das Geld wieder für einen Speicherosi reicht, dann weg mit dem Teil.
Ich habe mir einen Hantek DSO5072P geholt, da brauche ich den alten Osi natürlich nicht mehr.
kulturbereicherer:
Sind diese OLED Dinger nicht mit HW-SPI Flotter als über I2C?
Falls Du mich fragst: Keine Ahnung.
Ich habe diese I²C-OLED-Displays vor rund anderthalb Jahren kennen gelernt, mir meine eigene Bibliothek dazu geschrieben und fand diese Dinger bislang ausreichend Flott. Den I²C-Code für die Initialisierung habe ich AFAIR vollständig von anderswo genommen, aber Funktionen wie setPixel() oder circle() habe entweder selbst programmiert oder mit Hilfe kompetenter Literatur ausbaldowert. Die letzte größere Erweiterung meiner Bibliothek war das Hinzufügen eines Zeichensatzes mit 7x9 Pixeln.
Das Display war für mich bislang ausreichend schnell. Allerdings wird der I²C-Takt mit meiner Bibliothek auf 400 kHz erhöht. Das ist genug für 25 Bilder/s.
gregorss:
Das Display war für mich bislang ausreichend schnell. Allerdings wird der I²C-Takt mit meiner Bibliothek auf 400 kHz erhöht. Das ist genug für 25 Bilder/s.
Wofür muss das Display schnell sein?
Die Datenerfassung muss es sein, die Darstellung hat Zeit.
RIN67630:
Wofür muss das Display schnell sein?
Die Datenerfassung muss es sein, die Darstellung hat Zeit.
Klar, für das, was ich jetzt vorhabe, muss das Display nicht schnell sein. Ich habe nur „damals“ den Code für die Initialisierung irgendwo kopiert und dort wird eben das mit den 400 kHz gemacht. Warum ändern, wenn's funktioniert?
gregorss:
Klar, für das, was ich jetzt vorhabe, muss das Display nicht schnell sein. Ich habe nur „damals“ den Code für die Initialisierung irgendwo kopiert und dort wird eben das mit den 400 kHz gemacht. Warum ändern, wenn's funktioniert?
Möglicherweise, um mehr Resourcen für die Datenerfassung freizuhalten.
RIN67630:
Klaro werden bei einem schnellerem Takt mehr Prozessorzeit abgezwackt. Das wird nicht hardwaremäßig gemacht.
Die wire-Lib des Arduinos nutzt die Hardware der AtMegas für das I2C Interface. Das eigentliche Senden/Empfangen passiert zwar im Interrupt, die Aufrufe warten aber immer bis der ganze Vorgang abgeschlossen ist. D.h. ein schnellerer Takt beschleunigt die Übertragung und die Aufrufe für die Datenübertragung kehren schneller zurück.
PS: Da das inzwischen zu einem „richtigen“ Projekt geworden ist, habe ich mal mit einem Schaltplan angefangen (s. Anhang). Wenn jemandem etwas Sinnvolles zu den noch nicht benutzten Pins einfällt … immer her damit!
PS: Da das inzwischen zu einem „richtigen“ Projekt geworden ist, habe ich mal mit einem Schaltplan angefangen (s. Anhang). Wenn jemandem etwas Sinnvolles zu den noch nicht benutzten Pins einfällt ... immer her damit!
Naja das mit dem schnellerer Takt und weniger ressourcen überzeugt mich nicht.
Primär ging es jedoch um die Aktualisierung des Displays mit 25Hz. Schwamm drüber.
Ich würde dir aber empfehlen, die Pins D13 bis D9 für ein SPI interface frei zu lassen.
Schalte lieber deine Kontakte über Widerstände auf Analog(x).
So hast du das SPI interface für was anderes (ggf ein Wireless Transmitter) frei.
Wer weiss, vielleicht magst Du den Signal zum PC schicken und dann würde ich NIEMALS ohne galvanische Trennung arbeiten.
