bernhard.graeuler

This one? https://download.tinkerforge.com/3d/bricklets/servo_v2/servo-bricklet.step

Hi, schau Dir mal das C/C++ GUI Beispiel an, die Callback Funktion für LCD_128X64_CALLBACK_GUI_BUTTON_PRESSED wird in der Doku bei den Callbacks beschrieben. Wenn Du cb_button01_pressed wie folgt deklarierst: void cb_button01_pressed(uint8_t index, bool pressed, void *user_data) { printf("Hello Button01\n"); } Müsstest Du den Button über den Parameter index auslesen können.

Hi! Ich habe die Javascript Bindings noch nicht verwendet, aber mir scheint, dass Du erstmal nichts anderes machen willst, als die im IPConnection Example Code ausgegebenen Devices in ein Array zu schreiben, und in deinem Programm darauf zu warten, dass dies Array befüllt ist. Kommst Du vielleicht weiter, wenn Du das Beispiel entsprechend erweiterst?

Ah nee, Missverständnis: Das Kabel ist lang genug (100cm shielded für ca 80cm Distanz), ich habe den Aufbau in einer Art Schaltschrank, und die Kabel waren zwischen Durchführung von oben und Anschluss am Masterbrick zu kurz (s. rote Linie auf dem angehängten Bild). Wenn man da den Stapel zu weit nach rechts schiebt rutschen die Kabel aus den Buchsen. (Auf dem Bild habe ich das schon umgebaut. Ursprünglich kamen die Kabel von noch weiter links)

Hi, ich habe gestern meinen TF Stapel seit längerem wieder in Betrieb genommen, und dort auch das alte Temperature Bricklet im Einsatz. Die Firmware hatte ich auf die Version 2.0.4 aktualisiert, und dann nach ein paar Stunden Laufzeit auch das Phänomen "Temperature Bricklet gibt -38.43°C zurück" (temperatureReached Callback). Erst nach einem Reset des Master Bricks funktionierte das System wieder. Als Ursache käme bei mir in Frage, dass das Kabel zwischen Master Brick und Temperature Bricklet ein bischen zu kurz ist, so dass zwischendurch der Stecker am Master Brick teilweise rausgerutscht ist, also schräg im Port steckte. Könnte sein, dass ich den einfach wieder zurückgedrückt, und dann keine Prüfung mehr durchgeführt habe. Ich lasse es jetzt mal so laufen, und schaue, ob das Problem noch einmal auftritt. Gruß Bernhard

Hi, die OpenHAB API Doku für das Outdoor Weather Bricklet findest Du hier: https://www.tinkerforge.com/en/doc/Software/Bricklets/OutdoorWeather_Bricklet_openHAB.html Dort gibt es im Abschnitt "Actions" auch kleine Konfigurations-Beispiele. Freundliche Grüße Bernhard

I don't own that bricklet, but there's a documentation page for it here, where a screenshot of the brick viewer already shows a Galileo tab: Yet, in the API doc for getSatelliteSystemStatus it states "Currently GPS and GLONASS are supported, Galileo is not yet supported." So the question remains valid.

Das Bricklet erkennt ein Spannungspotential, du hast aber nur ein Kabel angeschlossen. Wenn Dein Code korrekt ist sollte es genügen, den Minus-Pol vom Sensor mit dem Minus-Pol vom Bricklet-Input-0 zu verbinden.

Hi, ich habe das über das Distance US Bricklet gelöst. Musst halt schauen, ob Dir der Messbereich und die Auflösung genügen.

Stimmt. [...] Nein, das stimmt so nicht. Deshalb möchte ich das gerne zum Anlass nehmen hier ein großes Lob für die Tinkerforge-Repräsentanten (namentlich vor allem borg) loszuwerden. Jede noch so schwammig formulierte Kritik (mir lag erst gehässiges in den Fingern) wird eben nicht, wie hier von Piwo dargestellt ignoriert ("schert sowieso keinen"), sondern es gibt Rückfragen, konstruktive Vorschläge, und Hilfestellung - für Profis ganz genau so wie für Anfänger. Das wiederum ignoriert piwo unangenehm regelmäßig. Das Problem ist, so wie ich es verstehe, dass Piwo eine Eierlegende Wollmilchsau will, nach dem Motto: "Ich steck jetzt 50 TF Brick(let)s zusammen, nehme die Premium Library von Tinkerforge, schreibe noch 20 Zeilen eigenen Code, und dann tut es genau das was ich will." Das gibt's aber halt leider nicht, und deswegen wird hier herumgemault. Mein Eindruck ist, dass piwo selber nicht genau weiß was er will, aber seinen Kopf sollen sich bitteschön andere zerbrechen.

