Ich hab das bislang nie ausprobiert, aber die Basis-Funktionalität ist im Phoniebox-Code offenbar bereits eingebaut:
In der playlout_controls.py gibt es schon die Befehle
# recordstart
# recordstop
# recordplaylatest
die man anhand der Anleitung Karten (oder auch Tasten) zuweisen kann.
Ja, bei meiner Methode kann man so 2, 3 Minuten pro Karte einplanen. Geht sicher schneller mit anderen Methoden. Sieht für den Zeit- und Materialeinsatz aber gut aus, finde ich.
Aber ich persönlich habe auch nicht wirklich Bedarf nach massenhafter Kartenproduktion. Bei so vielen Hörspielen, wie meine Kids hören, würde ich mich dumm und dusselig arbeiten - und auch zahlen - , wenn ich für jede Folge eine eigene Karte machen würde.
Stattdessen habe ich eine Karte pro Serie. Die Kids navigieren dann mit den Buttons von Folge zu Folge. Und zu Beginn jeder Folge kommt eine Ansage mit Folgennummer- und Name. Zudem gibt es Überraschungs-Karten bzw. Buttons mit denen eine Zufallsfolge oder eine Zufallsserie aktiviert wird. Das hat sich an sich gut bewährt bei uns.
Auch so bin ich bei mittlerweile 3 Phonienboxen (wo jedes Kind eigene Karten bekommt) Jetzt nach 3 Jahren schon bei über 100 Karten in Summe angelangt... Geht also ganz gut von der Hand, wenn man alle 3, 4 Monate mal wieder nen Schwung von 20, 30 Karten anfertigt... Was sich hingegen bewährt hat: Chinesische Magic Cards, deren IDs man per Hintertür-Kommando ändern kann. So hat die selbe Karte bei allen Kids dieselbe ID. Erleichtert die Administration ungemein...
Also soweit ich weiß, sind die allermeisten LEDs für einen Betriebsstrom von um die 20 mA konzipiert:
The forward current of an LED, IF, is the current which flows across the LED's leads, from anode to cathode, in order for the LED to receive sufficient current to power on. (...) Different kinds of LEDs have different forward current requirements. However, for the vast majority, visible-light LEDs (green, yellow, red LEDs) usually should receive a forward current of about 20mA.
Meine (aus ner Bastelbox für den Raspi) liegen bei bei 25 (Grün) bzw. 30 (Rot, Blau) Milliampere. Bereits mit 2 LEDs davon über GPIOs wäre die Spec des Raspis schon gerissen (wenngleich ich sie mit etwas höheren Vorwiderständen, also etwas niedrigeren Stromstärken betreibe, da sie sonst zu hell leuchten).
Die LED selbst können auch nicht allzu viel ab und gehen kaputt, wenn man den Vorwiderstand zu klein wählt oder gar ohne arbeitet. Bei meinen darf man maximal auf ca. 150 mA hoch, und auch das nur für 0.1 Millisekunden:
The peak forward current is the absolute maximum current that an LED can handle and this is only for a short period of time. The peak forward current, specified on a datasheet, can only be applied to an LED for the time period specified.
. Da wäre der Raspi aber vermutlich eh schon hinüber...
Bei GPIO Spannung von 3.3V fliest das doch ne Menge Strom (also für den RPI meinte ich jetzt).
Kann der RPI diesen Strom überhaupt liefern?
Ich dachte immer der komplette Summenstrom der GPIO darf ca. 30mA nicht übersteigen.
Genau, da muss man aufpassen, dass man sich den Microcontroller nicht zerschießt. Es sind glaube ich 50mA über alle GPIOS hinweg, aber da kann man bei der gängigen Dimensionierung handelsüblicher LEDs schon mit 2 Stück drüber kommen.
Ich steuere bis zu 5 LEDs gleichzeitig an und hab entsprechend Transistoren vorgeschaltet, so dass über die GPIO nur ein minimaler Strom fließt.
VLC war es mal, bevor vor ca. 1 Jahr auf MPD umgestellt wurde.
was steht denn in einem Beitrag weiter oben von hyle?!
Dass gpio16 vom digi+ verwendet wird? Aber das tut ja nix zur Sache hier...
Achso, noch eine Idee.
Wie hast Du die LEDs angeschlossen?
Geeigneter Vorwiderstand ist hoffentlich vorhanden?
Ideal wäre zudem eine Ansteuerung per Transistor, um den Stromfluss über die GPIO Ports zu begrenzen. Ab einer Handvoll LEDs ist man da ruck zuck schon am Ende der Spec des Microcontrollers angekommen bzw. läuft Gefahr ihn zu beschädigen. Wenn da noch ein HifiBerry dazu kommt, ist es sicherlich noch enger.
Hast Du mal ohne jegliche cronjobs, Pythonskripte und Co einfach mal per Kommandozeile (z.B. über SSH) getestet, ob die LED-Ansteuerung dann mit denselben oder ohne Nebenwirkungen funktioniert?
Einfach mit den folgenden Eingaben z.B. für GPIO 16:
// Einrichten:
echo "16" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio16/direction
// Anschalten:
echo "1" > /sys/class/gpio/gpio16/value
// Ausschalten:
echo "0" > /sys/class/gpio/gpio16/valueFür andere GPIOs entsprechend die Zahlen ändern.
Wozu zusätzlich LEDs und Stromverbrauch, wenn eh Power-Leds auf dem Raspi sind?
https://github.com/MiczFlor/RPi-J…th-fibre-optics
Der Fall kommt bei uns eher selten vor.
Entweder hört man bei uns der Reihenfolge nach, also einfach das nächste Hörspiel in der Reihe, das man noch nicht kennt. Dafür gibts ja inzwischen Autoresume.
Oder man will irgendwas hören, was man noch nicht kennt oder was man sich spontan aussucht. Dafür gibts bei uns die Überraschungs-Karte. Einfach ein paar Shuffle-Sprünge, bis etwas kommt, was genehm ist.
Dass eine bestimmte Folge aus einer langen Playlist gewünscht ist, kommt nur selten vor. Zu Tode hat sich dabei hier auch noch niemand gedrückt. Für Track 60 von 70 könnte man auch einfach 10x rückwärts gehen (dauert keine 5 Sekunden). Oder allgemein ein paarmal shuffle, bis man in der Nähe ist und dann noch ein paar Tracks vor/zurück. Alternativ stelle ich den gewünschten Track auch einfach schnell am Handy über das Webinterface ein. Aber wie gesagt, den Fall gibts bei uns nur selten.
Erstmal die richtige Karte aus einem Stapel mit xxx Karten zu suchen, dauert vermutlich länger.
Ja, so eine Karte ist ruck-zuck gebastelt, besonders wenn man mehrere auf einmal druckt.
Eine eigene Karte für jede einzelne Hörspielfolge finde ich aber irgendwie übertrieben. So oft hören die Kids dieselben Hörspiele nun auch wieder nicht (bis auf eine handvoll "Favoriten").
Ich hab pro Hörspielserie eine Karte gemacht und man kann dann mit den Buttons von Hörspiel zu Hörspiel springen. Auf meiner Box wird dann jeweils direkt nach dem Umschalten der Name der Folge angesagt. Ist bequem und schnell und spart ne Menge Karten.
Deren Mehrkosten werden dann von der separaten Spannungsversorgung für die Trustboxen (wahrscheinlich mehr als) wettgemacht.
Nicht wirklich. Aus der Grabbelkiste im Keller altes 700 mA Ladekabel vom Samsung Galaxy S2 gegriffen, den ausgeleierten und nicht wechselbaren micro-usb Stecker abgeschnitten und ans ebenfalls gekappte USB Kabel der Trust boxen gelötet - fertig ist der Lack für 0,00€
Also ich hab mit den Trust Leto in Verbindung mit der CSL-Soundkarte null Probleme (mit dem Onboard-Sound hab ichs nicht probiert).
Nach der Standardinstallation hatte ich zwar im Leerlauf durchaus auch erstmal etwas störendes Rauschen. Das bekommt man aber super einfach weg, indem man die Lautstärke (der Soundkarte) auf dem Pi hochstellt - am besten auf Maximum. Die Lautstärkejustierung kann man dann z.B. auch über das Verstärkerrädchen der Trust-Platine machen.
Was man unbedingt vermeiden sollte: am Pi eine niedrige Lautstärke ausgeben und die dann brutal über die Boxen hochregeln, da verstärkt man nämlich das Hintergrundrauschen mit, das sich auf den analogen Leitungen durch EM etc. zwangsläufig ergibt. Und der Verstärker der Leto-Boxen hat durchaus nen Range, der dazu verführt...
In meinen fertigen Phonieboxen läuft die Stromversorgung der Leto-Boxen über eine separate Stromversorgung, das entkoppelt dann nochmal zusätzlich.
Also ich seh bei mir jedenfalls keinen Bedarf, da noch zig Euros draufzulegen um den Sound noch weiter zu verbessern. Reicht völlig...
Du kannst die Funktion sowohl einer Karte als auch einem Button zuweisen (dazu muss man keine eigene SW hinzufügen)
Der Kartenbefehl heisst z.B SHUTDOWNAFTER30 oder SHUTDOWNAFTER60 für 30 bzw. 60 Minuten und kann in der rfid_trigger_play.conf einer Karte oder einem Chip zugewiesen werden. Dazu einfach die Zeile SHUTDOWNAFTER30="%SHUTDOWNAFTER30%" ändern in SHUTDOWNAFTER30="12345678", wenn 12345678 die ID der RFID-Karte/Chip ist, die Du dafür verwenden willst.
Für einen Button kannst Du in der gpio-buttons.py äquivalent wie bei den anderen enthaltenen Beispielen eine neue Funktion ergänzen wie:
def def_shutdown30():
check_call("./scripts/playout_controls.sh -c=shutdownafter -v=30", shell=True)und dann unten einem Button zuweisen, z.B.
shut30 = Button(22,pull_up=True)
shut30.when_pressed = def_shutdown30
Alternativ diese Transponderchips nehmen, dann halt mit kleinerem Aufdruck.
Mich stört es aber nicht wenn ab und an Mal ne Karte fehlt. Ich hab jetzt den zweiten 50er Pack für nen 10er aus Hongkong bestellt da kostet eine Karte 20ct. Ist ja schnell ne neue gebastelt...
Nach meiner Einhornbox für die Große letztes Jahr hab ich nun endlich die Dinobox für den Zweiten fertig gebaut 
Als wesentliche Neuerung hab ich die beiden onboard LEDs des Raspi über Lichtwellenleiter mit raus gelegt, damit man den Status noch besser sieht.
(Wer's damals nicht gelesen hat: die 5 großen LEDs oben sind zur Anzeige des restlichen Zeitkontingents - man kann mit Elterntranspondern Zeitlimits setzen)
Ich hab auch viele Hörspiele, da bräuchte ich ja hunderte Karten und das Kind findet gar nix mehr.
Die Software kann doch inzwischen beim zuletzt gehörten Hörspiel fortsetzen, da muss man dann nicht viel skippen. Alternativ macht man ein paar Mal shuffle bis man in der Nähe der gewünschten Folge ist und klickt sich dann den Rest durch.
Bzgl Software nehme ich Total Commander um das Netzlaufwerk der phoniebox mit einer vorbereiteten Ordnerstruktur auf meiner Festplatte zu synchronisieren. Geht mit wenigen Klicks...
Ich hab pro Hörspielserie eine einzige Karte.
Jedes Hörspiel ist ein einziger Track, so dass man also mit den skip Buttons ganz einfach von Folge zu Folge navigieren kann. Oder man lädt sich mit der Überraschungskarte eine zufällige Folge aus.
Zudem kommt bei mir zu Beginn jeder Folge eine kurze akustische Ansage mit der Folgennummer und dem Titel.
So kommt man mit vergleichsweise wenigen Karten aus (sind trotzdem noch ne Menge) und hat ne verhältnismäßig einfache Menüführung.
Die relevanten Teile sehen bei mir so aus:
#!/usr/bin/python3
from gpiozero import Button
from signal import pause
from subprocess import check_call
def def_shutdown():
check_call("/home/pi/RPi-Jukebox-RFID/scripts/playout_controls.sh -c=shutdown", shell=True)
def def_pause():
check_call("/home/pi/RPi-Jukebox-RFID/scripts/playout_controls.sh -c=playerpause", shell=True)
shut = Button(27, hold_time=2)
shut.when_held = def_shutdown
shut.when_pressed = def_pause
pause()
Das geht. Bei mir habe ich auf einem Button kurz: Pause/Resume und lang: Shutdown.
Bevor ein langer Tastendruck erkannt und gemeldet wird, löst vorher allerdings allerdings schon das kurze Ereignis mit aus.
Ist irgendwo logisch, da man z.B. bei einem "Next" button das Ereignis nicht erst haben will, wenn man den Button loslässt sondern schon direkt beim Reindrücken. Und wie lange das Drücken noch anhalten wird, kann die SW ja natürlich nicht wissen.
In meinem Fall wird also bei einem langen Druck erst die aktuelle Wiedergabe pausiert und kurz danach das Runterfahren eingeleitet. Hier stört das nicht, bei anderen Kombinationen mag das sicherlich anders sein.