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


    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




    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.



    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/commu…1RI=F325F5846A4D286&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



    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.





    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... :-)


    :danke_ATDE:


    [hr]

    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/lpcx134…ukebox4kids_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:


    Code
    mpc playlist


    und danach:


    Code
    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:


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




    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

    Versuch mal folgendes:



    Textdatei 'radio.sh' erstellen:


    Code
    nano /home/pi/radio.sh


    Folgenden Text eingeben:


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


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


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


    Danach kann man das Skript mit dem folgenden Befehl testen:


    Code
    ./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:


    Code
    crontab -e


    Folgende Zeile am Ende hinzufügen und speichern:


    Code
    @reboot /home/pi/radio.sh


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


    Bei mir hat es problemlos geklappt.


    hdo