Posts by hdo26

Hi,

hmm, interessant.

Alternativ gibt es auch ein Python MPC-Modul wenn ich mich
nicht irre.

Ansonsten gäbe es noch 'subprocess.communicate()' als Möglichkeit
statt 'os.system'. Google einfach mal danach.

hdo

Quote from MatzeHH

Ich vermute, es hat was mit diesen Problemen zu tun:
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=111232
https://www.raspberrypi.org/forums/viewtop…123305&p=829723

Genau wie in den beschriebenen Situationen, rufe ich beim Laden der Playlist ja auch os.system auf.

Ich werde mal versuchen, nach dem Laden der Playlist die Event Handler mit remove_event_detect zu entfernen und danach mit add_event_detect neu zu setzen.

Gibt es alternativ eine andere Möglichkeit, Kommandos an den MPC zu schicken als mit os.system?

Edit: hier wird noch eine Lösung beschrieben: https://www.raspberrypi.org/forums/viewtopic.php?f=32&t=97152

Hi,

probier mal den Serial-Port 'non-blocked' zu lesen, bzw. mit timeout=0.

Schau mal, bei mir habe ich es so gemacht:

https://github.com/hdo/jukebox4kids/blob/master/pyjukebox.py

Quote from MatzeHH

Nachdem ich mich letzte Woche mit der Hardware beschäftigt habe (löten, bohren, sägen, malen), konnte ich mich gestern mal wieder der Software zuwenden.
Ich habe inzwischen das Display angebunden, was prinzipiell auch macht, was es soll.

Dem obigen Problem bin ich näher gekommen. Ich ahne, dass die Zeile

Code

buf = self.UART.read()

das Programm anhalten und auf Eingaben vom RFID-Reader warten lässt. Die Endlosschleife läuft jedenfalls nicht durch, wie ich leicht erkennen kann, wenn ich jeden Durchlauf eine Ausgabe machen lasse. Vermutlich wird deshalb auch der Event Handler für die Buttons nicht aufgerufen.

Ich habe noch nicht rausgefunden, wie ich dafür sorgen kann, dass das Program weiter läuft, wenn vom RFID-Reader nichts kommt.

Das ist sonderbar. Probier es doch mal aus in der Interrupt-Routine nur ein Flag
zu setzen und die Befehle nur in der While-Schleife abzuarbeiten.

Mit Isolieren meine ich, dass du aufpassen musst, dass die 230V Leitungen keine anderen Leitungen berühren können.

Meine Kinder neigen dazu, die Jukeboxen hin- und herzutragen.

Moin Matze,

beim HD44780 LCD muss ich passen,
da ich dieses Display nur für meine Jukebox4KidsV2 verwendet
habe und dort läuft das ganze auf einem ARM STM32.

Auch bei den Buttons kann ich dir nicht wirklich
weiterhelfen, da ich diese bei mir auch durch einen ARM
verarbeite. Grundsätzlich sollte das aber funktionieren.

Warum die Taster bei einem Playlist-Wechsel nicht mehr
funktionieren ist sonderbar. Hast du mal versucht,
nach einem Playlist-Wechsel ein paar Debug-Meldungen
auszugeben? Nicht dass das Python-Skript sich danach
beendet. Achja, dein Skript kann man überhaupt nicht
lesen, da die wichtigen Einrückungen fehlen, aber das
hast du ja selber festgestellt. Ansonsten probier
doch mal Github GIST aus, dort sollte es kein Problem
geben.

Zur Not kannst du auch mal die Polling-Variante für
das Einlesen der Buttons ausprobieren. Das Entprellen
muss du nur bei der Interrupt-Variante machen. 200ms
sollten reichen.

Das Netzteil von Reichelt kannst du nehmen, achte aber
bitte darauf das Netzteil ordentlich zu isolieren.

Als Gehäuse habe ich die Zeller-Holzkisten verwendet.
Diese kriegst du bei OBI für ca. 10 Euro. Ob du die normale
Variante nimmst (zum Lackieren) oder die Variante 'Buche lackiert'
ist dir selbst überlassen.

Bitte stell auch mal Bilder rein wenn du soweit bist

hdo

Hi Sonix,

sehr schön deine Jukebox! Ich freue mich, dass auch andere
sich an das Projekt wagen und es auch noch schön umsetzen.

Deinen Kindern wird es sicherlich freuen. Unsere beiden Jukeboxen
laufen fast den ganzen Tag.

