Posts by LTSmash

    Wenn ich mit dem irrecord nur meine Enter-Taste mitschreibe, bekomme ich folgende Datei:

    Der Befehl

    Code
    irw

    liefert mir bei der Enter-Taste aber folgendes Statement:

    Code
    1c 0 KEY_ENTER devinput
    1c 1 KEY_ENTER devinput
    1c 0 KEY_ENTER_UP devinput

    Somit sind das also nicht die selben Codezeilen ... Komisch ist jedoch, dass alle anderen Tasten einwandfrei funktionieren, obwohl diese aus ähnlichen Schema bestehen.

    Liebe Community,

    ich verwende OpenELEC auf einem Raspi Model B in der Version 4.2.1. Ich möchte nun den Pi an einen alten PC-Monitor anschließen und diesen so als "Smart TV" nutzen. Dazu verwende ich einen IR-Empfänger TSOP38238, welchen ich an den GPIO-Pins des Pi angeschlossen habe. Belegt werden dabei Pin 12 (Datenanschluss), Pin 6 (Masse) und Pin 1 (+3,3 V). Als IR-Fernbedienung verwende ich eine Total Control URC-2082 (s. Bild).
    180px-Fernbedienung-promo8.jpg

    Zum bisherigen Vorgehen:
    Weil ich keine passende lircd.conf im Web für meine Fernbedienung finden konnte, wollte ich die Config-Datei selbst schreiben.
    Ich logge mich via SSH auf den Pi ein und stoppe den lirc-Daemon:

    Code
    killall lircd


    Der Befehl

    Code
    irrecord --list-namespace

    liefert mir die Bezeichnungen für die Tasten der Fernbedienung.
    Mit

    Code
    irrecord /storage/.config/lircd.conf

    wird dann mit den von mir gewählten Tasten das lircd.conf geschrieben. Nach einem

    Code
    reboot

    funktioniert die Fernbedienung in der Menünavigation schon sehr gut. Wäre da nicht das Problem mit der ENTER-Taste! Diese will nicht. Sprich ich kann die "Pfeiltasten" der Fernbedienung nutzen, jedoch keinen einzelnen Menüpunkt per Enter betreten.
    Für die Tastenbezeichnung verwendete ich den Begriff "KEY_ENTER" aus der beschriebenen Liste der Tastenbezeichnungen.

    Ich habe das Prozedere nun mehrmals gemacht und leider keinen Erfolg gehabt.
    Hat jemand eine Idee, was ich noch machen könnte???

    Okay. Vielen Dank schon mal dreamshader und meigrafd !

    Ich habe nun den "install"-Bereich des makefiles wie folgt abgeändert:

    Code
    install:	$(TARGET) $(TARGETDIR)
    	cp $(TARGET) $(TARGETDIR)

    Die Datei "piusvmonitor" kopiere ich mit dem Befehl:

    Code
    cp piusvmonitor /usr/local/bin

    Bekomme nun folgendes Feedback:

    ab4d4f7aa4.png

    Mich macht die Aussage "Warnung: Mit der Uhr stimmt etwas nicht." noch stutzig. Was könnte das noch sein? Jemand eine Idee?
    Nach einem reboot funktioniert leider die Software nicht. Also Strom an der USV geht weg, der Betrieb wird über eine Batterie gehalten, der Pi fährt aber nicht runter, wie er nach der Software eigentlich sollte. Muss ich noch irgendwelche Dateien in den "Autorun" bringen?

    Die Datei "piusvmonitor" habe ich übrigens wie in der README beschrieben mit

    Code
    chmod +x piusvmonitor

    ausführbar gemacht. An dem sollte es nicht liegen...

    Des Weiteren ist mir aufgefallen, dass wenn ich die primäre Stromversorgung an der USV abklemme, erscheint folgende Grafik in der rechten, oberen Ecke des Terminals im Ausgabebildschirm, welcher über HDMI angeschlossen ist:
    c2161956c7.jpg

    Wenn ich das Kabel wieder anstecke, verschwindet die Grafik wieder. Weiß jemand, was das zu bedeuten hat? :s


    Ich vermute mal, Du hast den Code per copy/paste genommen - kann das sein?

    Richtig. Passt. ich hab die Leerzeichen gegen Tabzeichen getauscht. Hat alles funktioniert. :thumbs1:

    Zu folgendem noch eine Frage dreamshader:

    Nach dem make Befehl legt er mir 5 Dateien mit der Endung ".o" an (Bsp.: cconfigreader.o) und eine mit dem Namen "piusvmonitor". Diese befinden sich ja noch im temp-Verzeichnis.
    Wenn ich dann nach deinem How-To den Befehl

    Code
    make install


    ausführe, bekomme ich folgende Fehlermeldung:

    f81c52ca0e.png

    Ich denke er kann das Verzeichnis noch nicht erstellen oder? Ich wusste nun auch nicht, was ich in deinem Makefile nun ändern sollte ...

    Quote from dreamshader


    Persönlich würde ich das binary nach /usr/local/bin kopieren ...

    Meinst du damit das file mit dem Namen "piusvmonitor"???

    Hallo Andreas,

    das klingt ja super! Mir geht es oft so, dass ich ein Tutorial ausprobiere und dann gewisse Schritte dann nicht funktionieren und ich dann evtl. andere Tutorials ausprobieren muss etc. So musste ich mir oft eigene "Anleitungen" aus mehreren Fremdaneitungen erstellen.

    Wäre super, wenn du dein Tutorial hier im Beitrag irgendwie verlinken oder veröffentlichen könntest. Wäre das möglich?

    Grüße
    LTSmash

    Eine README-Datei ist dabei. Allerdings kann ich mit den Anweisungen leider wenig anfangen. Hier die Anweisungen des Herstellers:

    Quote

    0. At the moment there is no makefile, so you either write your own or link by hand.
    1. Compile the sources(with g++ for example). Take "piusvmonitor" as resultname.
    (1.1. (re)Name the binaries (your compile result from the piusvmonitor source files) "piusvmonitor", if you chose another name for your compile result).
    2. Copy your "piusvmonitor" to /usr/share/piusvmonitor/ (or whrerever your piusv-software is located) and overwrite the existing "piusvmonitor"-file.
    You can skip this step if your compileresult overrote the original piusvmonitor file.
    3. Make your "piusvmonitor" executable (chmod +x piusvmonitor).

    Hallo miteinander,

    ich habe für den Pi mir die USV von CW2 zugelegt (http://www.piusv.de/) und verwende als OS "Arch Linux". Nun möchte ich die zur USV gehörende Software auf Arch Linux betreiben. Dazu wurde mir geraten, den Source Code vom Hersteller CW2 zu nehmen und mir meine eigene Arch Linux Distribution zu kompilieren.
    Nun bin ich totaler Newbie, was Arch Linux angeht und brauche daher Hilfe, wie ich nun die Software, welche dem Anschein nach in C++ geschrieben ist auf meine Arch Linux Distribution bringen kann.
    Kennt jemand eine Art Anleitung/ Tutorial, welche mir weiterhelfen könnte? :s
    Meine Suche blieb leider bisher erfolglos. :(

    Dank im Voraus ;)
    - LTSmash

    Es handelt sich um ein 7" TFT Display AT070TN90 + Kontrollerboard.
    Ich habe es über ebay für knappe 91 € gekauft. Da scheint es einen deutschen Händler zu geben.


    Hier die ebay-Seite:
    http://www.ebay.de/itm/370923758844?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649


    Ich habe von dem Verkäufer folgende Website bekommen:
    http://pm-electronics.de/?page_id=102


    Dort sind auch Anleitungen zur Treiberinstallation und Kalibrierung.

    Was ich an dem toll finde: HDMI-Eingang, VGA-Eingang, Composite-Eingang, Bildschirmtasten und eben Touchoberfläche. Für den Preis kann man nichts sagen.

    Details zum Display gibt es hier:
    http://www.vslcd.com/Specification/at070tn90.pdf

    LG
    LTSmash

    Quote


    [font="Tahoma, Verdana, Arial, sans-serif"]welche physikalische Auflösung hat der TFT ? kannst du in der Config diese Auflösung vorgeben ?[/font]

    Laut Datenblatt hat der TFT eine Auflösung von "800 x 3(RGB) x 400". Was ich schon komisch finde, da laut dem Dektop er ja eine Auflösung von 1136x592 packt.

    Übrigens: Wenn ich ein anderes OS benutze (z.B. OpenELEC) dann ist der Bildschirm komplett ausgefüllt. Also keine Probleme mit schwarzem Rand etc.

    Hallo liebe Raspi-Gemeinde,

    ich habe einen Raspberry Pi Modell B und einen 7 Zoll LCD. Genauer gesagt einen at070tn90 mit Touchscreen.
    Jetzt habe ich das Problem, wenn ich Raspbian Wheezy nutze einen schwarzen Rand um den Desktop habe. Auch beim booten, wenn ich mich noch nicht im X-Server befinde, ist der eigentliche Bildauschnitt auf diesen Bereich beschränkt.

    Hier ein Bild:

    Der Bildschirm sollte auf diesen Bereich angepasst sein:


    Laut Raspbian habe ich eine Auflösung von 1136x592. Im Drop-Down-Menü kann ich nur automatisch noch auswählen, was keine Veränderung bewirkt.

    Weiß jemand, wie ich das ändern kann!?

    LG
    LTSmash

    Leute, vielen Dank für die nützlichen Tipps! ;)

    Ich habe nun meine Abbruch-Funktion derart abgeändert:

    Code
    def my_callback(channel):
       if GPIO.input(18) or GPIO.input(16):
          time.sleep(0.1)
          if GPIO.input(18) or GPIO.input(16): 
             print "Abbruch 2"
             GPIO.output(15, False)
             GPIO.output(11, False)
             sys.exit(0)

    Fazit: Es funktioniert! :)

    Eine Frage habe ich noch: Wenn ich nun einen zweiten Taster aufnehme, kann ich dann in meinem Programm den Event-handler mit "GPIO.add_event_detect" einfach als zweites Kriterium mit aufnehmen? Also folgendermaßen:

    Code
    GPIO.add_event_detect(18, GPIO.RISING, callback=my_callback, bouncetime=200)
    GPIO.add_event_detect(16, GPIO.RISING, callback=my_callback, bouncetime=200)


    Oder muss das anders schreiben!?

    LG
    LTSmash


    Moin,

    das kommt mir irgendwie bekannt vor. Bei meiner Steuerung für Garage und sonstiges Outdoorgedöns wird der Teil für die Garage über Interrupts gesteuert (öffnen, Endschalter oben + unten, Lichtschranke) trotz CAT5 Kabel und geschirmten Einbau haut es spätestens beim Einschalten von Leuchtstofflampen den Interrupt rein, egal welche Bouncetime.
    Ich habe dann der Einfachheit halber das ganze so gelöst, dass nach einem ausgelösten Interrupt der betreffende Pin mittels Routine abgefragt wird ob dieser nach z.b. 200 ms immer noch geschlossen ist. Also quasi die "Bouncetime extern abgefragt" bisher läuft das so fehlerfrei

    Aha... das heißt der Pi nimmt wohl irgendeinen elektromagnetischen Müll auf und verarbeitet den wohl als Input.

    Hast du für das externe Abfragen der Bouncetime eine Beispielskript in Python??? Das wäre super. ;)


    Probier mal den Eingang hardwareseitig mit einem 10kOhm Pulldown Widerstand zu bestücken.
    Unbeschaltete Eingänge am PI können jeden Zustand einnehmen.
    Betrachte mal den Status der Eingänge an einem unbeschalteten PI und du wirst sehen was ich meine.

    Das habe ich auch schon ausprobiert. Allerdings ist es nach meiner Erfahrung nicht notwendig hardwareseitig einen Pulldown Widerstand zu setzen, wenn man softwareseitig einen setzt.

    Deswegen auch folgender Terminus im Code:

    Code
    pull_up_down=GPIO.PUD_DOWN

    Nichtsdestotrotz habe ich es mal auch mit einem 10kOhm Widerstand ausprobiert. Das Ergebnis ist das selbe.
    Hier im Video, was passiert. Beim Verhalten des "Funktionsaufrufes" habe ich übrigens keine Regelmäßigkeiten feststellen können.

    [youtube]92CvfKubcYA[/youtube]
    Die beiden Fenster im Video sind ein paar Millisek. Zeitversetzt. Bitte nicht wundern.

    Hallo Forengemeinde,

    ich habe ein großes Problem bei folgendem Setting:

    Ich verwende auf einer Experimentierplatine einen 12V Gleichstrommotor, eine 12V LED und einen Taster. LED und Motor werden via 2 NPN Transistoren geschalten.
    Was ich vorhabe:
    LED und Motor sollen in einer for-Schleife ein gewisses Programm ablaufen. Währenddessen soll mir der Pi mit der "GPIO.add_event_detect - Methode" den Taster im Auge behalten und soll falls dieser betätigt wird die for-Schleife beenden und das Python-Programm beenden.
    Weil mein Motor und die LED 12 V Gleichstrom benötigen verwende ich ein externes Netzteil zur Fremdeinspeisung.

    Hier ein Foto vom Breadboard:

    Hier der Python-Programmcode:

    Nun zum eigentlichen Problem:

    Wenn ich mein Python-Programm laufen lasse, funktioniert zunächst alles einwandfrei.
    Die LED leuchtet auf, Motor läuft im vorgegebenen Zeitintervall und wenn der Taster betätigt wird, bricht die Schleife ab und das Programm wird beendet.
    Wenn ich aber zum Beispiel mit einem metallischen Gegenstand, wie einer Pinzette oder nur einem Stück Draht oder Kabel an den Minus- oder Pluspol ran gehe, bricht das Programm ab. :neutral: (Obwohl ich den Taster nicht betätigt habe, nur Kontakt mit GND oder dem Pluspol).
    Wenn ich das Programm so umschreibe, dass die Tasterstellung am Ende der for-Schleife abgefragt wird (also sequentielles Abfragen des Tasters und Programmabbruch) dann gibt es den Effekt nicht. Dann kann ich noch so oft mit einem metallischen Gegenstand an einen der beiden Pole gehen, da bricht nichts ab.
    Fazit: Ich habe dieses Phänomen nur, wenn ich die interrupt-Methode mit der Event-handler [font="Monaco, Consolas, Courier, monospace"]GPIO.add_event_detect(18, GPIO.RISING, callback=my_callback, bouncetime=200)[/font][font="Verdana"]in den Code aufnehme.[/font]
    Meine Vermutung: Ich habe das Gefühl, dass der Pi selbst auf die kleinsten Spannungsschwankungen reagiert, die ich ihm über eine Pinzette/ Kabel induziere.
    Meine Frage: Wie kann ich das Problem lösen? Gibt es eine Möglichkeit beim Pi die "Empfindlichkeit" des Inputs zu "regeln"!? :huh: Hat jemand schon mal ähnliche Erfahrungen gemacht?

    Ich hoffe ihr könnt mir da weiterhelfen!? :helpnew:

    UPDATE:
    Also ich habe die event detection raus genommen. Und siehe da: Die for-Schleife funktioniert einwandfrei!

    Das Ergebnis:
    jfkcibd45so.jpg

    Erst wenn ich mit Strg+C abbreche, endet die for-Schleife, der Motor hört auf.

    Code sieht nun so aus:

    Sobald ich wieder [font="Monaco, Consolas, Courier, monospace"]GPIO.add_event_detect(22, GPIO.RISING, callback=abortion)[/font][font="Arial"]rein nehme, selbe Geschichte, wie vorher. Auch wenn ich nur einen Taster bei der event-detection verwende. [/font]

    [font="Arial"]Gibt es eine Alternative zum GPIO.add_event_detect? Weil schließlich muss das ja die Quelle der Fehlermeldungen sein... :s [/font]