Hallo, zu den Tinkerforge Komponenten gibt es ja jeweils die Angabe, wie hoch der Stromverbrauch ist. Leider finde ich keine Informationen, welcher Verbrauch für mobiles Internet angenommen werden sollte. Konkret: Ich betreibe den RED Brick mit dem 3G USB Stick aus Eurem Angebot, über den BrickViewer konfiguriert- also "always on" sozusagen. Die Netzabdeckung ist eher schlecht, so dass ich annehme, dass die Verbindung mehrmals am Tag neu aufgebaut werden muss. So weit ich weiß, ist das noch mal extra energieaufwändig. Hat das von Euch schon mal jemand gemessen, oder kann mir dazu ein paar Zahlen nennen? Würde mich freuen. Gruß Bernhard

Hi, maybe somebody could help you, if you specify, what you actually want to achieve. Do you use the Wifi Master extension? I assume, there's a bogus in your Wifi setup. Can you tell the IP address of your Wifi router (is it 192.168.8.1?) and how you tried to connect to your TF system. Did you try to ping it through the Wifi with another Wifi client? What IP address does that client have? Do you use DHCP or static IP address assignment? Best regards Bernhard

Hi, den DFRobot Capacitive Soil Moisture Sensor DFRobot Capacitive Soil Moisture Sensor sollte man sehr einfach an das Analog In Bricklet anschließen können. Die API ist dann bis auf die unterschiedlichen Funktionsnamen fast gleich. Gruß Bernhard

Ich würde hier starten: https://wiki.libsdl.org/SDL_CreateWindow

Hallo, es gibt für relativ günstiges Geld DCF-77 Empfängermodule (dies z. B.). Laut Datenblatt benötigt es eine Betriebsspannung von 3V, und liefert die Signale dann mit diesen 3V/5µA am DATA Port. Ich stelle mir vor, das Analog In Bricklet zu verwenden, einen VoltageCallbackThreshold Listener für 'o', min 1V max 2V zu registrieren. Die Analog In Bricklets (2.0 vs 3.0) scheinen sich nur im Stromverbrauch und in der API zu unterscheiden: 30mW / 70 mW, und Moving Average vs Oversampling plus Calibration und Details beim Listener. Fragen: Habe ich bei den Unterschieden zwischen v2 und v3 Bricklet was übersehen? Könnte dies über das Analog In Bricklet betreiben und wie beschrieben die Signalflanken auslesen? DCF-77 codiert Uhrzeit + Datum über den Verlauf einer Minute, so dass keine hohe Daten/Abtastrate notwendig ist. Das wirkt auf mich alles recht einfach, übersehe ich etwas? Freue mich über Rückmeldungen. Danke und Gruß Bernhard

Hi, Es wäre natürlich komfortabel, wenn der brickviewer die Möglichkeit böte, die URL zum Download in die Zwischenablage zu kopieren, oder gleich direkt herunterzuladen. Das ist aber gar nicht so leicht zu realisieren, weil die URL zum Download der nächsten Version zum Zeitpunkt des Releases der aktuellen Version noch nicht immer bekannt ist. Änderungen in der URL können auch den folgenden Kurzlink zerstören: https://tinyurl.com/brickv Den könntest Du Dir merken. Achtung: bei wget musst Du dann mit -O noch den gewünschten Dateinamen angeben, weil der aus dem letzten Teil der URL gebaut wird. Also: wget https://tinyurl.com/brickv -O brickv.deb Gruß Bernhard

http://download.tinkerforge.com/tools/brickv/linux/ http://download.tinkerforge.com/tools/brickv/linux/brickv_linux_latest.deb Cheers!

Hi, to me it does not seem clear, what you mean with "sampling frequency of the master brick". If you want to frequently read the measured weight of the load cell you should call setWeightCallbackPeriod(period_in_ms long) of the load cell API. Maybe take a look at the MATLAB example to see how it's done. The IR distance API works similarly. Hope that helps... Regards Bernhard

Hallo, handelt es sich um Stückpreise? Konkret z. B. die Chibi Extensions... Gruß Bernhard

Achtung, das kann auch für China Export stehen: http://www.tomshardware.de/ErP-Netzteil-Mainboard,testberichte-240732-3.html Kann man auf den Bildern nicht zweifelsfrei erkennen, finde ich. In den Begleitdokumenten steht auf den ersten Blick jedenfalls nichts dazu.

Hallo, ich habe hier einen mit Solarstrom betriebenen RED Brick Stapel. Der RED Brick steckt auf einem Step-Down Power Supply, welches über einen Laderegler versorgt wird. Nun kommt es dazu, dass die Akkus leerlaufen, weil die Sonne nicht genug scheint. Ich hatte erwartet, dass das System automatisch wieder hochfahren müsste, wenn wieder genug Energie zur Verfügung steht. Leider scheint das nicht so zu sein. Wenn der RED Brick mangels Stromversorgung einmal ausgegangen ist startet er nicht mehr von alleine, auch wenn die Akkus wieder voll sind. Wenn ich die Stromversorgung vom Step-Down Power Supply trenne, und wieder anschließe startet der RED Brick sofort. Was würdet Ihr mir raten? Gruß Bernhard

