Beiträge von PInguin


    und dann gibt es noch Portextender z.B. 8x I2C PCF8574(a) für je 8 Taster oder als out also 64 (8x8) Ports, der MCP kann mehr I2C, SPI bis zu 16 Ports muss man mal ausrechnen.

    Das klingt gut, denn das hätte auf alle Fälle den Vorteil, daß mir noch GPIO-Kontakte für später übrigbleiben, wenn ich noch mehr basteln will. Dann muss ich jetzt nur noch nach Anschlussbeispiele bzw Anleitungen für diesen Extender Ausschau halten. Falls Du einen Link hast: Danke! :)

    Was ich so ganz spontan nicht verstehe: wieso kann das Ding als Eingang nur 8 Taster, aber als Ausgang 64 Schalter? Ist das ein digitaler Ausgang, an dem ein Binärwert von 1 bis 64 angelegt wird, oder hat der wirklich 64 Anschlüsse, an denen ich direkt Relais oder LED anschließen kann?

    Du meinst also, es wäre besser, wenn die Pins immer "high" wären, und nur durch die Taster auf "low" gesetzt werden? Warum wäre das besser?

    Und noch eine Frage: es gibt laut Schaltplan 12 Pins mit der Bezeichnung "GPIO-0" bis "GPIO-11", die für solche Zwecke beliebig für das Auslesen von Tasters und/oder das Setzen von Schaltern benutzt werden können. Wenn ich für diese Zwecke mehr als 12 Anschlüsse benötige, gibt es dann noch einen anderen Weg als so einen "Expander" wie weiter oben beschrieben? Was ist mit den restlichen Pins, die nicht V+ oder GND sind, können davon welche verfügbar gemacht werden, wenn ich z.B. keine serielle Schnittstelle benötige?

    Ich brauch 15 Anschlüsse, die ich beliebig "betasten" und beschalten kann. Es fehlen mir also 3 Anschlüsse. Woher kann ich die bekommen?

    wo willst du genau Dioden hinsetzen?

    Ich dachte an Dioden zur Vermeidung der Verbindung der einzelnen GPIO-Pins. Wie auf dem Schaltplan ersichtlich, ist jeder Pin mit jedem anderen über 2xR verbunden. Aber das geht anscheinend, das ist in jedem Schaltplan, den ich im Netz gefunden habe und der mehr als 1 Taste beinhaltet, genau so.

    Moin!

    Ich habe auch eine Frage bzgl mehrerer Taster. Ich möchte gerne 4 Taster anschließen, und nach dem, was ich bisher gelesen habe, sollte man die GPIO-Anschlüsse mit Widerständen auf Masse ziehen, um einen definierten Pegel von Null zu erhalten. Also würde das nach meiner Logik auf die Schaltung unten hinauslaufen. Die Widerstände sollen 27kOhm betragen.

    Dabei sind aber die einzelnen GPIO-Anschlüsse jeweils über zwei Widerstände miteinander verbunden. Müssen da noch Dioden zwischen die einzelnen Anschlüsse?

    Hi!

    Ich bin gerade über diese Bastelanleitung gestolpert. Einen dritten USB-Anschluss könnte ich an meinem Pi auch gebrauchen. Ich habe den Pi zusammen mit einem aktiven USB-Hub in ein altes Router-Gehäuse eingebaut. Das Problem dabei ist, daß ein USB-Anschluss des Pi verloren geht, weil der mit den Hub verbunden ist. Außerdem sieht das echt doof aus, wenn ein Kabel von außen wieder im Gehäuse verschwindet.

    Wenn ich den Hub direkt an den USB-Kontroller anlöten könnte, würde mich das echt helfen. Reicht es bei einem aktiven Hub, wenn ich die beiden Datenleitungen verbinde, oder muss dabei auch die Spannungsversorgung angeschlossen werden?

    Mir ist schon bewusst, daß der Pi und seine Verwandten als Experimentierplattformen und nicht als "Dauerläufer" konzipiert sind. Es ist aber auch nicht von der Hand zu weisen, daß sich diese Minirechner mit ein paar Einschränkungen in Sachen Leistung durchaus als sehr preiswerte Server für Dienste wie eben OwnCloud zum Synchronisieren von Terminen und Kontakten eignen. Es gibt zwar NAS-Modelle, auf denen auch Dienste wie OwnCloud laufen können, aber ich glaube, in Sachen Energieverbrauch schneidet diese Geräteklasse um Zehnerpotenzen schlechter ab als ein Pi.

    Ich kann sehr gut damit leben, daß Thunderbird per CalDAV ein paar Sekunden braucht, um einen Termin zu verschieben, denn ich erkaufe mir diese Wartezeit mit der Gewissheit, daß *meine* Daten in *meiner* Hand bleiben und nicht auf Umwegen auf einem Server der NSA landen. Und ich bezweifle, daß es sehr viel schneller ginge, wenn ich für meine OwnCloud-Instanz im Internet einen Server anmieten würde. Aus dem Internet, also z.B. von meinem Androiden aus, wenn ich unterwegs bin, dauert es zwar mitunter bis zu 30 Sekunden, bis ein Kalender *komplett* synchronisiert ist, aber das geht automatisch, während das Telefon in der Tasche ist. Das stört mich also nicht. Das Hochschieben neu eingetragener Termine geht dagegen in weniger als 5 Sekunden.

    Alles in allem bin ich mit der Leistung, die ich für die paar Euro bekomme, sehr zufrieden. Ich weiß, daß ich für mehr Geld auch mehr Leistung bekäme, aber mal ehrlich: warum sollen 8 Prozessorkerne und 4 Gigabyte Speicher in irgend einem Rechenzentrum ein eigenes Kraftwerk auslasten, nur um mit der Verwaltung meiner Terminkalender gelangweilt zu werden? ;)

    Nichtsdestotrotz habe ich aber auch durchaus den Ehrgeiz, zu versuchen, das Optimum aus "diesen paar Euros" und dieser Experimentier-Plattform namens Raspberry herauszuholen. Das Problem bei einem Dauerbetrieb ist auch nicht der Pi selber, sondern die verwendeten Datenspeicher, die nicht für dauerhafte und permanente Schreibvorgänge ausgelegt sind. Der Pi könnte wohl Jahrhunderte laufen, ohne einem Fehler zu erliegen, wenn er einen ebenso dauerhaften Datenträger benutzen könnte.

    Es gab früher, als Compaq-Flash-Karten noch häufig im Gebrauch waren, eine Mikrofestplatte in Form einer solchen CF-Karte. Schade, daß es keine Festplatte in Form einer SD-Karte gibt.


    Der BananaPi hat zwar einen SATA Anschluss, allerdings ist das dort ähnlich wie beim Raspberry: Netzwerk sowie USB wird zum SoC über zwei USB 2.0 Lanes angebunden. Also müssen sich sowohl Netzwerk als auch USB die Bandbreite teilen. Es ist also auch bei weitem kein vollwertiger Gbit Port.

    Gut zu wissen!

    Die nächste Frage ist jetzt etwas vom eigentlichen Thema weg, daher reicht auch eine kurze Antwort und vielleicht ein Link: gibt es überhaupt Minirechner in dieser Preis-, Leistungs- und vor allem Energieverbrauchsklasse, die einen *echten* SATA-Anschluss haben?

    Danke für die ausführliche Antwort.


    ...Noch Fragen? :D

    Ja. :)

    Ich frage mal konkreter: profitiert OwnCloud auf einem Pi mehr davon, wenn (Achtung: Wortspiel!) "alles auf eine Karte gesetzt wird", also Betriebssystem und Daten auf einer SD-Karte liegen, oder wenn das System auf SD-Karte liegt, während OwnCloud seine Daten auf einem USB-Stecker lagert?

    Ich habe einige Versuche mit beiden Konstellationen durchgeführt, und mit bloßem Blick auf die Systemuhr habe ich bei Variante A (wie "alles auf eine Karte") einen leichten Geschwindigkeitsvorteil beim Aufbau der Kalender-Seiten gemessen, wenn ich die GUI benutze. Wobei ich das aber nicht wirklich nachvollziehen kann, denn die PHP-Skripte von OwnCloud lagern immer auf der Karte unter /var/www/owncloud, und solange MySQL nicht entsprechend konfiguriert wurde (siehe weiter unten), liegen auf die Kalender-Datenbanken unter /var/lib/mysql auf der Karte. OC lagert diese Datenbanken nur aus, wenn man SQLite benutzt.

    Das Hin- und Herschieben von Dateien in und aus der Wolke wird eh durch das Netzwerk begrenzt, ist also nicht wirklich relevant. Dieser Geschwindigkeitsvorteil hält sich aber in sehr engen Grenzen, und ich muss gestehen, daß ich weder eine richtige Stoppuhr noch eine statistisch wirklich einwandfreie Versuchsreihe durchgeführt habe. So habe ich z.B. zwischendurch meinen Rechner nicht neu gestartet, so daß auch noch Daten im Cache stecken konnten. Dennoch habe ich den Eindruck, daß bei Betrieb mit nur der SD-Karte die Benutzung von OwnCloud etwas schneller von der Hand ging.

    Lasse ich OwnCloud nur die herauf- und heruntergeladenen Dateien auf USB-Speicher lagern, ist im direkten Vergleich zu der Variante "nur Karte" noch kein großer Unterschied in der Zugriffsgeschwindigkeit zu spüren. Sobald ich aber auch die Datenbanken von MySQL, also die Kalender-Datenbanken von OwnCloud, auf den USB-Stick verlege, dauerte das Anlegen und Verschieben von Terminen in Thunderbird wirklich spürbar und messbar länger, und OwnCloud wirkt insgesamt "zähflüssiger" in der Benutzung.

    Es geht mir bei meiner Frage aber nicht nur um die reine Zugriffsgeschwindigkeit, sondern auch um die Datensicherheit aufgrund der Lebensdauer der Speichermedien: eine SQL-Datenbank dürfte z.B. einiges mehr an Schreiboperationen verursachen, als das Herauf- und Herunterladen von Dateien in und aus der Wolke. Ich versuche, abzuwägen, ob ein schnelleres "Abnutzen" einer SD-Karte als Preis für ein paar Bruchteile von Sekunden beim Schreiben und Lesen der Daten sinnvoll ist, oder ob ein USB-Speicher oder eine SSD-Platte sich bei dieser Art der Benutzung ebenso schnell abnutzen würde wie eine SD-Karte. Auch, wenn eine rotierende Datenplatte die sicherste aller hier genannten Optionen wäre, würde ich das wegen des erhöhten Energiebedarfs nur sehr ungern realisieren. Es mögen im Jahr vielleicht nur 5 Euro mehr sein, die eine Notebookplatte verursacht, aber wenn es sich vermeiden lässt, wäre das schön. Außerdem müsse die Platte eh über einen USB-Adapter betrieben werden, würde als keinen Geschwindigkeitsvorteil bringen. Es sei denn, ich weiche auf den Banana Pi aus, der einen SATA-Anschluss hat. (Der dann hoffentlich nicht nur eine interne USB-SATA-Adaption auf der Platine darstellt!)

    Wichtig ist auf alle Fälle, daß nicht irgendwann meine Kalender- und Termin-Datenbanken zerschossen sind, weil der Datenträger das Zeitliche segnet. Ich wird zwar täglich eine Sicherung durchgeführt, sogar übers Netz auf zwei verschiedene externe Datenträger, aber den Ärger, wenn mir unterwegs ein defekter Kalender auf meinem Androiden synchronisiert wird, möchte ich mir trotzdem ersparen. Und da ich mich mit Dingen wie der "Abnutzung" von Speichermedien nur sehr oberflächlich auskenne, frage ich lieber einmal zu viel als zu wenig nach. ;)

    Ja, Du hast schon Recht, was die Sache mit der Datenmanipulation angeht. Aber nach den ersten beiden Absätzen in dem Thema, auf das Du verwiesen hast, ging es um Netzwerkprobleme. Und da das Netzwerk bei mir lief, und mein Pi außerdem eine feste IP hat und somit also auch kein DHCP-Server sich über das falsche Datum aufregen musste, schien mir das dortige Problem eine andere Ursache als meines zu haben.

    Aber was Rechner angeht, habe ich schon Pferde direkt vor der Apotheke kotzen sehen! :D

    Nun, jetzt läuft's, und somit bleibt jetzt eigentlich nur noch, den Grund für den falschen Eintrag in der Datei herauszufinden. Den kann ich mir noch nicht erklären, denn, wie gesagt, habe ich die SD-Karte zurvor kopiert, und zwar mit "dd", also Bit für Bit, und dadurch stand auch in der Kopie nachher das in der Datei, was im Original stand. Bleibt eigentlich nur ein Fehler während der Aktualisierung. Die einfachste Erklärung wäre, daß im neuen Paket "fake-hwclock" eine fehlerhafte Datei steckt und "apt" nicht nachgefragt hat, ob er die alte Datei überschreiben soll.

    Ein erster Blick auch das System sagt mir:

    Code
    dpkg -S /etc/fake-hwclock.data 
    dpkg-query: Kein Pfad gefunden, der auf Muster /etc/fake-hwclock.data passt

    Also wird die Datei /etc/fake-hwclock.data während der Installation des Paketes fake-hwclock erzeugt, sie ist nicht Teil des Paketes, und das bedeutet, in dem entsprechenden Installationsskript könnte sich durchaus ein Fehler verstecken.

    Da muss ich also noch mal tiefer einsteigen zur Ursachenforschung.

    Aber nicht heute, das Wetter ist zu schön, um das Motorrad in der Garage zu lassen. :)

    Code
    pi@raspberrypi ~ $ date && diff -s /etc/localtime /usr/share/zoneinfo/`cat /etc/timezone`
    Sa 10. Okt 22:09:25 CEST 2015
    Dateien /etc/localtime und /usr/share/zoneinfo/Europe/Berlin sind identisch.
    pi@raspberrypi ~ $

    Ich glaube, ich beginne den Mechanismus von fake-hwclock zu verstehen: beim Herunterfahren wird die Systemzeit in /etc/fake-hwclock.data gespeichert und beim Starten wird von dort die letzte bekannte Zeit geladen und dann die Uhr nachgestellt.

    In dieser Datei stand bis eben aber das Datum vom 14.10.2015. (Habe es jetzt manuell geändert). Warum und woher, ist mir allerdings ein Rätsel, denn zum einen habe ich, wie gesagt, vor dem Update auf Jessie die SD-Karte mit Wheezy kopiert, damit ich im Notfall einfach wieder ein fehlerfreie System starten kann. Also wurde auch die Datei /etc/fake-hwclock.data kopiert, und darin steht auf Wheezy ein Datum, das wesentlich näher an der Wahrheit ist. Nach ein paar Neustarts mit Jessie kann ich jetzt sehen, daß unter Jessie diese Datei nicht aktualisiert wird, es steht immer noch meine manuelle eingetragene Uhrzeit darin.

    Könnte das ein Fehler in Jessie sein? Und wenn ja: woher kam der Eintrag mit Datum vom 14.10., also 4 Tage in der Zukunft? Mein Pi benötigt jedenfalls keine 1.21 Gigawatt... ;)

    Ich habe folgendes Problem:

    Ich habe auf Jessie aktualisiert, und dabei alle Konfigurationen behalten, durch Anpassung der source-list von apt. Das hat auch geklappt, bis auf die Tatsache, daß nach jedem Start von Jessie das Datum des Pi über 4 Tage in der Zukunft liegt und ntpdate sich weigert, die Systemzeit zu stellen.

    Ich benutze unter Wheezy nicht den Dämon, sondern der Einfachhalber einen Cronjob, um die Uhr zu korrigieren:

    Code
    */73 * * * * nice /usr/sbin/ntpdate ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de  >/dev/null 2>&1

    Das kann aber nicht schuld daran sein, daß unter Jessie das Datum so sehr falsch ist. Sicherheitshalber habe ich die SD-Karte mit Wheezy zuvor kopiert, und stecke ich die Karte mit Wheezy wieder ein und starte das alte System, stimmt auch das Datum wieder. Starte ich Jessie, liegt das Datum wieder in der Zukunft, und ntpdate weigert sich, die Uhrzeit zu stellen.

    Ich habe schon nach einem Fehler gesucht, aber keinen gefunden. Hat noch jemand einen Tip für mich?


    Ich würde (wie die meisten LED Verbauer in der Industrie) ein Stück Plexiglas über den LEDs positionieren, die bis zum Gehäusedeckel reichen und dort befestigt sind.

    Daran hatte ich auch schon gedacht. Muss mal sehen, ob ich meine alte Laubsäge noch wiederfinde. Das wäre dann die Alternative zum Weihnachtsbasteln. :D


    Warum sollte man solche Infos wie Linkstatus o. Duplexmode in Echzeicht brauchen?


    Für die Power-LED muss das nicht sein, das stimmt. Ich dachte da eher an die Netzwerk-LED: leuchtet die nicht im Takt der Daten, so daß man sehen kann, ob gerade Daten fließen oder nicht?

    Wenn das nicht so ist, würde ich natürlich die externen LED über die GPIO anschließen, das ist dann natürlich wesentlich einfacher zu verdrahten.

    Das könnte man machen, dann mußt Du dir aber ein Script schreiben das die nötigen Infos im System einsammelt und die LED's ansteuert.


    Was dann aber wohl nicht in Echtzeit geht, d.h. die Informationen der externen LED wären jeweils schon hoffnungslos veraltet, wenn sie die LED erreichen. ;)

    Zitat

    Einfacher und sicherer wäre es, die einzelnen LED Stati per LWL Kabel, zum Gehäuse zu übertragen.


    Ja, eine Glasfaser wäre eine elegante Lösung, das stimmt. Aber wie bekomme ich das Ding an den LED befestigt? Und brauche ich für jede LED eine einzelne Glasfaser? Gibt es für den Pi schon irgend etwas Fertiges für diesen Zweck?

    Hallo!

    Ich möchte einen Pi in ein Gehäuse einbauen, und die 5 Status-LED (Stromversorgung, Netzwerk, etc) nach außen ans Gehäuse legen. Kann ich diese Leuchtdioden auch an der GPIO-Schnittstelle anschließen? Oder kann/muss ich dazu einfach zu jeder der 5 LED eine zweite LED mit langen Leitungen parallel anlöten?

    Hallo Leute!

    Der Herr Rudolph hat in der Folge 168 des "Computer Club 2" USB-Netzteile getestet und demonstriert sehr eindrucksvoll den Zusammenhang zwischen Ausgangsspannung und entnommene Stromstärke, sowie den Aufdrucken auf den Geräten, die häufig nichts mit der Wirklichkeit zu tun haben.

    Wer sich also immer noch wundert, daß sein Pi instabil läuft, und meint, das Problem mit einem Netzteil mit Aufdrucken wie "2A" richten zu können, wird hier eines Besseren belehrt:

    http://www.cczwei.de/index.php?id=t…e&tvissueid=191


    PInguin
    Wie machst du das mit der Maus genau?
    Hast du ein Script dazu?

    Das ist recht einfach: dazu gibt es das Programm "triggerhappy". Die Konfiguration dazu erfolgt unter /etc/triggerhappy/triggers.d/:

    Zum Anhalten erstellst Du dort z.B. die Datei "halt.conf" mit folgendem Inhalt:

    Code
    BTN_LEFT+BTN_MIDDLE     1       /usr/bin/sudo /sbin/halt

    Für einen Neustart z.B. die Datei "reboot.conf":

    Code
    BTN_RIGHT+BTN_MIDDLE    1       /usr/bin/sudo /sbin/reboot

    Wie Du an den Kommandos siehst, müssen sie mit "sudo" aufgerufen werden. Der Benutzer "pi" ist bereits in /etc/sudoers entsprechend eingetragen, daher ist es am sinnvollsten, triggerhappy mit den Rechten von pi zu starten:

    /etc/default/triggerhappy:

    Code
    DAEMON_OPTS="--user pi"


    Durch Drücken der entsprechenden Tasten führt der Dämon dann das entsprechende Kommando aus. Wichtig sind dabei zwei Dinge:

    1.
    Das "+" bedeutet nicht, daß beide Tasten exakt gleichzeitig zu drücken sind, sondern daß die zuerst angegebene Taste gedrückt und gehalten werden muss, und dann die zweite zusätzlich.

    2.
    Und das ist wirklich sehr, sehr, sehr wichtig: es gibt Raspian-Versionen, die haben modifizierte Start-Skripte, und in einem dieser Skripte wird der Start von Triggerhappy annulliert. Oder er wird nach kurzer Zeit wieder gestoppt.

    Das habe ich jetzt selber erst nach langer Korrespondenz mit einem Betroffenen erfahren. Achte also darauf, ob "/usr/sbin/thd" einige Minuten nach dem Start noch in der Prozesstabelle auftaucht, bevor Du Dich wunderst, warum nichts passiert.

    Taucht das Programm nicht auf, durchsuche das Verzeichnis /etc rekursiv nach dem Wort "triggerhappy" (bzw nach "thd") und schaue, wo er wieder gestoppt wird.

    Hallo!

    MiniDLNA ist ja klasse, wenn es um das Verbreiten von lokalen Dateien im Netzwerk geht. Aber mit Internetradio habe ich Probleme. Ich erstellt z.B. diese Datei:


    Code
    #EXTM3U
    #EXTINF:-1, WDR2
    http://wdr-mp3-m-wdr2-koeln.akacast.akamaistream.net/7/812/119456/v1/gnl.akacast.akamaistream.net/wdr-mp3-m-wdr2-koeln

    Wähle ich den Pi auf meinen PC in VLC oder einem anderen Client an, dann erkennt das Programm zwar diese Playlist, aber es wird nichts angezeigt. Stattdessen wird einfach nur eine zufällige vorhandene Datei auf dem Pi, egal ob Audio oder Video, wiedergegeben. Ist keine lokale Datei vorhanden, werden weitere Ordner angezeigt, was ich noch weniger verstehe als gar keine Reaktion.

    Die Adresse in dem Beispiel ist gültig, gebe ich sie direkt in VLC als Netzwerkadresse ein, höre ich das Radioprogramm. Daran kann es also nicht liegen.

    Hat schon jemand mit MiniDLNA erfolgreich eine entfernte Radio-Station in seinem eigenen Netz verteilt?