Ich arbeite bereits an einer V3, denn mittlerweile haben wir >300 RFID
Karten rumliegen und es ist gar nicht so einfach eine Bestimmte zu suchen.

Viel Spaß noch damit!

VG

hdo

PS: Achja, welche Runtime benutzt du denn, um C# auf dem Raspi auszuführen? (Mono?)

Mit der verbauten Version B des Raspberry hat mit nur beschränkte Möglichkeiten.
Ich habe damals zursätzlichen einen ARM Cortex-M3 (ähnlich Arduino) verbaut,
der die Kommunikation mit den Knöpfen und RFID-Reader erledigt hat.

Mit dem neuen Raspberry B+ könnte es evtl. auch so gehen.

Quote from MichaRPI

Ich bin absoluter Raspberry Pi Anfänger.

Mich interessiert, wie man so viele Buttons mit dem Pi verbinden kann?
Werden die einfach an die Pins 17, 18, 27, 22, 23, 24 und 25 angeschlossen?

http://www.element14.com/community/serv…846A4D286&01NA=

Moin moin,

es ist etwas her, dass ich an der Jukebox gearbeitet habe.
Die V2 läuft seit fast 2 Jahren stabil und dennoch ist noch nicht alles fertig :-|

Ich habe den Code jetzt auf github gestellt, leider hatte ich keine
Zeit gehabt, den Code ausführlich zu dokumentieren.

Besser ein bissel als gar nichts:

https://github.com/hdo/stm32_jukebox4kids

Übrigens würde ich die V2 in dieser Form nicht mehr bauen.

