Jeder (Elektronik-)Bastler kennt sicherlich das Problem: Man tüftelt an einer neuen Schaltung oder probiert auf dem Bread-Board nur einmal schnell etwas aus und schon hat man eine Handvoll Widerstände, Kondensator oder sonstige Bauteile auf dem Tisch liegen. Nun kommt man an den Punkt, an dem das aktuelle Bauteil gegen ein anderes getauscht werden muss und ehe man sich versieht herrscht Chaos, als hätte man 3 Wochen nicht aufgeräumt. Als wäre das nicht schon genug, kommen dann noch die „Neuerrungenschaften“, am Besten als SMD-Variante und andere Bauteile laufender Projekte hinzu, für welche man sich sowieso erst noch einen „Lagerort“ überlegen muss, um sie auch in 2 Wochen noch wiederfinden zu können.
Da ich an diesem beschriebenen Bastelplatz seit neuestem auch meine tägliche Arbeit verrichte, möchte ich natürlich nicht die ganze Zeit irgendwelche Kleinteile rumliegen haben, weshalb nun endlich eine Lösung für dieses Ordnungsproblem her musste. Da sich zu den elektronischen Bauteilen auch noch der ein oder andere USB-Stick, USB-Kartenleser oder auch USB-UART-Konverter gesellte, sollten auch diese gleich einen festen Platz in dieser Lösung erhalten.
Die grobe Zielsetzung war also eine Aufbewahrungsmöglichkeit für USB-Sticks und allmögliches Kleinteilzeugs zu schaffen, um einerseits die Ordnung und Ansehnlichkeit des Arbeits- und Bastelplatzes zu verbessern und andererseits die Teile trotzdem immer griffbereit zu haben.
Die letzten Tage habe ich meine HTML-basierte Software des „SLSS CarNet Command Centers“ (Hauptartikel: SLSS CarNet*) weiter um- und ausgebaut. Nach der Installation der Hardware im Sommer 2020 konnte ich auf meinen Testfahrten (welche coronabedingt leider nicht so häufig waren wie gehofft) einiges an Erfahrungen und Eindrücken sammeln. Die ersten Erkenntnisse daraus habe ich nun in Form von Updates und Verbesserungen in die Software einfließen lassen. Das es an der einen oder anderen Stelle Verbesserungspotential geben wird, war mir bereits bei der Entwicklung der Soft- und Hardware klar. Ich war ziemlich erstaunt, dass sowohl die GPS-Ortung inkl. Richtungs- und Geschwindigkeitserkennung, als auch andere Komponenten, welche ich vorher nicht während der Fahrt (also „in Bewegung“) testen konnte, auf Anhieb funktionierten. Somit beschränken sich die Verbesserungen auch eher auf Optimierungen in Sachen Performance, Usability und Reaktionsgeschwindigkeit.
Verbesserung der CAN-Bus Reaktionsgeschwindigkeit dank Python
Eine Sache, welche mich schon beim Erstellen der Software beschäftigte, war die Erkennung der über den CAN-Bus gesendeten Botschaften. Ursprünglich nutze ich hierfür ein PHP-Script, welches per „shell_exec()„-Befehl das Lesen der CAN-Daten übernahm. Das Problem hierbei war zum einen, dass dieses Script nicht in einer Endlosschleife laufen konnte, da die so gesammelten Daten nach Zeit-X gespeichert werden mussten und dafür der Lesevorgang beendet werden musste. Zum anderen lief dieses Script innerhalb des „Command Centers“ was dazu führt, dass CAN-Daten nur erfasst wurden, wenn dieses auf einem Gerät ausgeführt wurde.
Während der Entwicklung der SLSS CANAnalyser* CAN-Bus Software benötigte ich mehrere Arduino Uno R3* Micro-Controller Boards inkl. angeschlossener MCP2515 CAN Bus Shields*, um die Kommunikationschnittstelle mit dem Computer entwickeln, testen und debuggen zu können. Da jedes der CAN-Boards bereits 7 JumperWires* für den Anschluss an den Arduino benötigt und die beiden CAN-Verbindungsleitungen zwischen den Controllern auch noch dazugekommen sind, sah es auf meinem Basteltisch ziemlich „chaotisch“ aus und das obwohl ich nicht wirklich viel mit den Boards machte (ich arbeitete ja an der Software). Noch schlimmer wurde es, als ich den Aufbau, um für ein anderes Projekt platz zu haben, auf die Seite räumen musste. Dabei lösten sich zum Teil die Anschlussleitungen am CAN-Board, am Arduino oder gleich auf beiden Seiten und ich musste diese jedes Mal neu verbinden, was dann auf Dauer doch etwas nervig war.
Aus diesem Grund entschloss ich mich dazu ein Halterung zu konstruieren, welche das CAN Board mit dem Arduino verbindet, die Kabel etwas in Zaum hält und mir trotzdem noch die Möglichkeit bietet die übrigen Ein- und Ausgänge des Arduino-Boards frei zu konfigurieren. Jetzt hätte ich zu diesem Zweck natürlich eine Platine bauen können, welche das CAN-Board aufnimmt und auf den Arduino Uno* aufgesteckt wird. Dies habe ich in der Vergangenheit schon des Öfteren gemacht und das hat auch immer super funktioniert. In diesem Fall wäre es jedoch zum aktuellen Zeitpunkt unnötig gewesen, da ich sowieso die Idee habe für die CAN-Software ein passendes Hardware-Layout zu erstellen. Diesen Schritt möchte ich mir allerdings für die fertige Software aufheben, da ich dann genau weiß, was ich wie und wo umsetzen möchte. Um nun doch ein wenig Ordnung in meinen Versuchsaufbau zu bekommen und die Boards auch „mobil“ nutzen zu können, habe ich mich also für das Erstellen einer Halterung für den 3D-Drucker entschieden.
Meine Leidenschaft für die „Bastelei“ mit Micro-Controllern hat mittlerweile auch in meiner beruflichen Tätigkeit als Prüfstandstechniker Einzug gehalten. So ist innerhalb der letzten Jahre das eine oder andere „Helferlein“ für die Erleichterung unserer täglichen Arbeit und das Meistern von speziellen Mess- und Prüfaufgaben entstanden. Der Anstoß für die Entwicklung eines neuen Gerätes war dabei meist der einfache Fakt, dass für die Umsetzung der benötigten Messungen keine Hardware verfügbar, oder die verfügbare Hardware für die Aufgabe nicht genau passend war. Da dieser Umstand beim Testen von Einzelkomponenten oder Teilgruppen relativ häufig vorkommt, fand ich immer wieder neue Herausforderungen und konnte somit auch Dinge realisieren, welche ich so in dieser Art vorher noch nicht umgesetzt hatte. So war zum Beispiel meine erste CAN-Bus Anwendung eines dieser Bastelprojekte.
Ein weiterer großer Vorteil dieser „Eigenanfertigungen“ ist, dass ich die zum Betrieb benötigten Ein- und Ausgaben direkt an die von unseren Prüfständen zur Verfügung gestellten Eingangs- und Ausgangsschnittstellen anpassen kann. So wurde bei den meisten meiner „schwarzen Kästchen“ die Steuerung per analogem Eingangssignal im Bereich von 0V – 10V realisiert, während die Rückgabe der Einstell- und Messwerte meist per CAN-Bus erfolgte. Dies ist dem Umstand geschuldet, dass der Treiber des verwendeten Messsystems nur auf dem CAN-Eingang des Prüfstandes lesen, aber nicht senden kann.
In der Vergangenheit gab es immer wieder die Anforderung Magnetventile, Motoren oder andere elektrische Komponenten mit einer vorzugebenden Frequenz – Tastverhältniseinstellung, also per Pulsweitenmodulation* / PWM* (https://www.elektronik-kompendium.de/sites/kom/0401111.htm), betreiben zu können.
Da die Digitalausgänge unser Prüfstandshardware keine hohen Schaltströme zulassen, wurde für die Ansteuerung von elektrischen Bauteilen meist eine Kombination aus vorgeschaltetem Reed-Relais und nachgeschalteten Kfz-Last-Relais verwendet. Leider ließen sich mit dieser Kombination keine hohen Schaltfrequenzen realisieren (max. ca. 30Hz bis 50Hz), was dazu führte, dass für Schaltanforderungen mit höheren Frequenzen meist Fahrzeugsteuergeräte und Kabelbäume aufgebaut, und die Ansteuerung kompliziert über deren Software realisiert werden musste.
Meine erste Idee war, den Relaisverbund durch ein Metall-Oxid-Halbleiter-Feldeffekttransistor* (kurz: MOSFET) zu ersetzen, womit sich die Schaltfrequenz um ein vielfaches erhöhen lässt und einer direkten Ansteuerung nichts mehr im Weg steht. Da ich bereits für andere Schaltaufgaben MOSFETs verwendet hatte, passte ich eine dieser Schaltungen an die neuen Anforderungen an. Als wir diese Schaltung am Prüfstand testeten, stellten wir jedoch fest, dass mit den digitalen Ausgängen der Messkarten keine stabilen Frequenzsignale erzeugt werden konnten. Hierbei liegt das Problem jedoch weniger an der Hardware selbst, sondern eher an dem in der Prüfsoftware eingestellten Software-Takt, welcher bei höherer CPU-Auslastung ab und an ins Stocken geriet. Dies war bei der Ansteuerung eines Magnetventils hörbar und auch in den aufgezeichneten Messdaten sichtbar.
Da man hiermit keine vernünftigen Messergebnisse erzeugen konnte, kam ich auf die Idee, die Ansteuerung von Frequenz und Tastverhältnis über einen Micro-Controller zu realisieren. Dieser sollte auf Grund seiner internen Timer und der hardwarenahen Programmierung problemlos ein stabiles PWM-Signal erzeugen können.
Das man mit einem 3D Drucker mehr anfangen kann, als nur Gehäuse und Funktionsteile zu drucken, ist glaube ich landläufig bekannt. Durch die großen Online-Sammlungen an 3D Objekten hat man auf der einen Seite die Möglichkeit von Fahrzeugen über Häuser, Boote, Flugzeuge bis hin zu Einrichtungsgegenständen für Puppenhäuser, verschiedenste Objekte drucken zu können, ohne selbst das 3 Modell erstellen zu müssen. Auf der anderen Seite kann man natürlich auch noch nicht verfügbare Gegenstände per CAD-Software verkleinern und so ein maßstabsgetreues Abbild der realen Welt schaffen.
Da unser leitender Prüffeldmeister Ende Mai 2019 in seinen verdienten Ruhestand gegangen ist, wollten wir ihm zum Abschied ein Geschenk machen, welches ihn an seine Arbeit erinnert und seinen langjährigen Leistungen würdig ist. Da er am Entwurf und der Entwicklung eines unserer Prüfstände maßgeblich beteiligt war, hatten wir die Idee diesen Prüfstand* (https://patents.google.com/patent/DE102007057052B4) mit allem was dazu gehört nachzubauen. Eine Aufgabe, welche mir ca. 500 Stunden Arbeitszeit und einige graue Haare beschert hat.
SLSS CarNet ist ein Projekt, welches im Winter 2019 seinen Anfang genommen hat. Ich und einige meiner Freunde sind begeisterte US-Car Fans. Außerdem spielte ich schon länger mit dem Gedanken mir einen Kleinbus zuzulegen um mit meiner Frau, unseren beiden Kindern und den Großeltern den einen oder anderen Ausflug unternehmen zu können, ohne immer auf 2 Fahrzeuge aufgeteilt sein zu müssen. So kombinierte ich die Schwärmerei für US-Cars mit dem Wunsch des Kleinbusses und kaufte im Dezember einen amerikanischen Chevrolet Express, welcher von der Explorer Van Corporation zu einem „rollenden Wohnzimmer“ umgebaut wurde.
Nach dem Kauf des Vans kam mir recht bald die Idee, diesen um ein paar Funktionen zu erweitern. So gibt es zum Beispiel in der vorderen Deckenverkleidung ein Bedienpanel auf dem 3 Schalter für die Steuerung der verschiedenen Beleuchtungen im Innenraum des Van angebracht sind. Diese Beleuchtung, wozu auch ein Sternenhimmel gehört, macht den hinteren Teil des Vans zu einer Chill-Out-Area, welche für nüchterne, deutsche Verhältnisse fast schon ein wenig übertrieben anmutet, für mich als Fan aber einfach dazu gehört. Leider sind diese Schalter aber eben nur Schalter. So ist es nicht möglich das Licht zu dimmen, sondern nur ein- oder auszuschalten. Was beim Sternenhimmel noch ganz in Ordnung ist, sieht beim Schalter für die Lesebeleuchtung schon anders aus. Betätigt man diesen, so erstrahlen ganze 8 Leseleuchten, welche von vorn bis hinten über die ganze Fahrzeuglänge verteilt sind, mit voller Leistung. Dies ist so hell, dass der Vorbesitzer bereits alle 5W Glassockel-Lampen durch orange Leuchtmittel, wie sie zum Beispiel für Seitenblinker verwendet werden, ersetzt hat. Leider ist das orange Licht nicht wirklich dunkler und so kam mir die Idee die Beleuchtung mittels Pulsweitenmodulation zu dimmen. Eine weitere Idee war, dem Van aufgrund seiner Größe eine Rückfahrkamera zu spendieren. Da ich das originale Radio nicht durch ein Doppel-Din Gerät mit Kameraeingang ersetzen wollte und mir die Monitore für die Nachrüstkameras eher nicht gefallen, musste also eine Individuallösung her. So stand der Entschluss fest ein eigenes System zu entwickeln, was all diese Funktionen in einer grafischen Oberfläche vereint.
Nachdem ich mich ein wenig in die Handhabung der Raspberry Pi* eingearbeitet hatte, dauerte es nicht lange und ich kaufte mir eine 2. Raspberry Pi* fürs Wohnzimmer. Diese sollte dort einige Schalt- und Messaufgaben (Helligkeitsmessung, Schalten von Geräten mit IR-Empfängern wie HiFi-Decoderstation, TV-Receiver, etc.) übernehmen, damit diese platzsparend auch im Schrank untergebracht werden konnten. Diese Funktionen waren recht zügig umgesetzt und nun lag dieser auch damals schon recht leistungsfähige Mini-Computer hinter dem TV. Da wir viel und gern Radio, vorzugsweise Rockmusik, hören und ein Teufel Soundsystem besitzen auf dem sich diese auch super anhört, kam mir die Idee die sich langweilende Raspberry Pi* um ein Web-Radio zu erweitern, mit welchem wir einfach und bequem zwischen verschiedenen Internet-Radiosendern auswählen können. Das Ganze sollte sich natürlich, wie soll es auch anders sein, nahtlos in die selbstgebaute GUI (englisch: graphical user interface) meiner DIY-Hausautomatisierung* einbinden lassen. Der Startschuss zur Entwicklung des SHAS-Radio war damit gefallen.
Hinweis:Da dieses Projekt mittlerweile doch recht umfangreich geworden ist und Programmierkenntnisse sowohl in HTML, PHP, JavaScript als auch Python erforderlich sind, möchte ich hier keine detaillierte Nachbauanleitung, sondern viel mehr eine Anregung, respektive einen Wegweiser aufzeigen, um technikinteressierten Bastlern vorab eine grobe Richtung beim Start der Umsetzung eines ähnlichen Projektes zu geben. Bei Bedarf gebe ich aber auch gern die zur Installation nötigen Dateien weiter.
KOMMENTAR DES AUTORS
Version 1 – Headless SHAS-Radio für die Hausautomatisierung (2014)
In seiner ersten Version sollte das Radio ohne direkte GUI erstellt werden und ausschließlich über das Netzwerk fernsteuerbar sein, da die Radiofunktion auf der Raspberry Pi* im Wohnzimmer genutzt, aber über die Oberfläche meiner DIY-Hausautomatisierung*, welche wiederum auf einer anderen Raspberry Pi* läuft, bedient werden sollte. Der Plan war den Aufbau so zu gestalten, dass ich bei Bedarf auch weitere Räume mit einer Raspberry Pi* ausstatten und somit um ein Webradio erweitern hätte können. Da die Hausautomatisierung größtenteils in HTML, Javascript und PHP umgesetzt wurde, lag es nahe, dass SHAS-Radio auch mit diesen Sprachen umzusetzen, da damit die Kommunikation zwischen Hausautomatisierung und Radio einfach zu realisieren ist.
Nachdem ich meine DIY-Hausautomatisierung* um viele Softwarefunktionen erweitert hatte und der Umstieg auf die Raspberry Pi* mich neugierig auf die Welt der Elektronikbasteleien gemacht hat, empfahl mir ein guter – ebenfalls technikaffiner – Freund, doch mal einen Blick auf das Micro-Controller-Board namens Arduino* zu werfen. Zu diesem Zeitpunkt hatte ich auf Grund meiner Ausbildung zwar bereits ein Grundverständnis von Elektrik und Elektronik, doch Micro-Controller waren komplettes Neuland für mich. Da das Thema aber so interessant war, bestellte ich mir das empfohlene Starter-Kit mit dem Namen Fritzing Creator Kit*, in welchem neben einem Arduino* Uno R3 auch einige elektronische Bauteile, ein Breadboard* und eine Handvoll Verbindungsleitungen zum Anschluss der Bauteile enthalten war. Nach ein wenig Rumspielerei mit den enthaltenen Bauteilen kam mir die Idee dem Micro-Controller eine sinnvolle Aufgabe zu geben. Einen Funk-Temperatursensor für meine Hausautomatisierung hatte ich schon länger auf meiner Nice-To-Have-Liste, doch leider gab es nichts passendes zu kaufen. Jetzt war die Zeit gekommen, es anzugehen diese selbst zu bauen.
Eines meiner älteren aber immer noch aktuellen Projekte ist meine DIY-Hausautomatisierung mit dem treffenden Namen SHAS für Sepp Home Automation Systems. Die Idee dahinter war unsere Mietwohnung ohne bauliche Veränderungen ein wenig „smarter“ zu machen. Das Verlegen von Bus-Leitungen oder installieren von Unterputz-Schaltaktuatoren war hierfür keine Option, das diese bei einem evtl. Wohnungswechsel zurück gebaut werden müssten. Der Einfall hierzu kam mir im Jahr 2010, als ich einen Bericht über „Das Haus der Zukunft“ im TV gesehen habe. In diesem konnte man per Tablet alle möglichen Funktionen wie Beleuchtung, Jalousien, Kamin, etc. bequem von der Couch aus steuern. Die Steuerung wurde durch einen eigenen Hausserver samt daran angeschlossenen Schaltaktuator realisiert. Ich fand das Thema total spannend, wusste aber sofort, dass so ein Aufbau für eine Mietwohnung schlichtweg nicht praktikabel ist.
Diese Internetseite verwendet Cookies und Google Analytics für die Analyse und Statistik. Wir nutzen Cookies zu unterschiedlichen Zwecken, unter anderem zur Analyse und für personalisierte Marketing-Mitteilungen. Durch die weitere Nutzung der Website stimmen Sie der Verwendung zu. Wenn Sie mehr zu diesem Thema erfahren möchten, dann gelangen Sie hier zu unseren Cookie- und hier zu unseren Datenschutzrichtlinien
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Notwendige Cookies helfen dabei, eine Webseite nutzbar zu machen, indem sie Grundfunktionen wie Seitennavigation und Zugriff auf sichere Bereiche der Webseite ermöglichen. Die Webseite kann ohne diese Cookies nicht richtig funktionieren.
Präferenz-Cookies
Präferenz-Cookies ermöglichen einer Webseite sich an Informationen zu erinnern, die die Art beeinflussen, wie sich eine Webseite verhält oder aussieht, wie z. B. Ihre bevorzugte Sprache oder die Region in der Sie sich befinden.
Marketing-Cookies
Marketing-Cookies werden verwendet, um Besuchern auf Webseiten zu folgen. Die Absicht ist, Anzeigen zu zeigen, die relevant und ansprechend für den einzelnen Benutzer sind und daher wertvoller für Publisher und werbetreibende Drittparteien sind.
Statistiken
Statistik-Cookies helfen Webseiten-Besitzern zu verstehen, wie Besucher mit Webseiten interagieren, indem Informationen anonym gesammelt und gemeldet werden.
Nicht klassifiziert
Nicht klassifizierte Cookies sind Cookies, die wir gerade versuchen zu klassifizieren, zusammen mit Anbietern von individuellen Cookies.