Hi, this was recently discussed on the german board as well. Please let me try to translate borgs statement from there:

Hi, Die Software wird vom RED Brick ausgeführt, verbindet sich mit dem lokalen BrickDaemon, und kommuniziert mit den einzelnen Komponenten des Stacks. Eine Ethernet Master Extension erweitert einen Master Brick. Also muss die Software mit dem Master Brick kommunizieren, und diesen via isEthernetPresent() fragen, ob eine Ethernet Extension zur Verfügung steht. Dann kann mit BrickMaster::get/setEthernetConfiguration() gearbeitet werden. Die API des RED Bricks brauchst Du dafür nicht. Gruß Bernhard

Hi, Du stellst Dir gleich zweimal ein Bein: Du verwendest den Callback der IMU als Scheduler für Deine Anwendung. Statt die Werte, die die IMU im Callback schon liefert rufst Du sie lieber noch mal neu ab. (short[] acceleration im Callback vs. imu.getLinearAcceleration() in output(...)) Ich würde (für quick & dirty) empfehlen die Werte, die Du im AllDataListener::allData([viele Arrays]) bekommst, in ein ImuData POJO zu verpacken in output(imudata, accel, gps) zu übergeben, und noch zusätzlich die anderen Brick(let)s abzurufen. Eine gute Lösung wäre meiner Meinung nach, für alle benötigten Datenquellen periodic Callback Listener zu registrieren, damit die Werte periodisch schicken zu lassen und in einer ConcurrentHashMap zu speichern. In einem separaten Task kannst Du die Werte dann periodisch aus der Map lesen und ausgeben. Wenn es unbedingt Polling sein soll, verwende besser einen ScheduledTaskExecutor. Dann ersparst Du dem Datenbus wenigstens die Last, Dir alle IMU Werte doppelt zu schicken (1x Callback + 1x getNNN() im Output). Freundliche Grüße Bernhard

Wasserdurchflusssensoren kann man fertig kaufen. Kann aber mangels Erfahrung keinen empfehlen. Scheinen häufig Impulsgeber zu sein. Sprich, man bekommt Spannungsimpulse, deren Frequenz von der Durchflussmenge abhängt. Die Impulse kann man z. B. mit dem Edge Counter vom Industrial Digital In Bricklet zählen lassen (1 x pro Sekunde abfragen und Menge der Impulse in Liter pro Sekunde umrechnen). Oder über eine kleines Elektro-Bastelprojekt (Kondensator + Widerstand / F/U-Wandler IC) in eine Spannung umwandeln, und die dann Analog In Bricklet periodisch abfragen und in Liter pro Sekunde umrechnen. Der Leitwert in Siemens ist der Kehrwert des elektrischen Widerstandes. Jetzt hängt es von der Aussagekraft ab, die man erreichen will. Man _könnte_ einfach zwei Elektroden ins Wasser tauchen, eine Spannung anlegen, die Stromstärke messen, den Kehrwert des Widerstand berechnen und fertig. Da die Leitfähigkeit des Wassers aber auch von der Temperatur abhängt, sollte diese in die Bewertung mit einfließen. Also: eine Kombination aus Thermocouple und Voltage/Current Bricklet. Für die Überwachung der Spannungsversorgung würde ich das ganze System (die Überwachung, und wenn möglich/nötig gleich auch alle Aquarien) an eine USV hängen. Viele von denen bieten die Möglichkeit einen Ausfall der Spannungsversorgung via USB oder RS232 zu melden. Dann hängt es von der Art der Internetverbindung ab, also ob die auch vom Stromausfall betroffen ist, wie man den Alarm schickt. Für wirklich kritische Monitorings wird der Alarm übrigens besser dann ausgelöst, wenn sie sich nicht mehr regelmäßig melden. Deine Software könnte also z. B. via cron Job regelmäßig einen HTTP Request auslösen. Ein unabhängiges System (z. B. Skript bei irgendeinem Billighoster) kann Dich dann alarmieren, wenn die Meldung auffällig lange ausgeblieben ist. Ich würde mal aus dem Bauch heraus schätzen, dass ein Red Brick die Daten der 16 Aquarien gut verarbeiten kann, wenn Deine Software schonend mit seinen Ressourcen umgeht. Pro Aquarium würde ich dann einen Sensor-Block (Step-Down Power + Master + WIFI/RS485 + Bricklets) zusammenstellen, und die dann an den Red Brick - Block (Power + RED + Master + WIFI/RS485) anbinden. Großes Projekt, dass Du Dir da vorgenommen hast. Respekt! Komponentenzusammenstellung, Design, Programmierung, Kalibrierung, Setup, Fehlersuche... Für sowas würde ich (auch) gerne bezahlt werden Viel Erfolg!