Nach einem Update meiner V1 mit einem Read-Only Root-FS läuft diese
auch einwandfrei. Bei einem Proof-of-Concept habe ich eine eigenes
Linux auf Basis von Buildroot gebastelt und diese hat auch in 5 Sekunden
gebootet. Den Aufwand für eine Implementierung für den STM32 würde
ich heute nicht mehr machen. Die Implementierung mit einem
Rasberry Pi ist deutlich einfacher und besser wartbar (Python).
Ferner hat man dann auch Netzwerk und ggf. LCD display
(das steht als nächstes auf meiner Liste

hdo

Quote

Habe bisher noch keine Problem mit dem RDM630 gehabt. Hatte aber nie einen Dauerbetrieb laufen.

Es gibt billige Nachbauten die nicht so zuverlässig funktionieren wie das Original (RDM630 vs RDM6300). Zumindest war das meine Beobachtung. Beide Reader funktionieren natürlich,
nur war beim Original die Erkennung besser. An für sich bin ich aber begeistert von
den Karten, denn diese verrichten bei mir seit 2,5 Jahren problemlos ihre Arbeit und
sind zudem äußerst robust.

Quote

hdo26 die Karten EM4100 übertragen ständig, darum wird im C-Sample auch gleiche Ids gefiltert und erste wenn 1 Sekunde keine Meldung kommt gilt der Tag als entfernt.
printf("TagID %s gone\n", TagID);
Kann mir aber schwer vorstellen das das am den Karten liegt. Macht das nicht der Reader so, dass er ständig abfragt?

Bei mir lag es tatsächlich an den Karten. Ich hatte Karten aus verschiedenen Bestellungen und hatte das Verhalten beobachtet. Die RFID Reader habe ich bei mir
nicht direkt am RPi hängen, sonderen an einem LPC bzw. STM32 (ARM Cortex-M3/M4).

Moin Ulli,

ich kenne die USB Soundkarte von Rasppishop nicht, aber ich vermute
es handelt sich um einen C-Media Chip der häufig in dieser Preisklasse
eingesetzt wird. Der Sound ist ok, aber die Chips sind nicht besonders zuverlässig.

Such mal in der Bucht nach PCM2704. Das ist ein TI Burr-Brown USB-DAC welcher
für den Preis (knapp 10,-) wirklich gut ist. Ich selber habe mehrere davon
im Einsatz und die Soundqualität ist um Welten besser als der eingebaute PWM
vom RPi. Noch besser sind die I2S DACs von Sabre, aber die meisten hören
den Unterschied ohnehin nicht. Ich kann die PCM2704 Dinger nur empfehlen.
Unter RetroPie hört man einen deutlichen Unterschied zum eingebauten Sound.

hdo

Wie viele RFID Reader willst du denn anschließen?

In der Tat sind die 'Billig'-RDM6300 Dinger (3€) nicht 100% zuverlässig.

Interessanterweise gibt es auch Unterschiede bei den RFID-Karten.
Manche Karten übertragen ihre IDs kontinuierlich und manche Karten
nur einmalig. Du müsstest ggf. das Signal entsprechend filtern.

Ich habe sehr gute Erfahrungen mit den Groove-Modulen sowie Bricks-Modulen
gemacht (ca. 13€).

An meinem PI Modell B habe ich ebenfalls 2 USB-Konverter
hängen die Problemlos mit der Stromversorgung laufen.

Mit dem Modell B+ sollten 4 auch kein Problem sein.

Quote

Wieso rätst du dann das andere wenn du den Unterschied aber nicht verstehst? Icon_nosmile

Pull-DOWN -> GND runter auf GPIO
Pull-UP -> 3V3 rauf auf GPIO

GND zu schalten ist immer besser/schonender für die Hardware.

Ähm, genau das habe ich gemeint. Ich schalte grundsätzlich nach GND,
deswegen verwende ich Pull-Ups (IO mit R nach VCC).
Mit Pull-Up schaltet der Taster IO nach GND und mit Pull-Down schaltet der Taster
IO nach VCC. Christian verwendet Pull-Downs. In der Praxis wird halt
oft Pull-Ups verwendet (TTL UART, i2c, SPI, etc.).
Den Unterschied kenne ich schon.

Wie dem auch sei, jeder das Seine. Weiter gehts ...

Witzig, ich bin gerade dabei, einen Bartop zu bauen.

Kleiner Tipp: Bei e*** habe ich einen günstigen 17" TFT von NEC (LCD1770NX) für 19,- inkl. Versand gekauft. Das schöne an dem LCD ist, dass es recht flach ist und einen 12V Ausgang
hat. Damit werde ich dann den RPi versorgen.

Ich habe ebenfalls für 11€ zwei Pseudo-SNES Controller zum ausschlachten
gekauft. Das ist allemal günstiger als eine USB Controller-Board zu kaufen

Meine Buttons und Joysticks habe ich auch von e****, such mal nach 'arcade buttons'.

hdo

Du willst also nur mit einer Taste sowohl Klingeln als auch das Tor aufmachen?

Taste < 5 Sekunden = klingeln
Taste >= 5 Sekunden = Tor aufmachen

Ist das nicht etwas riskant? (Sicherheit etc.)

hdo

Quote from DackS

@ meigrafd,

Ich hatte mir das so gedacht:

das script wartet auf ne ansteigende Flanke an GPIO.22

wenn die kommt wird die for-schleife ausgeführt und wenn wärend der for-schleife die taste losgelassen wird (GPIO.22 == LOW), dann soll Klingel klingeln.

Wenn nicht, soll nach fünf Durchläufen das Tor geöffnet bzw. geschlossen werden.

Funktioniert auch so....mehr oder weniger.....
Hatte gerade bei einem Test, dass die Klingel klingelte obwohl das Tor auf ging.
Muß ich wohl noch mal rann....

hmmmm

Gruß

Christian

Display More

Ah ok. Apache ist allerdings alles andere als light-weight

Wenn du Polling statt Interrupts verwendest, solltest du irgendwo
ein 'sleep' einbauen, sonst hast du 100% CPU Auslastung.

Quote from DackS

Hi hdo26,

....es laufen noch zwei drei andere kleine scripts und ´n Apache auf dem RPi.
Ich glaub ich muß mich noch tiefer in die Python-materie einlesen um ne ordentliche Programmierung hin zu bekommen...

Quote

Dem muss ich widersprechen. Pull-Down ist schon gut weil dann GND auf den GPIO geschaltet wird, nicht 3V3.

Sorry, das verstehe ich nicht ???

Quote

Ehm, wenn man mithilfe time.sleep wartet wird das Script auch blockiert. Das was du schreibst widerspricht sich also etwas, vorallem aber weil in der Zeit wo das Script durch time.sleep blockiert wird auf kein Tastendruck reagiert werden kann - im Gegensatz zum GPIO.wait_for_edge denn das lässt das Programm weiter laufen sobald ein Tastendruck erkannt wurde.
Also GPIO.wait_for_edge ist imho besser als die allgemein übliche " while 1: time.sleep " Sache.

Les dir dazu mal das durch: http://sourceforge.net/p/raspberry-gpio-python/wiki/Inputs/

Nah, es kommt ganz darauf an, was man machen will. Bei 'GPIO.wait_for_edge' muss
man mit Treads arbeiten, wenn man im Hintergrund andere Sachen machen will.
Grundsätzlich gebe ich dir aber recht was Interrupts betrifft.
Mit Polling kriegt man keine 'Echt-Zeit' Button-Events hin. Für eine Garagentor-Steuerung
sehe ich das aber nicht als kritisch.

In meinem Jukebox Projekt benutze ich auch nur 'Polling' und es läuft wunderbar:

https://github.com/hdo/jukebox4kids/blob/master/pyjukebox.py
https://github.com/hdo/lpcx1343_c…s_ui/src/main.c

Hi Christian,

was läuft denn sonst noch so auf dem RPi?

Wenn nur das Skript läuft, kannst du eigentlich auf Interrupts verzichten.

Grundsätzlich würde ich auch eher Pull-Ups statt Pull-Downs verwenden.

Ich bin mir nicht sicher, aber ich glaube "GPIO.wait_for_edge" ist ein blockierender
Zugriff. Ich würde eher jeweils den Zustand non-blocking einlesen und dann 0.1 Sekunden warten. Mit Hilfe einer Variablen kannst du dann auf Zustandswechsel reagieren (Falling-Edge). Das Ganze würde man auch so hinbekommen, dass die Taste mind. 5 Sekunden
gedrückt werden muss.

hdo

Hmm, das ist äußerst sonderbar, denn das Skript leert ja die komplette Playlist
und lädt diese neu.

Gib mal bitte nach dem Neustart, wenn der zuletzt gespielte Track angespielt wird
die folgenden Befehle ein und poste mal deinen output:

mpc playlist

und danach:

mpc

Ich versuch mal nachzuvollziehen, was 'mpd' eigentlich abspielt.

Alternativ gibt es Möglichkeiten, 'mpd' in einem definierten Zustand zu starten.

EDIT: Achja, versuch mal das radio.sh Skript wie folgt zu ändern:

#!/bin/sh
mpc clear
mpc load radiosender
mpc play 1

Quote from chrissi1

Wenn ich das Skript manuel teste, dann spielt MPD korrekt den 1. Stream in der Playlist ab.

Wenn ich einen Neustart mache, dann spielt MPD auch automatisch den 1. Stream ab.

Sobald ich aber den Sender wechsle und dann wieder einen Neustart mache, spielt MPD den zuletzt, gespielten Sender ab und nicht den 1.

Was muss ich machen?

Kannst du ggf. Logs posten?

Neben mpd musst du auch noch das Paket 'alsautils' installiert haben.

hdo

Hi,

das hast du schon richtig gemacht.
Evtl. wird das Skript zu früh ausgeführt.

Was spielt MPD denn ab, wenn du manuell das Skript ausführst?

Ggf. muss noch noch ein "sleep 10" in das Skript in der 2. Zeile einbauen.
Dieser Befehl sorgt dafür, dass 10 Sekunden gewartet wird, bevor
die weiteren Befehl abgearbeitet werden.

hdo

Hier habe ich meinen ersten her (sehr schnelle Lieferung):

http://www.watterott.com/de/Raspberry-Pi-Modell-2

Meinen 2. habe ich von hier (zur Zeit nicht lagernd):

http://www.rasppishop.de/boards/3119/ra…uadcore-1gb-ram

Versuch mal folgendes:

Textdatei 'radio.sh' erstellen:

nano /home/pi/radio.sh

Folgenden Text eingeben:

#!/bin/sh
mpc clear
mpc load radiosender
mpc play

Nach dem Speichern die Datei "ausführbar" machen:

chmod a+x /home/pi/radio.sh

Danach kann man das Skript mit dem folgenden Befehl testen:

./radio.sh

Nach diesem Befehl wird die aktuelle Playlist zuerst geleert und danach die Playlist 'radiosender' geladen.

Wenn dieser Befehl funktioniert, kann du diesen für den Autostart definieren:

crontab -e

Folgende Zeile am Ende hinzufügen und speichern:

@reboot /home/pi/radio.sh

Danach sollte der Raspberry Pi nach jedem Neustart den Radiosender abspielen.

Bei mir hat es problemlos geklappt.

hdo