Beiträge von smutbert

    lirc kann das wahrscheinlich eher nicht (damit kenne ich mich aber nicht aus). Grundsätzlich kann so etwas funktionieren. Denon verwendet z.B. bei der F109 und wahrscheinlich auch bei den Receivern eine serielle Schnittstelle in Form einer 3½mm Klinkenbuchse. Hier ist ein Projekt mit einem Programm, mit dem man problemlos die Fernbedienungssignale empfangen und auswerte kann:
    http://kfigiela.github.io/2014/06/15/denon-remote-connector/
    Die andere Richtung, also das Senden von Fernbedienungssignalen ist offensichtlich etwas schwieriger, weil Denon 5V (statt 3,3V wie beim Raspberry) verwendet, aber gerade habe ich gesehen, dass derjenige von dem das Projekt stammt auch beim Senden der Befehle Fortschritte gemacht hat…

    Eigentlich habe ich angenommen, dass es bei Marantz gleich oder sehr ähnlich funktioniert, allerdings ist dafür eine RCA/Cinch-Buchse wohl nicht genug, schließlich benötigt man 3 Leitungen.

    Nach allem was ich bis jetzt so gelesen habe ist hardwaremäßiges entprellen rein prinzipiell wesentlich besser, wenn man „einen Interrupt an den Schalter hängen“ will.
    (Das ist insofern klar, als man ja nicht will dass die Routine zB 5 Mal aufgerufen wird, wenn man den Taster nur einmal betätigt)


    Damit man anders als bei einem simplen Kondensator parallel zum Schalter immer einen eindeutig definierten Zustand am GPIO-Pin hat, kann man bei Umschalttastern ein R/S-FlipFlop oder bei einfachen Tastern den Kondensator, 2 Widerstände und einen Schmitt-Trigger verwenden. Es ist zwar etwas aufwändiger zu bauen, funktioniert aber zuverlässiger und die Kosten halten sich in sehr engen Grenzen.
    Die Schaltungen findest du hier:
    http://www.mikrocontroller.net/articles/Entprellung


    Mir ist die richtige hardwaremäßige Entprellung bis jetzt übrigens auch zu aufwändig gewesen und der simple parallel geschaltete Kondensator zu windig, weshalb ich beim Abfragen einfach auf Interrupts verzichte und in Software entprelle. Auf meinem Cubietruck schaffe ich in python selbst über das sysfs trotzdem genügend Abfragen pro Sekunde für einen Taster und das bei einer CPU-Last von wenigen % (ca. 6% für 8 Taster), macht man das statt über das sysfs mit rpi.GPIO oder WiringPi kann man die Rechenlast fast schon komplett vernachlässigen.

    Code
    top


    zeigt dir eine Liste der Prozesse und überwacht deren Speicher- und CPU-Verbrauch standarmäßig nach der CPU-Last sortiert.

    Code
    free -m


    zeigt nur den Speicherverbrauch.

    Eine (lange) Liste der installierten Pakete erhältst du mit

    Code
    dpkg -l

    Interessanter ist es da schon zu wissen, was so alles an Diensten und Skripten beim Systemstart gestartet wird bzw. werden könnte, das siehst du in /etc/init.d

    Code
    ls /etc/init.d/


    Vieles davon brauchst du und darft es nicht so ohne weiteres deinstallieren, aber zumindest ist es ein weiterer Anhaltspunkt.

    Hallo allerseits,


    zwar habe ich das folgende mit einem Cubietruck und nicht mit einem Raspberry Pi gemacht, aber weil hier mehr Leute reinschauen und ich eigentlich vor keinem hardwarespezifisches Problem stehe, erlaube ich mir einfach hier ein Thema aufzumachen.

    Ich habe an die GPIO Pins ein paar Taster und LEDs angeschlossen und ein Skript mit einer Endlosschleife geschrieben, das über das sysfs die Taster abfragt und die LEDs steuert, damit ich einen mpd zumindest rudimentär am Gerät selbst bedienen kann, was zwar nicht sehr elegant ist und dank sysfs sehr viel Rechenleistung verbraucht, aber zumindest zuverlässig funktioniert.
    Jetzt will ich aber etwas mehr und steuere zusätzlich über I²C ein Display an und werte außerdem 2 Drehimpulsgeber aus.

    Dank eines Ports von WiringPi auf den Cubietruck kann ich mit einem von den Hardwarechecks befreiten py-gaugette Drehimpulsgeber auslesen. Also habe ich mir basierend darauf meine eigenen Workerthreads gebastelt, die nur die ganze Zeit Taster und Drehimpulsgeber abfrage und mit Callbackfunktionen etwas im Hauptprogramm auslösen sollen und genau dabei stoße ich immer wieder auf Probleme.
    In das python-Forum, in dem auch schon einen Thread eröffnet habe, traue ich mich vorläufig noch nicht wieder, weil ich das Gefühl habe zu weit daneben zu stehen um dort sinnvolle Fragen stellen zu können.

    Also poste ich einmal mein Testprogramm, das schon nicht richtig funktioniert.

    Ich hoffe es ist einigermaßen klar, was das passieren soll:

    • der erste Drehimpulsgeber encoder_a soll nur die Meldungen "rotate-" und "rotate+" ausgeben, wenn daran gedreht wird und das funktioniert auch soweit.
    • der zweite Drehimpulsgeber encoder_b soll zum nächsten oder vorigen Stück springen, was er aber nur tut, wenn man nicht zu schnell daran dreht. Hier ist mir schon so viel unklar, dass weh tut...
      Blockieren die Callbackfunktion den Workerthread oder laufen schon mehrere Callbackfunktionen paralell, wenn ich einigermaßen schnell drehe?
    • der Taster switch_a soll die Playlist leeren und funktioniert für sich gnommen einigermaßen problemlos nur in Verbindung mit
    • dem anderen Taster switch_b kommt es zu merkwürdigen Problemen. Der sollte zwischen Play/Pause umschalten und wenn die Playlist leer ist, ein zufälliges Album auswählen und zur Wiedergabeliste hinzufügen.
      Die Anweisungen stammen übrigens aus meinem ersten uneleganten Skript mit der Endlosschleife, das aber wie gesagt problemlos funktioniert hat.


    Außerdem ist beim Testen dieser für mich endgültig unerklärliche Fehler aufgetreten


    Kann das vielleicht (auch) daran liegen, dass ich parallel zu meinem Skript mpdlcd laufen lasse, um das Display über lcdproc anzusteuern?

    Die Workerthreads habe ich der Übersichtlichkeit wegen nicht gepostet, sie scheinen aber zu funktionieren. Wenn es für die Fehlersuche wichtig ist oder sie jemand aus anderen Gründen gerne sehen würde, poste ich sie selbstverständlich gerne - ich habe sie mir aber hautpsächlich mithilfe des verlinkten py-gaugette zusammengebastelt.

    Es wäre toll, wenn sich das jemand ansehen und mir weiterhelfen könnte... aber ich muss euch vorwarnen, in dem Fall kommen noch einige weitere Fragen auf euch (und eventuell das python-Forum) zu.


    viele Grüße,
    smutbert

    In python-mpd2 [1] gibt es MPDClient.idle([subsystems]). Ich bin python-Anfänger, aber soweit ich das verstanden habe, kann man mit dem Befehl einfach so lange warten, bis sich bei mpd irgendetwas geändert hat, zB der aktuelle Titel, und in weiterer Folge daraufhin etwas machen, zB die Displayanzeige aktualisieren. Das könnte man dann in einer Endlosschleife laufen lassen.

    Oder du machst es dir einfacher und verwendest mpdlcd [2] in Kombination mit lcdproc/LCDd [3]. Dann musst du eigentlich nur noch LCDd konfigurieren (und ihm die Ansteuerung des LCD überlassen), mpdlcd starten und fertig.

    [1] http://pythonhosted.org/python-mpd2/topics/commands.html
    [2] https://pypi.python.org/pypi/mpdlcd/0.4.0
    [3] http://lcdproc.omnipotent.net/

    Die genaue Fehlermeldung hilft bei der Fehlersuche aber enorm ;)

    Code
    # sudo alsactl store
    bash: sudo: command not found


    würde zB bedeuten, dass sudo nicht installiert ist. Wohingegen

    Code
    # sudo alsactl store
    sudo: alsactl: command not found


    heißt, dass der Befehl alsactl aus irgendeinem Grund fehlt oder unauffindbar ist.
    Oder du hast mit Copy&Paste oder durch irgend eine andere Merkwürdigkeit statt der Leerzeichen etwas anderes erwischt (wenn es tatsächlich ein Underline gewesen wäre, wäre dir das wohl aufgefallen, aber es gibt ja auch unauffälligere Zeichen):

    Code
    # sudo_alsactl_store
    bash: sudo_alsactl_store: command not found


    Wahrscheinlich musst du aber gar nichts weiter unternehmen, weil der Befehl beim Herunterfahren von Linux normalerweise automatisch ausgeführt wird. D.h. die Reglerstellungen sollte beim nächsten Start so wiederhergestellt werden wie sie zuletzt waren.

    Wo hängt der analoge Ausgang denn dran?
    (falls er am Bildschirm hängt, hättest du auf diese Weise eine Masseverbingung zwischen RPi und Bildschirm und die Soundkarte wäre sowohl über USB. wie auch den Audioausgang mit Masse verbunden und das könnte als Ursache bereits genügen)

    Statt die HDMI-Verbindung zu kappen, könntest du auch einfach testweise einen Kopfhörer an die Soundkarte anschließen. Wenn es dann immer noch auftritt muss es wirklich etwas anderes sein.


    Sonst gibt es nicht viel zum Einstellen, außer vielleicht das Stummschalten des Mikrofoneinganges, falls der direkt an den Ausgang durchgeschleift werden kann (was ich allerdings für unwahrscheinlich halte).
    alsamixer sollte direkt nach dem Starten die Wiedergaberegler anzeigen, eventuell muss man mit <F6> vorher noch die Soundblaster Play! als Gerät auswählen. Bei den Wiedergabereglern sollte dann ein analoger Eingang, so vorhanden, (Mic, Line) auf 0 stehen und/oder gemutet sein (MM statt 00 am unteren Ende des Reglers).
    (Die Einstellung der Aufnahmeregler, die man mit <F4> erreicht, sollte keine Rolle spielen.)

    Hallo allerseits,

    die verlinkten Lautsprecher sind Aktivlautsprecher, haben den Verstärker also bereits eingebaut (sonst hätten sie auch keine eigene Stromversorgung und keinen Lautstärkeregler).

    Also entweder liegt es am Lautstärkeregler des Raspberry (zB alsamixer, wobei der Raspberry tatsächlich keinen besonders „lauten“ Ausgang hat) oder die Lautsprecher sind wirklich so schwach.