remotecontrol

Gefühlt pendelt sich der Durchschnittswert bei mir jetzt ein, d.h. er geht nicht mehr weiter runter.

Was meinst Du mit konkret dem "dort" - wo? Den Master-Brick mit LED-Strip-Bricklet kannst Du per USB an den RasPi anschliessen und dann mit Java ansteuern (siehe http://www.tinkerforge.com/de/doc/Hardware/Bricklets/LED_Strip.html, dort sind am Ende Links zu der API und Beispielen). Mehr Alternativen als das LED-Strip-Bricklet bietet Tinkerforge hierfür nicht.

Mit meinst Du 5 in Reihe schalten (immer alle gleichzeitig ein) oder eine kleine LED Leiste mit 5 einzelnen LEDs betreiben? Für 5 Grüne in Reihe bräuchtest nämlich 5*1,9V, also 9,5V und die könntest Du nicht mit dem IO16 schalten. Du nimmst 3,3V Spannung oder 5V? Davon ist der Widerstand abhängig.

Wie heisst es so schön: Probieren geht über Studieren ..

You should have /usr/bin/brickd /etc/init.d/brickd and if brickd was started successfully there should be a log-file at /var/log/brickd.log You can start brickd also manually via sudo /etc/init.d/brickd start.

Ich habe bei mir z.B. ein SoundIntensity-Bricklet am laufen, welches ab einer bestimmten Lautstärke alle 40ms einen Callback wiederholen soll. Das klappt relativ gut, aber nicht mit 100% Genauigkeit. Beispiel - die erste Zahl ist jeweils eine relative Millisekunde des Callbacks, der alle 40ms kommen sollte: 10629 1271 10669 1154 10709 1337 10749 1282 10789 1177 10829 1342 10869 1285 10909 1432 10950 1403 10990 1328 11030 1433 11070 1263 11109 1136 11149 1153 11191 1097 11230 1145 11270 1350 11310 1262 11351 1048 11391 1259 11431 1310 11471 1297 11512 1228 11552 1185 11592 1087 11632 1076 11672 1057 11712 1012 11752 1363 11792 1289 11833 1308 11873 1354 11913 1178 11953 1148 Hier kannst Du sehen, dass es mal eine Millisekunde mehr oder weniger sein kann. Tendenziell kommen in 40 Sekunden bei mir keine 1000 Callbacks, sondern eher nur 999, d. h. es gehen pro Callback wohl ein paar Mikrosekunden verloren (für meine Anwendung ist das ausreichend).

Die Tinkerforge-Module haben eine maximale Genauigkeit von 1ms (bedingt durch USB Transfer). Bei Aufruf des Callbacks kann es meiner Erfahrung nach zu einer minimalen Verzögerung kommen, bis der Callback die Anwendung erreicht, d. h. ich würde aktuell nicht davon ausgehen, dass der Callback immer mit dem Timestamp der auslösenden Millisekunde an der Anwendung ankommt (da liegt eine USB-Stecke und eine Netzwerkstrecke dazwischen). Die Übertragungszeit dürfte relativ konstant sein. Kommt es Dir auf das Delta zwischen zwei Callbacks an oder die absolute Zeit in Millisekunden? Hier spielt ja auch die Genauigkeit des Zeitgebers im PC eine Rolle. Die Programmiersprache wird eher wenig Einfluss auf die Genauigkeit haben.

Ich habe die Stützen einfach mit einem T-Profil befestigt. Damit bleiben 2 Seiten der Führungsschiene ganz frei. Die Schrauben für die Stütze am T-Profil zeigen zwar in die Laufrichtung der Rolle, aber die hat dennoch ausreichend Platz. Nachtrag: meine Laufrollen sitzen oben, unten und außen. Die unteren bringe ich zuletzt an, um die Wagen zu fixieren (danach bekomme ich den ja nicht mehr ab).

Prinzipiell ginge das auch per Software auf einem Smartphone, dann brauchst Du das Encoder-Bricklet auch nicht, weil die Einstellung direkt über Smartphone oder Tablet gemacht werden kann. Allerdings wird dann wieder ein Masterbrick und WLAN-Extension fällig. In Summe eher eine Fernsteuerung, wohl nicht das was Du bauen willst.

Kannst Du das init-Skript und das jar mal posten? Das sieht so aus, als würdest Du entweder immernoch das jar "direkt" aufrufen oder das jar ist falsch gebaut. Funktioniert die Anwendung, wenn Du von Hand "java -jar /home/pi/FerienHaus.jar" startest?

Ich hatte keine Probleme damit: habe mir einen USB-Stecker hergestellt, den ich an den 5V Ausgang der Step-Down anschließen konnte und gleichzeitig den Stack an den USB-Port des Raspi gehängt. D.h. aber: den RasPi habe ich per Micro-USB versorgt, nicht per GPIO. Wenn die 5V auf GPIO "kurzgeschlossen" sind mit dem Micro-USB müsste es aufs gleiche rauskommen. Aktuell mache ich das analog mit einem Odroid U3 - auch hier keine Probleme. Hier geht das sogar noch weiter: an einem anderen USB-Port des U3 hängt ein zweiter Stack, der dann über USB mit Strom versorgt wird.

dem stimme ich völlig zu, bei mir bewegt sich das auch noch in dem Bereich.

heisst auch: den Repeat-Count mal erhöht? Ich hatte den Effekt, dass sich meine Dose nach einigen Tagen Betrieb irgendwann gar nicht mehr schalten liess, es nach einem Stack-Reset aber wieder ging. Nach Erhöhen des Repeat-Count war dieser Effekt weg. Gefühlt war der Repeat-Count grenzwertig für die Dose und evtl. hat sich das Timing im Betrieb um eine ms verschoben und dann geht nicht mehr. Für eine andere Dose derselben Baureihe reicht selbst dieser neue Repeat-Count nicht aus, um die Dose zuverlässig zu schalten wenn eine Wand dazwischen ist: mal geht's mal nicht.

Hallo Bastian, da fällt mir noch was ein: sind die Bricklets in einer gewissen Weise "kalibriert"? D.h. zwei Bricklets am gleichen Ort liefern annähernd gleiche Werte? Wenn ja kann ich mir bei Gelegenheit ja mal ein Zweites bestellen und vergleichsweise tauschen oder an einem zweiten Stack an der gleichen Stelle mal messen.

Anbei die Datei. Mit einem "grep AVG sounds.log" bekommt man schnell einen Überblick über die Durchschnittswerte, z. B. sowas: # -- 2014-10-06 06:10:27 -- MIN 1005 -- MAX 1739 -- AVG 1232.06 -- TIME 19540 -- # -- 2014-10-06 07:50:09 -- MIN 1001 -- MAX 1582 -- AVG 1212.34 -- TIME 11975 -- Wenn die Dauer des Geräusches (TIME) ca. 11,95 Sekunden oder 19,5 Sekunden (+-100ms) ist, ist das die Mühle. Andere Dauern sind andere Geräusche in ähnlicher Lautstärke, die sind nicht relevant. Ich habe Callbacks auf 40ms eingestellt, aktuell mit einem Minimum von 1000. In den normalen Zeilen steht immer die relative Zeit und danach die gelieferte Intensität von SoundIntensity-Bricklet. Viele Grüße sounds.zip

Hallo Bastian, für einen merklichen Unterschied muss das 4 bis 6 Wochen laufen. Dann kann man Tendenzen im Durchschnitt feststellen. Ich hab noch Intensity-Aufzeichnungen ab Juli. Die kann ich morgen mal posten, dann siehst Du besser, in welcher Größenordnung sich das bewegt. Viele Grüße

Hallo TF-Team, ich habe seit Ende Mai ein SoundIntensity Bricklet im Einsatz, welches ca. 30cm oberhalb meiner Kaffeemühle platziert ist, Micro nach unten, damit sich auf Dauer kein Staub absetzt (auch wenn das Ganze im Gehäuse ist). Damit zähle ich die Anzahl Mahlvorgänge. Mein Problem: die gemessene Soundintensität nimmt langsam aber kontinuierlich ab. Bei Inbetriebnahme hatte ich Werte zwischen Min 1300 und Max 2100 mit einem Durchschnitt über alle Werte von 1600-1700. Jetzt habe ich nur noch Werte zwischen 1050 und 1600 mit einem Durchschnitt über alle Werte von 1200-1300. Ich habe ein absolutes Minimum von 1000 eingestellt, Werte darumter bekomme ich gar nicht geliefert. Bei Inbetriebnahme hatte ich hier 1200 und das hatte gereicht. Ich habe immer die gleiche Kaffeesorte und auch unterschiedliche Chargen würden keinen so großen Unterschied machen. Und ich merke deutlich, dass ich meine Min/Max Werte zu Erkennung des Mahlvorganges immer wieder anpassen muss. Kann es sein, dass das Mikro im Dauerbetrieb "nachlässt" ?

alles richtig Nur bedenken: das 12V Netzteil ist dauerhaft mit 220V versorgt (die Relais schalten ja die 12V) und sollte eine geringe Leerlaufleistung haben. Einen schönen Abend noch

Willst Du die Pumpe nur ein/aus schalten oder auch die Geschwindigkeit anpassen? Ein/ausschalten geht bei der Leistung mit dem Dual-Relais oder Industrial-Quad-Relais. D.h. Du brauchst dann - Masterbrick - Dual- oder Quad-Relais-Bricklet - Bricklet-Kabel - bei Bedarf Gehäuse oder Rasterplatte für die Montage - Stromversorgung für die Pumpe Viele Grüße

Ob das Cubieboard zuverlässig 500mA am USB Port liefert kann ich nicht sagen, darum wäre ein Test mit Stepdown hilfreich. Du müsstest das Cubieboard mit einem Netzteil versorgen, was mehr als 1A bei 5V leistet. Machst Du das? Mein Problem habe ich nur durch ausreichend Abstand gelöst. Den Motor kann man zwar noch entstören, aber Abstand ist fast noch wichtiger.

Wenn immer nur 1 Relais an ist, sollte es rein rechnerisch vom Strom her passen. An welcher Art Rechner hängt der Stack? Ein Raspi liefert z.B. nicht ganz so viel Strom per USB. Hast Du eine StepDown Power Supply mit der Du mal eine andere Art der Stromversorgung testen kannst? Was schaltest Du mit den Stromstoßrelais? Und wie dicht sind die am Stack? Ich hatte/habe immer dann Reset Probleme, wenn ich irgendetwas dicht am Stack habe, was Induktionsfunken erzeugen kann, z.b. Motoren oder Spulen.

Hängen die Dual Relais am Stack der per USB versorgt wird? Wenn ja, dann hast Du evtl. ein Stromproblem: Ein Dual Relais braucht 75mA pro geschaltetem Relais, also bis zu 150mA pro Relais Bricklet wenn beide Relais geschaltet sind. Was schaltet Du über die Relais? Wie viele sind gleichzeitig ein?

Hi foley, sorry vielleicht habe ich das damals übersehen. Ein Stand des Projekts ist hier : http://www.tinkerunity.org/wiki/index.php/DE/Projekte/Wetterstation_mit_Zeitschaltuhr_und_Android_App. Allerdings ist das C++. Vom Prinzip habe ich hier eine Schleife, die alle 2 Sekunden prüft, ob was zu tun ist. Und 'etwas tun' kann eben auch Displaybeleuchtung ein oder aus sein. Ich bin die Woche unterwegs, könnte bei Bedarf nächste Woche noch eine etwas genauere Beschreibung posten. Viele Grüße

Ja, das Problem mit dem "Teile ausgehen" ist mir vertraut ..

Ich vermute, dass sich potentielle Interessenten eher etwas unter "Kameraschlitten" vorstellen können, als unter Linearführung, auch wenn Letzteres allgemeiner ist und nicht so auf eine konktrete Anwendung ausgerichtet (was eigentlich besser ist, da es die Leute nicht so in eine Richtung der Nutzung lenkt). "Objektschlitten" würde mir noch einfallen.