Heute stelle ich kurz ein Miniprojekt, das aus gegebenem Anlass entstanden ist, vor. Zum Thema 3D-Druck mit dem Ultimaker 2 Drucker gibt es ja mittlerweile schon tonnenweise Informationen im Web. Auch die Steuerung über einen Webserver (octoprint) samt Webkamera Überwachung ist sehr gut dokumentiert und einfach zu realisieren. So haben es viele selbsternannte 3D-Drucker-Experten einfach, und können auf das umfangreiche Wissen aus dem Web zurückgreifen. An meinem Arbeitsplatz im Labor ist seit kurzem auch ein Ultimaker 2+ Drucker im Einsatz und wird, da ja viele Druckaufträge oft mehrere Stunden bis zur Vollendung benötigen, per Webcam überwacht. Jetzt könnte man den Drucker unbeaufsichtigt drucken lassen und den Raum oder das Gebäude verlassen und den Fortschritt remote überwachen. Doch wenn jetzt etwas nicht nach Plan verläuft und der Druckkopf beispielsweise mit dem Druckobjekt kollidiert oder das Druckobjekt selbst nicht so gedruckt wird, wie es der Slicer vorsieht, dann kann der Drucker nicht per Remote not-abgeschaltet werden.
Da der Octoprint – Server nun aber auf einem Raspberry PI läuft, dessen GPIO Port – Pins einfach ungenutzt herumstehen :), bieten sich diese an, ein Interface zu bauen, das im Falle des Falles die Stromversorgung des Druckers abschalten kann. Eine, in ein kleines Kunststoffgehäuse eingebaute Relaisplatine soll an die GPIOs angeschlossen werden. Die Relaiskontakte werden dann daran angeschlossene Schuko Steckdosen schalten. Ich habe die Relaisplatine für vier Kanäle dimensioniert, um nicht nur den Drucker notabschalten zu können, sondern zukünftig auch ein Abluftventilator etc. damit zu schalten. Die Schaltbefehle werden dann direkt am Raspberry, über z.B. Python-Skripten, oder einfach nur bash Kommandos ausgeführt.
Hier ist die supereinfache Schaltung für den Aufbau der Relaiskarte dargestellt:
Vom Papier zur fertigen Platine und diese dann in ein Gehäuse eingebaut und per 40poliger Stiftleiste und Flachbandkabel an den Raspberry PI angesteckt, ist im folgenden Bild zu sehen. Als Geräte Bezeichnung ist mir „Ultimaker Schuko Controller“ eingefallen. Da die Aluminium-Frontplatte des Gehäuses wegen der Aussparung für das Flachbandkabel ohnehin in den Fräsbohrplotter musste, habe ich den Schriftzug „Ultimaker Schuko Controller“ auch gleich dort verewigt.
Die Hardware ist nun fertig und mit dem Raspberry verbunden. Als GPIO Pins habe ich, wie im Schaltplan zu erkennen, die GPIOs 08, 23, 24 und 25 verwendet. Als einfachen Test kann man die Relais jetzt über das Terminalfenster des Raspberry (entweder lokal, oder über einen Putty) ganz einfach ansteuern. Als Beispiel ist hier GPIO Pin8 angegeben:
In einem früheren Blogeintrag habe ich einen Uhrenbausatz vorgestellt, dessen Anzeigenelemente mit VFD-Röhren aufgebaut sind. Diese Vakuum-Fluoreszenz-Display Röhren stammen, wie auch die Nixieröhren, aus den 60iger, 70iger Jahren und wurden dann von den LED 7-Segment Anzeigen abgelöst. Doch der Reiz der glimmenden, in Glaskolben verpackten Leuchtziffern erobert heute wieder so manches Wohnzimmerregal. Über den damaligen Beitrag über den VFD – Uhrenbausatz von gr-projects, bin ich mit dem Konstrukteur und Hersteller dieses Bausatzes, Herrn Rother in Kontakt gekommen. Herr Rother hat mir weitere Uhrenmodelle zur Verfügung gestellt, deren Auf- und Zusammenbau ich in Form kurzer Filme aufbereitet und dokumentiert habe. Die verwendeten Anzeigeröhren sind russische Röhren der Typen IV-11, IV-6 und IV-3.
Hier die Infos zu den Röhren:
IV-11:
Glaskolben mit einer Höhe von 55mm und einem Durchmesser von 22mm.
Anzeigehöhe 20x13mm (HxB)
Heizspannung 1,5V bei einem Strom von 50-70mA
Gitterspannung ca 25-30V
Lebensdauer ca. 5000h
IV-6:
Glaskolben mit einer Höhe von 40mm und einem Durchmesser von 12mm.
Im letzten Teil des Projektes „Raspberry Pi als Datenlogger“ habe ich einen Raspberry Pi als Datenlogger für unterschiedliche Sensoren konfiguriert. Als Schnittstelle dient der I²C Bus und die RS232 Leitungen, an denen die Sensoren angeschlossen sind. Die Sensoren waren ein HYT939 (Luftfeuchtigkeit und Temperatur), ein BME280 (Luftdruck, Luftfeuchte und Temperatur) sowie ein Ultimate GPS Board an der seriellen Schnittstelle. Der Raspberry Pi ist dabei in eine Box eingebaut, wird mit einer Powerbank, die sich ebenfalls in der Box befindet, versorgt und stellt als Schnittstelle eine 8 polige RJ45 Buchse mit I²C und RS232 nach außen zur Verfügung. An diese Buchse können dann die Sensoren angeschlossen werden. Will man die Sensorik nun ändern, bzw. erweitern, so können einfach weitere I²C Bus – Sensoren angeschlossen werden. Es muss lediglich noch die Software (in diesem Fall Python Skripten) angepasst werden und schon können die Daten des neuen Sensors empfangen und aufgezeichnet werden. Wie aber geht das System um, wenn der Sensor nicht über I²C spricht? Wenn zum Beispiel ein analoger Wert eingelesen werden soll? Ganz einfach: Soll die Hardware des Datenloggers nun nicht mehr modifiziert werden, so muss man einfach dafür sorgen, dass der neue Sensor, der beispielsweise analoge Spannungen ausgibt, diese an eine, nennen wir sie Black Box weitergibt, die wiederum an ihrem Ausgang ein I²C Bussignal bereit stellt. Das kann dann wieder in das bestehende System integriert werden.
Arduino Nano als I²C Converter
Und genau diese Aufgabe erfüllt ein Microcontroller. Praktischer Weise habe ich diesmal einen Arduino Nano dazu verwendet. Der Arduino Nano mit dem Atmega 328 besitzt ja mehrere analoge und Digitale Eingänge, sowie zwei Interrupts. Über entsprechende Libraries ist einfach das I²C Bus Protokoll zu realisieren. Somit ist das geeignete Black-Box Gerät gefunden.
Der folgende Arduino Code stellt einen einfachen I²C Bus Slave dar. Die Busadresse soll beispielsweise 0x08 sein, von einer Messung haben wir den Messwert 1.3321 erhalten. Dieser Wert soll bei Anfrage an diese Busadresse gesendet werden. Das Beispiel sieht wie folgt aus:
Im Skript ist eine Funktion „dtostrf“ zu sehen. Sie wandelt den Inhalt einer Variablen des Datentyps „floating point“ in ein Charakter Array um. Infos sind hier zu sehen. Im Python Interpreter des Raspberry können wir nun überprüfen, ob die Daten ankommen. Doch zuvor soll der gesamte Aufbau einmal schematisch dargestellt werden.
Schematische Darstellung des Systems
Sind alle Sensoren inklusive des Arduino angeschlossen, so kann das folgende Python-Skript aus der Linux Konsole des Raspberry aufgerufen werden:
# Reading data from arduino as sensor slave
# V0.1 by bihlo 09/2016
import smbus, time
bus = smbus.SMBus(1) # Raspberry Rev. 2
address = 0x08 # Fixed default address of Arduino
# Initialize sensor to acquire measurements
#def MeasurementRequest():
# void = bus.write_quick(address)
#time.sleep(0.1)
# Read from bus
def ReadMeasurement():
void= bus.write_quick(address)
time.sleep(0.1)
# Acquire 6 byte from sensor
Readout = bus.read_i2c_block_data(address,0,6)
out=''.join(chr(i) for i in Readout) #byte array von ascii in string wandeln
print "Antwort vom Arduino: ", Readout, " ."
print "Antwort als String: ", out
ReadMeasurement()
Wenn der Python Interpreter jetzt keinen Fehler meldet und der Inhalt der Variable „wert“ des Arduino in ASCII und im Klartext dargestellt wird, dann kann jetzt mit einem „richtigen“ Messwert eines Sensors weiter gearbeitet werden.
Partikeldetektor
Als Sensor soll an an den Arduino ein DSM501 Dust Sensor Module angeschlossen werden. Der DSM501A ist ein Staubsensor, der mit 5V bei einer Stromaufnahme von 90mA betrieben wird. Er erkennt Partikel ab einer durchschnittlichen Größe von 1µm bei einer Konzentration von 0 bis ca. 1.4mg pro Kubikmeter Raumluft. Laut Datenblatt und Herstellerinformationen wird die Luft im Bereich der Messkammer erhitzt, sodass eine Luftzirkulation entsteht. Die sich ständig bewegende Luft wird mit einem getakteten Lichtstrahl beleuchtet. Ein in einem Winkel zur Lichtquelle angebrachter Fotodetektor empfängt nun, im Falle dass sich Partikel im Licht befinden, dessen Streulicht. Die Intensität des Streulichtes ist von der Anzahl und Größe der Partikel abhängig und kann so erfasst werden. Als Ausgangssignal erzeugt der Sensor ein Puls/Pausensignal mit einer Periode von 100ms. Das Verhältnis von High- zu Lowtime stellt nun die Grundlage für die Berechnung der Partikelanzahl bzw. -dichte dar. Über einen Countereingang des Arduino werden die Impulse gemessen und der korrespondierende Partikelwert errechnet. Dieser Wert wird nun wie oben beschrieben als Busdatum für den I2C Bus herangezogen und bei Auslösen des Bus Events übertragen. Somit hat der Arduino die Aufgabe eines einfachen Protokollkonverters übernommen. Mit dieser Methode lassen sich alle möglichen Messwerte so aufbereiten, dass der Raspberry mit einer Schnittstelle damit umgehen kann.
Wie das im Detail funktioniert und wie der Code dazu aussieht, werde ich vielleicht später einmal posten.
Dieses Mal habe ich wieder ein Stück für die Rubrik Nostalgie Technik aus meiner Altgerätesammlung ausgegraben. Ich bezeichne es zumindest als Nostalgie Technik. Den Game Boy Color. Dabei handelt es sich um eine „Handheld Spielekonsole“ von dem Hersteller Nintendo. Der Game Boy Color wurde von Nintendo Ende des Jahres 1998 auf dem internationalen Markt veröffentlicht. Er ist der Nachfolger des legendären Game Boy mit dem monochromen Display. Der Game Boy Color bekam seinen Namen von seiner Eigenschaft, einen farbigen LCD-Bildschirm zu besitzen. Der Bildschirm hat auch hier, gleich wie sein Vorgänger, noch keine Hintergrundbeleuchtung.
Gleich wie der Ur-Game Boy rechnet in seinem Inneren ein 8-Bit Prozessor von Sharp (LR35902), der auf der Basis des Zilog Z80 aufgebaut ist. Der „color“ wurde bis 2003 hergestellt und wiederum von seinem Nachfolger, dem Game Boy Advance ersetzt. Laut Online-Quellen sind vom Game Boy Color ca. 50 Millionen Stück verkauft worden.
Hier nun die technischen Details:
CPU: Sharp LR35902 (8bit CPU auf Basis des Z80)
CPU Geschwindigkeit 4MHz/8MHz (4.338 bzw. 8.338MHz)
RAM: 32kB
VRAM: 16kB (das Videoram ist in die CPU integriert)
ROM: maximal 8 MB
RAM auf dem Cartridge 128kB
Bildschirmauflösung: 160×144 Pixel bei einer Farbtiefe von 15bit (32768)
Gleichzeitig auf dem Bildschirm darstellbare Farben: 10, 32, 56
Sprites: 40 max, 10 pro Zeile bei 4 Farben pro Sprite 8×8 bzw. 16×16 Pixel Spritegröße
Schnittstellen: Serial I/O Port mit 512kbit/s, Infrarot I/O, Cartridge I/O zur Aufnahme der Spiele-ROMS
Abmessungen: 133x75mm, 27 mm Dick
Gameboy Color InnenlebenSeitenansicht linksRückseiteMainboard NahaufnahmeNahaufnahme BildschirmSpielmodul (Cartridge)
Die Gameboy Spiele Cartridges sind auch im Gameboy Color spielbar. Die Module beherbergen einen ROM-Baustein mit dem Spiele-Code, einen SRAM-Baustein, sowie auch bei vielen Modulen eine Backup Batterie in (CR1616), die den Status des SRAM bei stromlosem, oder ausgesteckten Modul aufrecht hält. Über den Cartridge Steckplatz lässt sich der Gameboy und Gameboy Color auch für andere Anwendungen, außer Spielen, nutzen. Hier haben einige Entwickler und Bastler Module gebaut, mit denen der Gameboy zum Messgerät wird, die Software im Bereich Autotuning modifizieren kann, oder als programmierbare Steuerung fungiert. Es existieren hunderte Spieltitel für die Gameboy Serie. Der Boom und die Faszination der fernöstlichen Großaugen-Comics hat auch unsere Jugend erreicht und für die Epoche der 90er Jahre geprägt. So sind folgende Spieletitel auf der Liste der meist-verkauften Spiele gelandet. (Quelle: nintendo.wikia)
Diese kurze Anleitung beschreibt wie Fernsehaufnahmen, die mit dem tvheadend-Server empfangen werden, auf ein Share im Netzwerk aufgenommen werden können: (da in vielen Haushalten auch NAS Server zum Speichern der Familiendaten herumstehen, kann man sich einen USB Speicher am Raspberry sparen und auch die Fernsehsendungen auf dem gemeinsamen Speicher ablegen)
Voraussetzung:
Ein Netzwerk, in dem ein Share über ein NAS oder eine andere Netzwerkfreigabe existiert, die, wie im Beispiel hier das Sambaprotokoll beherrscht. Nehmen wir als Beispiel an, die Netzwerkfreigabe lautet wie folgt:
//192.168.50.50/NAS/TV/record
dieser Netzwerkpfad muss von allen Clients in diesem Netz erreichbar sein. Dann haben wir die erste Bedingung erfüllt. Weiters benötigen wir einen tvheadend Server, im selben Netz (die Bedingung ist auch erfüllt, da der Anspruch, die Aufzeichnung zu konfigurieren ja aus dem tvheadend Projekt kommt 😉 ). Nehmen wir an der tvheadend Server liegt auf 192.168.50.100 Dann testen wir im Browser durch Eingabe von:
https://192.168.50.100:9981
ob die tvheadend Weboberfläche erreichbar ist. Wenn ja, dann sind alle Grundbedingungen erfüllt. Jetzt muß am tvheadend Server die Konsole gestartet werden. (in diesem Fall ist der Server ein Raspberry auf dem xbian läuft)
Mit ssh xbian@192.168.50.100 in die Konsole einloggen.
dann mit „CTRL“+“O“ speichern und mit „CTRL“+“X“ beenden. Anmerkung: Auf dem Raspberry muss der Ordner „record“ im Verzeichnis /home/xbian/ angelegt sein bzw. mit mkdir record angelegt werden. Der Username bzw. das Password im obigen Eintrag bezieht sich auf das NAS, also die user/pass id mit der auf das NAS zugegriffen werden darf.
Jetzt mit sudo mount -a die fstab neu ausführen. Jetzt in das Webinterface von tvheadend wechseln und dort bei den Aufnahmeeinstellungen bei Speicherpfad /home/xbian/record eintragen. Ab sofort landen alle Aufzeichnungen am Netzlaufwerk des NAS…
Edit 09/2019:
Voraussetzung ist natürlich, dass Samba auf dem Raspi installiert ist. Hier ist mir auch aufgefallen, dass bei einem neu eingerichteten System eine andere cifs Version installiert wurde und beim Einrichten der Freigabe eine Fehlermeldung (host down…) auftauchte. Mit
sudo mount.cifs –version
kann die aktuelle Version angezeigt werden: In meinem Fall:
mount.cifs version 6.8
durch die Angabe einer Version im der fstab (vers=1.0, etc.) kann die Kompatibilität zur NAS-Freigabe wiederhergestellt werden.
sudo nano /etc/fstab
roc /proc proc defaults 0 0 /dev/mmcblk0p6 /boot vfat defaults 0 2 /dev/mmcblk0p7 / ext4 defaults,noatime 0 1 # a swapfile is not a swap partition, no line here # use dphys-swapfile swap[on|off] for that //192.168.xx.yyFRITZ.NAS/USBLAUFWERKSNAME/record /home/netrecord cifs defaults,username=meinNASLogin,password=meinNasPasswort,vers=1.0
Wie vor längerer Zeit im Blog angekündigt, soll der Geigerzähler nun eine Software bekommen, die nicht nur die Pulse des Zählrohres zählt, sondern sie auch auf eine Einheit bezieht. Hierzu waren aber noch kleine Änderungen an der Hardware notwendig. (genauer gesagt habe ich andere Pins des Arduino verwendet – was bedeutet: Leiterbahnen durchtrennen und mit Schaltlitzen neu verlegen). Hier eine Liste der Änderungen:
die Leitung von Pin4 Arduino zu Pin D7 vom LCD unterbrechen
die Leitung von Pin5 Arduino zu Pin D6 vom LCD unterbrechen
D7 vom LCD an Pin12 vom Arduino verbinden
D6 vom LCD an Pin13 vom Arduino verbinden
der Zählimpuls wird von TP3 auf Arduino Pin4 geschaltet
die Verbindung TP3 zu Arduino Pin23 wird getrennt
Daraus ergibt sich folgende I/O Port/Pin Belegung:
NES – Nintendo Entertainment System ist sicher auch noch vielen ein Begriff. Es war die 8-Bit Spielekonsole der Firma Nintendo, die Mitte der 80iger Jahre auch in Europa verkauft wurde und die Jugend der Zeit geprägt hatte. Mittlerweile ist sie doch ein Museumsstück, das bereits den Titel „Retro“ verdient. Vielleicht auch aus diesem Grund, beginnt sie in der Retrogamergemeinde wieder aufzuleben. So soll beispielsweise noch dieses Jahr ein Remake der NES in miniaturisierter Form mit moderner Technik und vorinstallierten Spielen auf den Markt kommen.
Auch über Emulatoren für alle möglichen Plattformen kann man die alten NES Spieletitel wieder zum Leben erwecken. Um diese Spiele auch „artgerecht“ bedienen zu können, (natürlich geht es auch mit der PC Tastatur oder über den Touch-Screen am Handy) hat das Unternehmen 8Bitdo Tech den NES30 GamePad Controller auf den Markt gebracht. Es handelt sich dabei um einen Wireless Bluetooth Controller der exakt dem originalen NES Controller nachempfunden wurde. Er ist mit einem Integrierten Akku ausgestattet, der über eine MicroUSB Kabelverbindung geladen werden kann. Der Controller ist so konstruiert, dass er sowohl als PC-Gamecontroller, als Joystick, als Bluetooth-Keyboard und als USB Joystick konfiguriert werden kann. Das lässt sich über fünf unterschiedliche Modes realisieren. Diese Modes können durch Tastenkombinationen während des Einschaltens ausgewählt werden. Die Tabelle unten zeigt die unterschiedlichen Modi:
Mode1
Mode2
Mode3
Mode4
Mode5
Joystick
BT-Keyboard
iCade
Emu-Touch
USB-Joystick
Power ON
START
START+B
START+A
START+X
Kabelverbindung
Blaue LED blinken
1x
2x
3x
4x
–
OS
WIN Android
WIN/Apple Android
Android Apple
Android Apple
WIN
Im Bild ist die USB-Ladebuchse zu sehen, rechts davon sind zwei Status-LEDs .
auf der Rückseite der Platine ist der Akku untergebracht
die Platine des Controllers; der die Firmware des Mikrocontrollers kann aktualisiert werden
Kontaktmatten stellen die Tasten dar. Unter den beiden Schultertasten liegen echte Mikrotaster …
Hier wird der Emulator „NES Emu“ auf einem Android-Handy mit dem NES30 bedient 😉
Uhren und Zeitmessgeräte, auch die nicht-mechanischen, gehören zu meinen Interessengebieten. Vor allem, wenn die Uhrzeit mit optisch schönen Anzeigen dargestellt wird, bin ich Feuer und Flamme. Dazu zählen Nixie-Anzeigeröhren und auch die VFD-Röhren. Über letztere handelt dieser Blogeintrag. Hier hat Herr Günter Rother (www.grother.de) einen sehr schönen Bausatz zusammengestellt, der schnell und einfach zusammen zu setzen ist. Es sind alle zum Aufbau benötigten Teile enthalten und man kann gleich loslegen.
Auf einer zweiseitigen, gelayouteten und mit Lötstoplack versehenen Platine mit den Abmessungen 100×50 mm findet die Uhrenschaltung Platz, bei der als Anzeige für jede Ziffer je eine 7-Segment VFD-Röhre verwendet wird. VFD bedeutet hier Vakuum-Fluoreszenz-Display. Die Funktionsweise ist hier nicht wie bei Nixieröhren eine Glimmentladung, sondern wie bei Elektronenröhren, eine, von einer direktbeheizten Kathode emittierte Elektronenwolke, die auf einer Leuchtschicht – Anode (Phosphor) auftrifft. Die Spannung zwischen Kathode und Anode liegt hier üblicherweise zwischen 20V und 50V. Mit einem Steuergitter vor den Segmenten können die Elektronen gezielt gebremst werden. Somit ist eine Ansteuerung einzelner Segmente möglich.
Treiberbaustein für die IV-3 VFD-Röhre ist ein LB1240 Display Tube Driver IC, der acht voneinander unabhängige Darlingtonstufen beinhaltet. Jeder Ausgang ist in der Lage 30mA bei maximal 55V zu treiben. Die Eingänge des LB1240 werden über einen Atmel AT89C2051-12PU angesteuert und mittels vier Transistoren wird jede Röhre per Multiplexing geschaltet. Getaktet wird der Atmel mit 11.0592Mhz. Ein DS18B20 Temperatursensor ist ebenfalls in den Bausatz integriert, um auch die Temperatur anzeigen zu können. Der DS18B20 ist ein 1-Draht Digital-Temperatursensor, einstellbar in 9 bis 12 Bit-Auflösung an 5V Spannungsversorgung und mit einer Ansprechzeit von 94ms bis 750ms, je nach Auflösung. Der Mikrocontroller ist bereits mit der Firmware für die Uhr geflashed und direkt einsatzbereit. Die IC´s sind gesockelt, 1/25W Kohleschichtwiderstände auf Band und sogar alle Schrauben, Abstandhalter und vorgefertigte Acrylglasplatten für ein finales Gehäuse sind vorhanden.
Die gesamte Schaltung wird mit einem 50Hz Steckernetzteil mit konventionellem Eisenkerntransformator versorgt. Die Spannungen an Board werden mit einem 7905 Linearregler für die 5V und einem fertigen DC/DC Convertermodul (Step-UP-Wandler) für die ca.30V Anodenspannung erzeugt. Bedient wird die Uhr über zwei Mikrotaster, mit denen Stunden und Minuten eingestellt werden können.
Ein kurzes Video über den Zusammenbau und die fertige Uhr kann hier angesehen werden:
Nach schon einigen Projekten und Versuchen mit dem Raspberry PI, bin ich immer wieder einmal auf die Problematik mit der schlechten, verrauschten Tonqualität des Raspi-Audioausgangs gestoßen. Der analoge Ton besteht ja nur aus einem einfachen PWM (PulseWidthModulation) Signal, das über ein paar Filtercaps direkt an die Klinkenbuchse des Raspberry geschaltet ist. Für viele Anwendungen reicht das sicherlich, wenn man nur eben einmal ein paar Töne ausgeben will. Soll´s aber Musik sein, oder wie in meinem Fall ein vernünftiger Ton bei der Retro-Gamestation, die mit „retropie und der EmulationStation“ läuft, so reicht die Qualität einfach nicht aus.
Hier sollte man dem Raspberry PI einen richtigen Soundchip, also Soundkarte verpassen. Im Internet wird man schnell fündig und so habe ich mir bei einem Onlineshop um gerade einmal 2,90 Euro eine USB – Soundkarte bestellt. Die Karte, oder besser, der USB Dongle besitzt zwei 3,5mm Klinkenbuchsen. (einen Audio-Ausgang und einen Mikrofon-Eingang)
Die Installation ist schnell durchgeführt. Will man ein bestehendes System umrüsten, so ist einfach der Klinkenstecker der Lautsprecherzuleitung vom Raspberry abzuziehen und in den Audioausgang des Raspberry einzustöpseln. Der USB Stecker kommt in einen freien Port des Raspberry.
Der Hardwareteil ist somit erledigt und es kann mit dem Anpassen der Software begonnen werden. Nach dem Booten der Retropi-Maschine und dem Einloggen in die Konsole kann man überprüfen, welche Geräte am USB-Bus erkannt wurden. Nach der Eingabe von:
pi@retropie:~ $ lsusb
werden alle am USB-Bus angeschlossenen Geräte gelistet:
Bus 001 Device 007: ID 1516:1603 CompUSA Flash Drive
Bus 001 Device 006: ID 03f0:034a Hewlett-Packard
Bus 001 Device 005: ID 16c0:05e1 Van Ooijen Technische Informatica Free shared USB VID/PID pair for CDC devices
Bus 001 Device 004: ID 0d8c:013c C-Media Electronics, Inc. CM108 Audio Controller
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
In diesem Fall ist der C-Media Electronics, Inc. CM108 Audio Controller unsere USB – Soundkarte. Als nächsten Schritt überprüft man die Reihenfolge (Priorität) der geladenen Soundmodule.
pi@retropie:~ $ cat /proc/asound/modules
Als Ergebnis kommt:
0 snd_bcm2835
1 snd_usb_audio
Das bedeutet die Soundausgabe des BCM2835 ist als erstes gelistet. Wir wollen jedoch alle Tonausgaben über den USB-Ausgang hören. Dazu muss die Datei „alsa-base.conf“ wie folgt angelegt werden. (auf einigen Systemen ist sie bereits vorhanden – hier sind dann nur die Prioritäten anzupassen)
Mit „control+O“ wird gespeichert und mit „control+X“ kann der Editor beendet werden. Jetzt ist das System zu rebooten. Nach dem Neustart kann in der Konsole nochmals mit:
pi@retropie:~ $ cat /proc/asound/modules
die Reihenfolge der Module überprüft werden. Die sollte jetzt so aussehen:
0 snd_usb_audio
1 snd_bcm2835
Jetzt sollten in der Emulationstation wieder Töne zu hören sein. Diesmal aber ohne Rauschen und kristallklar 😀
Als Kunde des A1 IPTV – Angebotes bekommt man ein A1 DSL – Modem samt einer A1 TV-Box. Diese Kombination funktioniert natürlich einwandfrei. Möchte man den Funktionsumfang erweitern und beispielsweise eine MINIX NEO – Box als Streaming Client betreiben, so bietet sich hier die bekannte Software „KODI“ an, die für alle möglichen Hardwareplattformen und Betriebssysteme erhältlich ist.
TV-Variante ohne Server, ohne Aufnahme und Timeshift
Die A1 TV – Box kann man direkt gegen die MINIX Box ersetzen. Auf der Mini-Box läuft ein Android Betriebssystem. Unter kodi.tv kann man sich den Client herunterladen und auf der Mini Box installieren. Dann ist noch unter SYSTEM -> STETTINGS -> ADDONS -> PVR clients auszuwählen.
Dort findet man den PVR IPTV Simple Client der zu installieren ist. Unter Konfiguration ist der Pfad zu einer .m3u – Liste anzugeben. Die m3u Liste sollte einfacher weise in einem lokalen Ordner (z.Bsp. Downloads) abgelegt werden.
Die .m3u – Datei beinhaltet die IP-Adressen mit den Streaming-Links und Sendernamen und sieht für die Basissender von A1 so aus:
Jetzt muss nur mehr „Settings“ -> „TV“ der „Enabled“ Button gecheckt werden und die Wiedergabe der TV-Kanäle sollte funktionieren. Mit dieser Methode ist stellt die Android Box einen IPTV Client dar, der die Streaming Links direkt abspielt. Da kein Server im Hintergrund läuft, ist es auch nicht möglich Timeshift oder Aufnahmen von Sendungen zu realisieren.
TV – Variante mit Server, Timeshift, EPG und Aufnahme
Um diese Funktionen zu erhalten, muss ins heimische Netzwerk ein IPTV Server integriert werden. In meinem Fall habe ich einen Raspberry Pi2 für diesen Zweck konfiguriert. Folgende Komponenten benötigen wir dazu:
Raspberry Pi2 (an das heimische Netzwerk angeschlossen)
Micro SD Karte mit 8GB
eine externe Festplatte oder USB-Stick als Speicher für die Aufnahmen
Ist alles heruntergeladen, so beginnt man mit dem Extrahieren des Images auf die Speicherkarte. Dazu startet man die Software win32diskimager.exe und wählt den Pfad zur Image-Datei. (die nennt sich in diesem Fall: XBian_Latest_rpi2.img). Dann ist die Speicherkarte einzulegen und der zugeordnete Laufwerksbuchstabe auszuwählen. Danach kann der Schreibvorgang mit „Write“ gestartet werden. ACHTUNG: Das gewählte Laufwerk wird mit dem Image ausgestattet. Hier unbedingt sichergehen, dass nicht ein falsches Laufwerk ausgewählt wird. Nach ein paar Minuten ist die SD-Karte fertig beschrieben und kann in den Raspberry PI eingesteckt werden.
Jetzt kann man den Raspberry PI an einen Monitor, Keyboard, LAN und per Micro-USB an eine 5V/2A Versorgung anschließen. Er wird jetzt booten. Es startet das Script: raspi-config, das bequem mit dem Keyboard bedient werden kann. Hier wird als erstes der tvheadend – Server installiert:
Zunächst wählt man „Packages“ aus und bestätigt.
dann scrollt man bis zur Kategorie „video“ und bestätigt wiederum.
hier ist nun tvheadend auf „Yes“ zu setzen und wieder zu bestätigen. Jetzt beginnt der Download des Paketes und die anschließende Installation. Ist der Prozess beendet, so ist das raspi-config script zu beenden und in die bash zu gehen. Der default Login lautet: xbian und das Passwort: raspberry
Zunächst sind noch alle Updates und Upgrades durchzuführen:
sudo apt-get update sudo apt-get upgrade
Als nächstes macht es noch Sinn, die IP Adresse des Raspberry PI zu kennen, die er vom DHCP Server des Routers zugewiesen bekommen hat. Die müssen wir ja wissen, wenn wir auf den TV-Server Zugriff haben wollen. Dazu gibt man einfach folgendes ein:
ifconfig
Als Antwort erhält man dann folgende Infos zum Ethernet – Anschluss. In diesem Fall eth0:
Wie man sieht, ist in diesem Beispiel die Adresse 10.0.2.15 zugewiesen worden. Mit dieser Information können wir den Raspberry Pi nun neu starten und an einem Client-Computer mit dem Setup von TVHeadend fortfahren.
sudo reboot
Nach dem Neustart sollte der Raspberry tvheadend-Server jetzt auf einem Client-PC erreichbar sein. Dazu öffnet man einen Webbrowser und gibt in der Adresszeile folgende Adresse ein: https://10.0.2.15:9981
Jetzt muss folgendes zu sehen sein:
Wir suchen und klicken auf den TAB „Konfiguration“. Hier geben wir ein paar allgemeine Einstellungen ein: den Servernamen (bei mir hier einfach Tvheadend); den Ansichtsmodus stellt man auf „Experte“. Die restlichen Einstellungen belässt man auf default. Unter Spracheinstellungen ist „German“ zu wählen. (oder was auch immer gewünscht wird). Die Webbenutzeroberfläche ist im default Modus auch ganz schön. Wer auch noch Senderlogos haben will, der stellt unter „Picon“ wie folgt ein:
Nach all den Einstellungen nicht vergessen auf „Speichern“ zu klicken. Jetzt kommt die eigentliche Arbeit: Das Editieren der Senderliste. Hierzu erstellt man als erstes ein „Netzwerk“. Unter den Tabs: Konfiguration -> DVB-Inputs -> Netzwerke legen wir ein neues „Netzwerk“ (eigentlich TV-Netzwerk) an.
Mit „Hinzufügen“ öffnet sich ein Fenster in dem man „IPTV Network“ auswählt. Bestätigt man das so öffnet sich ein weiteres Fenster. Hier nimmt man ein paar wenige Einstellungen vor. Sinnvoller Weise benennen wir das Netzwerk A1TV.
Mit „Speichern“ werden die Einstellungen abgeschlossen. Jetzt klickt man auf den TAB „Muxes“. Hier müssen alle Sender angelegt werden. Diese Arbeit muss man sich einmal antun. (Es gibt dann aber die Möglichkeit, über die Konsole die config-Dateien vom Server zu sichern – dazu später aber mehr)
In dem Bild ist die fertige Mux-Tabelle zu sehen. Mit „Hinzufügen“ wird ein neuer „MUX“ (Signalquelle) hinzugefügt. Hier wählt man aus den verfügbaren Netzwerken A1TV (das, das wir vorher angelegt haben) aus.Im sich jetzt öffnenden Fenster ist unter URL die Streaming – Adresse vom jeweiligen Sender einzugeben (hier z. Bsp.: rtp://239.2.16.21:8202 für 3sat). In Mux-Name ist der Sendername einzugeben.
Danach auf „Speichern“ drücken und mit „Hinzufügen“ den nächsten Sender konfigurieren. Hat man die mühevolle Arbeit dann getan und alle Sender eingegeben, so müssen die Muxes einem Service/Kanal zugeordnet werden. Das ist die eigentliche Senderliste, die der Server dann den Clients zur Verfügung stellt. (Ein MUX muss jetzt nicht unbedingt eine IP-Streaming Adresse sein, sondern kann auch aus einem Sat-, oder DVB-T Empfänger kommen. Da hier in einer Signalfrequenz mehrere TV oder Radioprogramme per Multiplexverfahren (eben MUX) übertragen werden. Darum ist die Bezeichnung MUX für IP-Adressen hier vielleicht etwas verwirrend). Das Zuordnen der Services geschieht im TAB „Services„. Hier einfach auf „Services zuordnen“ -> „alle Services zuordnen“ klicken und warten bis der Prozess abgeschlossen ist. Nun kann ein erster Test erfolgen.
Links neben den Kanalnamen ist ein kleiner „Play-Button“ zu sehen. Ist das VLC-Player-Plugin im Browser installiert, so wird beim Anklicken des Buttons ein Wiedergabefenster geöffnet, das den aktuellen Stream anzeigt.
EPG und Senderlogos
Weiter geht´s beim Konfigurieren nun mit dem elektronischen Programm Guide (EPG). Hier muss ein wenig getrickst werden. Aus diversen Foren und Anleitungen im Web habe ich eine für mich funktionierende Konfiguration zusammengestellt. Wir beginnen im Tvheadend-Server unter Konfiguration -> Kanal/EPG -> EPG-Grabber Module mit den Einstellungen.
Hier ist der interne Grabber „XMLTV: Sweden (TVZon)“ zu aktivieren. Danach wieder auf Speichern drücken.
Danach müssen wir wieder auf den Raspberry PI in die Konsole. Man macht das entweder vom Client-PC aus über ein Terminal (z. Bsp. Putty) oder direkt am Raspberry PI, wenn dieser noch an Keyboard und Monitor angeschlossen ist. Die folgenden Anleitungen stammen von https://github.com/Bronkoknorb/a1tv-helpers
Ist die Konsole, am besten als root-admin geöffnet, so installiert man zuerst ruby und die dazugehörigen libraries.
sudo apt-get install xmltv-util
sudo su hts
tv_grab_se_tvzon --configure
Nach der letzten Eingabe fragt das Konfigurationsscript des Grabbers nach folgenden Informationen:
Root-URL for grabbing data (hier https://xmltv.xmltv.se/channels-Austria.xml.gz eingeben)
Directory to store the cache: /home/hts/.xmltv/cache
Select Channels : Hier allauswählen
Jetzt muss der TVheadend – Service neu gestartet werden:
sudo service tvheadend restart
Jetzt kann wieder auf das Webinterface von TVheadend gewechselt werden. Im EPG-Grabber TAB kann jetzt noch die Zeit zum Synchronisieren der EPG Datenbank ausgewählt werden.
Die Senderlogos werden weitgehend gefunden. Wo das Senderlogo fehlt, kann unter dem TAB Kanal/EPG -> Kanäle in der Spalte Benutzerlogo ein Link mit einem geeigneten Logo eingetragen werden.
Jetzt ist der Server soweit fertig konfiguriert und die Clients können eingerichtet werden. In meinem Fall habe ich auf der MINIX NEO X8 Android Box ein Kodi installiert. In der Liste Addons -> PVR-Addons ist unter vielen auch ein TVHEADEND Addon gelistet. Dieses wird installiert. Alle anderen PVR-Addons müssen deaktiviert werden.
In den Client Einstellungen ist lediglich noch die IP Adresse des Raspbery PI anzugeben. Die Ports sind default (9981). Wenn beim TVheadend Server kein eigener User angelegt ist, so brauchen wir auch im Client unter user und pass nichts einzutragen.
Jetzt fehlt nur mehr die Aufnahmefunktion am Server. Hierzu begeben wir uns wieder in das Webinterface vom Server. Unter Konfiguration -> Aufnahme sind die abgebildeten Einstellungen zu machen:
Ich habe hier das default profile editiert. Wichtig ist der Aufnahmedateipfad. Steckt am Raspberry PI ein externer USB-Datenträger, so kann dieser für die Aufnahme verwendet werden. (In der Xbian Konsole kann man sich den Datenträger entsprechend vorbereiten und Verzeichnisse erstellen). Die Einstellungen sind weitgehend selbsterklärend….
Edit: 09/2019…
Es muss natürlich nicht das XBIAN Image sein. Die aktuelle Version habe ich auf ein Raspbian Image installiert. Das bekommt man von der RaspberryPi Website. Ist das Image auf der SD-Karte, dann sollte man mit „raspi-config“ das Filesystem „expandieren“ und das SSH Service installieren. Danach ein:
sudo apt-get update sudo apt-get upgrade
durchführen und dann das tvheadend Paket installieren.
sudo apt-get install tvheadend
Während der Installation wird man nach einem einzurichtenden Username und Passwort für den TVheadend-Server gefragt. Hier ist natürlich auch was einzugeben. Ist die Installation fertig dann kann im Webbrowser über:
http://ip-adresse-des-raspi:9981
getestet werden, ob der Server läuft. Wenn jemand nicht weiß welche IP der Raspi vom DHCP bekommen hat, dann einfach in der Konsole mit
ifconfig
nachsehen. Soll der Raspi eine statische IP-Adresse bekommen (ist bei einem Server vielleicht keine schlechte Idee), dann mit einem Editor die folgende Datei editieren:
nano /etc/dhcp.conf (hier sind einige Static IP templates auskommentiert) diese einfach an die gewünschten Adressen anpassen. Mit dem folgenden Command dann den Service restarten:
Heute stelle ich kurz ein Miniprojekt, das aus gegebenem Anlass entstanden ist, vor. Zum Thema 3D-Druck mit dem Ultimaker 2 Drucker gibt es ja mittlerweile schon tonnenweise Informationen im Web. Auch die Steuerung über einen Webserver (octoprint) samt Webkamera Überwachung ist sehr gut dokumentiert und einfach zu realisieren. So haben es viele selbsternannte 3D-Drucker-Experten einfach, und können auf das umfangreiche Wissen aus dem Web zurückgreifen. An meinem Arbeitsplatz im Labor ist seit kurzem auch ein Ultimaker 2+ Drucker im Einsatz und wird, da ja viele Druckaufträge oft mehrere Stunden bis zur Vollendung benötigen, per Webcam überwacht. Jetzt könnte man den Drucker unbeaufsichtigt drucken lassen und den Raum oder das Gebäude verlassen und den Fortschritt remote überwachen. Doch wenn jetzt etwas nicht nach Plan verläuft und der Druckkopf beispielsweise mit dem Druckobjekt kollidiert oder das Druckobjekt selbst nicht so gedruckt wird, wie es der Slicer vorsieht, dann kann der Drucker nicht per Remote not-abgeschaltet werden.
Die Spannung zwischen Kathode und Anode liegt hier üblicherweise zwischen 20V und 50V. Mit einem Steuergitter vor den Segmenten können die Elektronen gezielt gebremst werden. Somit ist eine Ansteuerung einzelner Segmente möglich.
