m0d

Hallo TF-Team,

gibt es hier mittlerweile Möglichkeiten - ggf. auch mit dem Outdoor-Weather Bricklet?

Danke!

--m0d

Sofern die Verbindung via Ethernet auf den RasPi funktioniet, kannst Du die Kommunikation zwischen dem lokal installierten brickv und dem brickd auf dem RasPi via SSH tunneln.

Der Aufruf sieht z.B. so aus

ssh user@raspberry -L4223:raspberry:4223

Anschliessend kannst Du im brickv als Host einfach "localhost" angeben. Auch Putty unterstuetzt das Tunneln.

Kann es sein, dass der Pfad so aussehen muss:

"/home/tf/programs/TestMail/bin/Testdatei.txt"

anstatt:

"/home/tf/programs/TestMail/bin\Testdatei.txt"

Hallo TF-Team,

bei Verwendung mehrerer IPConnections wäre es hilfreich, wenn Host- und Port-Properties die beim Aufruf von

public void Connect(String host, int port)

gesetzt werden auch wieder abgefragt werden können.

Gibt es hier einen Grund, warum diese (zumindest bei den C#-Bindings) nicht abrufbar sind?

Hallo Josh,

ist der Stepper im Brick-Viewer nicht sichtbar, wenn Du Dich per USB auf den Master verbindest?

Siehe hier: https://www.tinkerforge.com/de/doc/Hardware/Bricks/Stepper_Brick.html#beschreibung

Der Stepper Brick kann mit anderen Bricks in einem Stapel genutzt werden. Zum Beispiel kann ein zusätzlicher Master Brick mit Master Extensions genutzt werden, um die USB Verbindung durch andere kabelgebundene Schnittstellen (RS485, Ethernet) oder drahtlose Schnittstellen (WLAN) zu ersetzen

--mod

Hallo zusammen,

um den Füllstand in einem Pumpensumpf zu ermitteln war meine erste Idee dies mit dem Distance US Bricklet zu realisieren. Leider schwanken hier die Ergebnisse zu stark. Der Pumpfensumpf ist nicht besonder tief (ca. 30 cm) und ich würde gerne genauere Messwerte erhalten.

Ein weiterer Versuch mit dem Multi Touch Bricklet sieht recht vielversprechend aus. Bei Wasserkontakt mit einer Elektrode wird hier der Touchzustand korrekt ermittelt.

Folgende Fragen habe ich zu diesem Ansatz der Füllstandsmessung:

• Nutzt noch jm. das Multitouch Bricklet zur Füllstandsmessung und wie sind ggf. die Erfahrungswerte?
  
• Besteht eine Möglichkeit nicht nur Bit-Werte vom Bricklet abzufragen (also Berührung Ja/Nein) sondern auch Näherungswerte pro Elektrode zu erhalten?
  
• Besteht eine Möglichkeit mehr als 12/13 Pegelstände mit einem Bricklet zu messen?
  

Grüße und besten Dank

m0d

Meiner Meinung nach liegt das Problem an der Verwendung von C++/CLI. Mono bietet meines Wissens nach keine Unterstützung für C++/CLI.

--m0d

Hatte meine Installation auch auf einem Raspberry Pi laufen.

Solange es noch kein GSM-Bricklet gitb, könntest Du Dir z.B. mit einem GSM USB-Stick behelfen. Ich habe einen alten UMTS USB-Stick verwendet, um damit unter Linux mit Hilfe der SMS Server Tools [1] Nachrichten zu versenden. Soweit ich mich erinnern kann, kannst Du auch auf eingehende Nachrichten reagieren.

Hoffe das hilft Dir weiter.

--mod

[1] http://smstools3.kekekasvi.com/

Vielleicht gibt es ja mittlerweile ein paar Erfahrungswerte zum Einsatz des Dust Detector Bricklet. Antworten auf die folgenden Fragen wären für mich noch interessant:

• Spielt bei Außenmontage die Luftfeuchte bzgl. der Messergebnisse eine Rolle?
  
• Ist der Sensor geeignet auch in feuchter Umgebung zu arbeiten, oder ist hier eine schnelle Korrosion zu befürchten?
  
• Haben Temperaturschwankungen Auswirkungen auf das Messergebnis (lt. Datenblatt liegt die Betriebstemp. zwischen -10 °C und +65 °C?
  
• Würde sich die Montage in einem umgedrehten "J"-Rohr mit Ventilator anbieten?
  

--m0d

Schau mal hier:

http://www.tinkerunity.org/forum/index.php/topic,3174.msg19663.html

Nur über USB ist mittels Brick Viewer (brickv) möglich.

Vielen Dank für die Empfehlung. Heute ist der Sensor von sensorshop24 angekommen. Erste Messungen liefern nahezu identische Ergebnisse mit dem Temperature Bricklet !

--m0d

Besten Dank, die Sensoren machen einen soliden Eindruck!

Aktuell habe ich einen PT100 3-Draht Sensor getestet. Ein Datenblatt/ Spezifikation dazu ist nicht vorhanden. Leider habe ich Temperaturabweichungen von 4-10 °C von der tatsächlichen Temperatur. Kann mir jm. einen Sensor empfehlen, der im Bereich zwischen +20 °C und 120 °C in Flüssigkeiten korrekte Ergebnisse liefert?

Vielen Dank schon einmal!

--m0d

Habe soeben einen Test auf dem Red-Brick durchgeführt und konnte den Code [1] erfolgreich ausführen. Keine Fehlermeldung bzgl. iptables. Hier meine lsof -i Ausgabe:

...
java    13768   tf    7u  IPv4  22802      0t0  TCP *:10007 (LISTEN)
...

[1] Java Echo Server von:

http://www.cs.uic.edu/~troy/spring05/cs450/sockets/EchoServer.java

Du kannst Dir z.B. mit dem Befehl

netstat -tnlp 

anzeigen lassen, welcher Prozess (PID) einen bestimmten Port geöffnet hat. Du kannst auch überprüfen, ob auf dem entsprechenden Port momentan ein Dienst/Programm "lauscht".

Hallo Kristian,

wenn Du auf einem bestimmten Port Verbindungen annehmen möchtest ist meiner Meinung nach kein iptables erforderlich. Was macht das Programm denn genau?

--m0d

Du kannst Dir mit Hilfe des Programms "disk usage" den Platzbedarf auf Deinem System anzeigen lassen. Das sollte bereits erste Hinweise liefern...

du -h --max-depth=1 | sort -hr

• "-h" gibt die Werte formatiert (z.B. 2G) aus
  
• "--max-depth=1" gibt die Verzeichnistiefe 1 an
  
• "sort -hr" sortiert die Ausgabe noch
  

Danke Malik. Hat evtl. jm. Erfahrungen mit (Hutschienen-) Gehäusen von anderen Anbietern, die von den Abmessungen her für TF-Stacks geeignet sind?

@TF: Gibt es in Überlegungen auch Gehäuse für das industrielle Umfeld anzubieten? Habt ihr vielleicht Erfahrungen mit geeigneten Gehäusen?

Für den Einsatz im industriellen Umfeld suche ich nach einer Besfestigungs- / Montagelösung. Die im Shop angebotenen Trägerplatten für die Hutschienenmontage sind zwar für kleine Stapel ganz in Ordnung, bei Stapeln >3 Bricks wird die ganze Vorrichtung jedoch etwas instabil.

Auch suche ich nach einer "soliden" Lösung, den eingesetzten Stapel vor Staub und anderen äusseren Einflüssen (idealer Weise bei Hutschienemontage) zu schützen.

Wünschenswert wäre Schutzart IP54 [1], das muss aber nicht unbedingt sein.

[1] http://de.wikipedia.org/wiki/Schutzart

Unter Debian ist udev [1] für die Namensgebung der Geräte verantwortlich. Die Konfiguration erfolg dabei mittels bestimmter Regeln die unter Debian u.a. im Verzeichnis "/lib/udev/rules.d" zu finden sind. Meiner Meinung nach sollte das Verhalten jedoch bereits so sein, dass für einen Stick (mit bestimmter MAC-Adresse) ein bestimmter Schnittstellen Name (z.B. "wlan0") vergeben wird. Auf dem Red-Brick (1.6) wird bei mir Stick A "wlan0" zugeordnet und Stick B "wlan1". Auch nach einem Wechsel wird Stick A wieder "wlan0" und Stick B "wlan1" zugeordnet.

Lt. Changelog des Red-Brick kommt Debian Jessie bereits seit Image Version 1.4 zum Einsatz. Das Verhalten sollte eigentlich identisch sein...

[1] http://de.wikipedia.org/wiki/Udev

Die Idee ist, das Bricklet in den Stack zu schalten, und anschließend einen Reset durchzuführen.

Voraussetzung dafür ist allerdings, das der Schaltzustand des Relais beim Reset des Stacks nicht verloren geht. Sollte das mit dem Quad Relay nicht funktionieren, so könnte ein zusätzliches Bistabile Relais verwendet werden.

Habe gerade erst den Eintrag von Nic zum Thema Hotplug gelesen.

Vielleicht wäre es denkbar, nach dem "Zuschalten" des GPS Bricklets einen Reset des Stacks durchführen?

Du könntest theoretisch auch die Stromversorgung zum GPS Bricklet durch ein Industrial Quad Relay unterbrechen (das Industrial Quad Relay hat einen Verbrauch von 2mA pro Relais). Ob das allerdings auch praktisch möglich ist oder sonstige Quereffekte nach sich zieht kann ich Dir nicht sagen.

--m0d