Vielleicht möchtest Du einfach einen USB-zu-tty Konverter einsetzen. Dann kannst Du den Sensor auch an einem normalen (linux) PC betreiben und dort auch die Software entwickeln, wenn nötig. So ein Konverter kostet nicht die Welt (3 EURO) und ist sehr praktisch.
Jedenfalls entfällt dann das ganze Gehühnere beim PI3, die Serielle Schnittstelle freizubekommen.
Nu seid doch nicht so, dann vertauscht Ihr eben Emmitter mit Collector. Warum heissen die auch so....
Die Lösung im angesprochenen fremden Forum besagt, dass der Mensch dort das Aussteigen des 1wire Busses auf Spannungsschwankungen zurückgeführt hat, welche von störenden anderen Verbauchern herrührten.
Er hat diese Störungen durch einen paralelgeschalteten R-C-Kreis beseitigt und dann geht es auch mit dem 1wire Bus wieder zuverlässig.
Der Transistor kann eine maximale Verlustleistung ab. Wenn mehr, dann wird er heiss, fängt an zu glühen und geht kaputt.
Die Verlustleistung berechnet sich aus dem Basistrom und dem Emmitter-Strom, da beide über den Collector gehen und der mindestens eine Diode (P/N-Übergang) hat, an der Spannung abfällt. Die angaben oben besagen also, dass Du Deine Schaltung so auslegen musst, dass der Strom nicht größer werden darf als 100mA (ausser bei sehr kurzen Spitzen, da 200mA).
Welcher Spannungsabfall tatsaechlich vorliegt, ergibt sich aus den Kennlinien (Basis --> Collector und Emmitter --> Collector). Man kann eine Schaltung aber auch so auslegen (mit entsprechenden Widerstaenden), dass man etwas unabhaengiger von den eingesetzten Tranistortypen wird (und derern spezieller kennlinie). Dann muss man die Widerstaende so auslegen, wie man es auch bei LEDs machen würde, zur Strombegrenzung.
Die Spannungsangabe (45 V) ist weniger wichtig, besagt aber, dass wenn die Spannung größer würde, dass man dann den Transistor zerschiesst, allein wegen der Feldstaerke, egal wieviel Strom dabei vielleicht fliesst.
Die schwierigste Zeile fuer ein Sketch ist wohl diese:
[cite]
`echo -n $CPSTR | iconv -f ISO8859-15 -t UTF-16LE | md5sum | awk '{print substr($0,1,32)}'`
[/cite]
Den Rest des Skripts müsste man mehr oder weniger straight forward auf Sketch umsetzen können.
Hm: Routinen für MD5 gibt es auch, das ganze Stringmanipulieren kriegt man vielleicht auch hin. Ist aber ziemliches gefrickel (selbst für einen passablen Programmierer).
cool
: Du hattest das erste Hochkomma vergessen!
Den letzen Teil (2>/dev/null) kannst Du auch weglassen, wenn Du die Zeile nicht in einem Script verwendest sondern direkt aus der Kommandozeile.
Hier würde sich wirklich ein Raspberry Pi (zero) besser eignen. Diese Kommando-Orgie geht über die ssh Schicht. Also mit voller Verschlüsselung etc. Dafür brauchst Du relativ viele und große libraries. Es kann wohl gehen, ist aber umständlich.
Wäre nicht eine alternativere Möglichkeit besser: Du kannst auf dem Raspberry ja ein kleines Script starten, was dauernd auf UDP Pakete lauscht. Vom Adruino/NodeMCU/Wemos kannst Du dann einfach spezielle Pakete per UDP (unverschlüsselt) absetzen, die den Raspberry und das script erreichen, was daraufhin irgendeine Aktion auslöst.
Diese Methode ist auch in Sketch leicht zu implementieren. Es git tausend Beispiele (Arduino + UDP).
Hm. Welcher pfad auch immer...
Anstelle von 'ls -al /home/pi' musst Du natuerlich Dein Kommando einsetzen. Das ls ist ja nur ein Beispiel. Das Kommando muss in einfachen (oder doppelten) Hochkommata stehen.
Wenn dein Kommando dauerhaft laufen soll, also wenn Du es nur von remote aus starten willst, dann gibt es zwei möglichkeiten:
1. Wenn es keine Ausgabe macht, dann mit '&' hinter dem Befehl starten,
2. wenn es eine Ausgabe macht, dann kannst Du die Ausgabe entweder in ein logfile umleiten:
a) '/home/pi/meinscript.sh > logfile.log &' oder
b) das ganze in einer screen session nutzbar machen: 'screen -d -m /home/pi/meinscript.sh'
/home/pi/meinscript.sh muss dabei natürlich ausführbar sein. screen muss evtl. nachinstalliert werden. (sudo apt-get install screen)
Versuche doch mal in einem Script auf Computer A:
Damit muesste auf dem RaspberryB das Kommando ls -al /home/pi ausgeführt werden.
Wenn Du die Passwortabfrage nicht willst, dann musst Du noch den public key von Computer A in authorized_keys auf RaspberryB eintragen.
Wenn der Briefkasten aus Metall ist, dann kannst Du den Empfang dadurch verbessern, dass Du ein Loch oder einen Schlitz mit mindestens 5 cm Breite da reinschneidest. Oder eben die Klappe offenlaesst.
Das ist einfach:
Der mplayer (in der Rohversion) auch omxplayer wird Dein Freund. Allerdings wenn Du ihn dreimal öffnest und drei Videos gleichzeitig abspielst, ist der Pi (jedenfalls die älteren Versionen) möglicherweise etwas langsam. Probier ihn doch einfach mal aus!
Äh, da dein Projekt so ja noch niemand fertig hat, musst Du wohl selbst die Entscheidungen treffen, welche Teile Du verwenden willst. Es ist ja kein Bausatz. Wo Du die dann bestellst, darfst Du auch selbst aussuchen. ich würde ja nicht nur auf günstige Preise auchten, sondern auch auf Lieferung aus einer Hand, von einem Händler aus Deutschlad etc... Aber wenn Du gerne auf dem Zollamt bist, kannst Du natuerlich auch bei A* oder aus CHina bestellen. Das ist ja jedem selbst überlassen. Daran soll Dein Projekt ja nicht scheitern.
Nein, natuerlich nicht direkt am Motor, sondern am Motor-Treiber / Leistungsverstärker.
Tut denn die Hardware? Also dreht sich da was, wenn Du impulse auf dem Puls-Eingang gibst (von Hand)? Und kann auch die Richtung wechseln?
Äh, was denn für Infos noch?
Ich hatte mal so einen kleinen Universalsniffer erstellt:
Ist aber nur ein Anfang. ...
Ein kleiner USB-Speicherstick (klein meint Geometrie, nicht Speichergröße) kann recht heiss werden. Besser ist es hier, eine größere Einheit zu wählen, wenn keine anderen Gründe dagegensprechen, dann verteilt sich die Wärme besser.
Es hat wahrscheinlich nur noch niemand gemacht. Aber gehen wird es. ich dachte, Video-Wall besteht immer aus mehreren Bildschirmen, die zu einer Matrix zusammengeschaltet sind. Das waere dann schwieriger.
Ich könnte mir vorstellen, dass es recht einfach mit diesem Display hier geht:
http://makerstudio.cc/index.ph…duct_info&products_id=349
Ich glaube sogar, diese Displays haben immer auch einen SD-Kartenleser mit drauf, so dass man sogar per Arduino Bilder von dieser Karte Anzeigen lassen kann (dann aber keine Videos).
Beim raspberry gibt es (glaube ich) einen Treiber, der ein framebuffer-device aufmacht. Auf dieserm Framebuffer kann man dann leicht bitmaps darstellen und ich meine sogar, dass auch mplayer direkt auf den framebuffer abspielen kann. Und das ist dann genau, was Du benötigst.
mplayer kann dann per script gesteuert werden.
(kann auch sein, dass es mplayer2 oder omxplayer heisst, aber Achtung: Du brauchst einen mit Soft-decoder).
