photron

Der periodische Callback des RTC Bricklets wäre nicht besser/genauer als jeder andere Callback. Das GPS Bricklet nutzt für die Taktung der Callbacks nicht die GPS Zeit und das RTC Bricklet würde dafür nicht die RTC Zeit benutzten. Dafür müsste in jedem Tick I2C kommuniziert werden, was nicht möglich ist. Oder willst du darauf hinaus, dass du den Date/Time Callback mit einer Periode von z.B. 1 Sekunde einstellt um dann z.B. Zeitspannen im Minutenbereich zu messen. Du also einfach jede Sekunde Prüfen kannst ob deine Minute schon rum ist. Das hat natürlich dann den Nachteil, dass du da lokal Ungenauigkeit reinbekommst, weil nicht definiert ist wann die Zeit den abgelesen wird. Für solche Kurzzeitmessungen ist meistens ein lokaler Timer am besten, fürchte ich. Jede Programmiersprache bringt dafür irgendwas mit, das für diesen Zweck besser funktionieren wird als das Real-Time Clock Bricklet. Es kommst aber auch darauf an was du machen willst. Wenn du über 100 Minuten hinweg insgesamt 100 Bilder aufnehmen willst, dann willst du möglicherweise keinen sich aufsummierenden Fehler den ein einfacher Intervalltimer hätte. Das Real-Time Clock Bricklet kommt dann zum tragen, wenn es um längere Zeiträume geht und keine andere Zeitquelle verfügbar ist. Zum Beispiel ein RED Brick oder ein Raspberry Pi ohne Internetanbindung. Beide haben keine eigene Real-Time Clock und halten ihre Zeit über den Prozessortakt. In diesen Fällen kann das Real-Time Clock Bricklet als bessere Uhr genutzt werden. Mit der möglichen set_alarm Funktion set_alarm(int8_t month, int8_t day, int8_t hour, int8_t minute, int8_t second) kannst du dir einen wiederholend Alarm für jeden Samstag um 15:36 Uhr bauen. Der nächste Samstag ist der 2. April, also den Alarm auf "2. April 15:36 Uhr" stellen set_alarm(4, 2, 15, 36, 0) Sobald der Alarm ausgelöst wurde kannst du ihn auf den folgende Samsatg, den 9. April einstellen set_alarm(4, 9, 15, 36, 0) usw.

Das was du das tun willst funktioniert auch mit Callbacks. Aber fang am besten erst mal einfach mit Gettern an: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "qG8" # Change to your UID from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_gps import BrickletGPS import time ende = 6.5 if __name__ == "__main__": ipcon = IPConnection() # Create IP connection gps = BrickletGPS(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected while True: start = 0 while start <= ende: course, speed = gps.get_motion() # speed in 1/100 km/h start = start + speed time.sleep(0.1) print("Summe", start) time.sleep(1) ipcon.disconnect() Mit ist nur nicht klar, warum du den speed aufsummieren möchtest bis die Summe 0,065 km/h erreicht hat.

Wir legen eine AG1 Batterie mit 1,55V und 20mAh (31mWh) bei. Der RTC IC auf dem Bricklet schaltet nur dann auf Batterieversorgung um, wenn wenn er nicht vom Brick versorgt wird. Der IC benötigt laut Datenblatt im Batteriemodus 1,06µW (typisch) bis 1,58µW (maximal): 31mWh / 1,06µW = 29250h (1291 Tage) 31mWh / 1,58µW = 19620h (817,5 Tage) Die Batterie sollte also mindestens für 2 Jahre ohne externe Stromversorgung reichen. Es gibt keine "Batterie Low" Abfrage, 1) weil der IC das so nicht kann und 2) weil es nicht einfach ist die Batterie zu messen ohne sie dabei auch deutlich zu entladen. Du kannst also entweder a) "Batterie Low" Abfrage haben oder b) eine deutlich längere Lebensdauer der Batterie. Wir haben uns für b) entschieden. Du kannst den Batteriehalter selbst als Lötpad verwenden, wenn es sein muss. Die Batterie sitzt recht stramm im Halter. Wenn du mit solchen Erschütterungen rechen musst, dass dir die Batterie abhanden kommt, dann ist das Abhandenkommen der Batterie nicht dein einziges Problem. In dem Fall kannst du das Bricklet z.B. auf eine Montageplatte schrauben und vor den Batteriehalter einen Bolzen setzen. Wir haben da nichts für vorgesehen, weil der Halter eben recht stramm sitzt und es das Bricklet in den allerallermeisten Fällen unnötig größer gemacht hätte. Das Real-Time Clock Bricklet ist dafür da die Zeit zu halten, wenn keinerlei andere Zeitquelle zur Verfügung steht. Zum Beispiel in einer Unterwassermessstation die Monate lang Messungen machen soll. Das System würde dann zwischen den Messungen eine Stunde schlafen und alles bis auf einen Watchdog abschalten, um Strom zu sparen. In diesem Fall hält das Real-Time Clock Bricklet die Uhrzeit, damit ich den Messungen nachher einen Timestamp zuweisen kann. Unterwasser kann ich weder DCF77 noch GPS empfangen, darüber hinaus ist DCF77 eine Deutsche Sache. Sicherlich ist das Real-Time Clock Bricklet nicht so genau wie DCF77 und GPS sein können, aber darum geht es beim Real-Time Clock Bricklet auch nicht unbedingt.

Einen Date/Time Callback nach GPS Vorbild können wir einbauen. Dessen Periode würde dann genau wie beim GPS Bricklet mit der internen Uhr des Bricks gemessen. Ein generischer Timer ist das schon schwieriger. Der IC auf dem Bricklet bietet aber eine Alarmfunktion bei der man einstellen kann zu welchem Datum und Uhrzeit sie ausgelöst werden soll: set_alarm(int8_t month, int8_t day, int8_t hour, int8_t minute, int8_t second) Das funktioniert dann nach dem Muster von cron unter Linux: set_alarm(4, 2, 20, 15, 0) Diese setzt einen Alarm für 20:15 Uhr am 2. April. Der Alarm würde dann per Callback mitgeteilt. Wäre das was? Oder was stellt ihr euch da vor?

Richtiges RS232 arbeitet mit bis zu +15V und -15V für 0 und 1. Es gibt dann noch RS232 für TTL mit 0V für 0 und +3,3V oder +5V für 1. Der MAX232 IC kann dazwischen umwandeln. Das RS232 Bricklet kann mit beidem umgehen, es hat so einen Umwandler-IC integriert. Wenn ich das richtig verstehe, dann spricht der MB7369 vereinfachtes RS232 mit +15V für 0 und 0V für 1. Die Beschreibung spricht da von Invertieren, weil RS232 +15V für 0 und -15V für 1 verwendet, RS232 für TTL 0V für 0 und +3,3V oder +5V für 1. Du solltest den MB7369 einfach an den D-Sub 9 Stecker oder die Schraubklemmen anschließen können. Du brauchst in keinem Fall einen MAX232 IC für die Verwendung mit dem RS232 Bricklet.

Die Geschwindigkeit ist in 1/100 km/h: http://www.tinkerforge.com/de/doc/Software/Bricklets/GPS_Bricklet_Python.html#BrickletGPS.get_motion Du kannst also den speed Wert nehmen, ihn durch 100 teilen und hast dann die Geschwindigkeit in km/h.

The log contains 200 USB reconnects from a Master Brick between 7:41 and 8:50 on the 2016-03-26. This is a lot. I assume you didn't not manually reconnect the Brick 200 times in one hour. This could be a USB power issue with your Raspberry Pi. In this case the Raspberry Pi USB host port is not powerful enough to supply the stack. Do you happen to have a Raspberry Pi 1? Those had USB power issue. You could try an active USB hub in between the Raspberry Pi and the stack, or use as Step-Down Power Supply to power the stack. Maybe you need to power your Raspberry Pi from a supply with a higher output current.

Okay, hier mal ein schneller Mockup mit Gimp. plot_orig.png zeigt wie es aktuelle ist. Der graue Rahmen hebt das eigentliche Plot Widget hervor. plot_mod1.png zeigt den "Clear Graph" Button ins Plot widget verschoben, um Platz zu sparen. Außerdem ist unten links die "Fixed Value Axis" Checkbox hinzugekommen. An jedem Plot ist jetzt auch Min/Max markiert. plot_mod2.png zeigt die fixe Value Achse. In diesem Modus wird die Value Achse nicht mehr automatisch skaliert, sondern über die zwei Spinboxen eingestellt. Meinungen?

Das Industrial Digital Out 4 und das IO-16 Bricklet kannst du als ein-/ausschaltbare Spannungsquellen mit geringer Leistung betrachten. Das Industrial Digital Out 4 kann bis zu 36V ausgeben, wobei du die Spannung extern einspeist. Das IO-16 Bricklet kann 3,3V oder 5V ausgeben und braucht keine externe Versorgung. Du kannst aber auch 16 externe Transistoren anschließen, die dann wiederum als Ersatz für mechanische Schalter verwenden werden können um höherer Spannungen und Ströme schalten zu können. Das IO-16 Bricklet steuert dabei die Transistoren an. Das Industrial Quad Relay Bricklet kannst du als Ersatz für mechanische Schalter verwenden und damit bis zu 30V bei 1,2A schalten. Ich nehme an die 12V Leitungen versorgen direkt die Lampen. Die Schalter dafür müssen also höhere Ströme schalten können. Du brauchst also das Äquivalent eines mechanischen Schalters, nehme ich an. Dafür ist wahrscheinlich am besten das Industrial Quad Relay Bricklet oder ein IO-16 Bricklet mit zusätzlichen Transistoren geeignet. Es hängt aber natürlich auch davon ab wie viel Ampere Strom pro Lampe geschaltet werden muss.

If Brick Viewer doesn't show an error message when you click "Connect" then the Brick Daemon is running. Have a look at /var/log/brickd.log, or attach this file to a forum post so I can have a look at it. Do the Bricks show up in the output of "lsusb" in a terminal?

In https://bugs.php.net/bug.php?id=51879 wird das Problem diskutiert. Der vorgeschlagene Patch wurde aber nicht gemerged und der Bug steht immer noch auf Assigned. Das Problem besteht also weiterhin.

Hier eine Version der PHP Bindings die die Sockets Extension verwendet, wenn vorhanden und ansonsten Stream Sockets verwendet. Stream Sockets haben einen Nachteil, die TCP_NODELAY Option wird nicht unterstütz. tinkerforge_php_bindings_2_1_8_07807acf8c78b.zip

Aus dem entpackten C# Bindings Zip brauchst du nur die Tinkerforge.dll. Wohin du die entpackst spielt keine Rolle. Die Tinkerforge.dll fügst du dann deinem SharpDevelop Projekt als Referenz hinzu. Das geht über den "Add Reference" Menupunkt im Kontextmenu des Projekts: http://wiki.kerbalspaceprogram.com/wiki/File:SharpDevelop_AddRef.png

Okay, Industrial Digial In/Out 4 und Quad Relay waren auch zu hoch.

Ja, das funktioniert. Einfach mehrere Bricks einzeln per USB anschließen und sie sind alle über den einen Port 4223 erreichbar. Warum denkst du das? Es gibt keine direkt Beziehung zwischen Port und Brick. Was hast du denn vor? Du kannst den Port 4223 ändern, das gilt dann aber für alle Bricks. Unter Windows liegt die Config Datei unter C:\Programme\Tinkerforge\Brickd\brickd.ini (Linux/Mac: /etc/brickd.conf). Dort kannst du über die Zeile listen.plain_port = 4223 den Port ändern. Du kannst dort eine Zahl zwischen 1024 und 65535 wählen. Danach brickd neustarten. Das geht am einfachsten in dem du den Rechner neustartest.

Stream Sockets waren mir noch nicht bekannt. Ich denke es spricht nichts dagegen, dass für die nächste Version der PHP Bindings entsprechend umzustellen. Ich kümmer mich drum. Danke für die Überarbeitung.

Du meinst für eine länge Historie mit mehr als 20 Sekunden auf der X-Achse? Das Real-Time Clock Bricklet haben wir nicht dabei. Das wird aber ab nächste Woche im Shop verfügbar sein. Wir haben in paar andere Prototypen dabei, z.B. das RGB LED Matrix Bricklet mit 8x8 LEDs und das CAN Bricklet.

Das Fast Image ist seit einiger Zeit deprecated, es kann gut sein, dass das aktuelle nicht mehr baubar ist. Das make-root-fs.sh Skript kopiert das ganze Modules Verzeichnis des gebauten Kernels. Das sollte auch eine neuen Modules mit kopieren. Guckst du im Image denn auch an die richtige Stelle? Oder wie stellst du fest, dass die neuen Modules fehlen?

Den Master Brick resetten wir per Reste Knopf am Brick, oder Reset Knopf im Brick Viewer. Während des Resets passieren eine Reihe von Dinge. Wir versuchen gerade herauszubekommen was genau das Problem wieder beseitigt. Wie gesagt, dauert das leider recht lange. FlyingDoc, du könntest in deinem Aufbau testen, ob es hilft, wenn der PC periodisch irgendwelche Daten an den RED Brick sendet über RS232, damit nicht nur der RED Brick durchgehend sendet. Sprich ob das Problem wirklich damit zusammenhängt, dass dauerhaft nur in eine Richtung Daten gesendet werden.

Ich dachte es wäre offensichtlich was ich beruflich mache: Ich arbeite bei Tinkerforge, daher weiß ich soviel darüber! Welches Bricklet hast du den hinzugefügt, so dass der Setup Tab wieder zu hoch ist?

Das original MQTT ist TCP/IP basiert. Es gibt mittlerweile aber auch MQTT-SN (MQTT for Sensor Networks) das für nicht-TCP/IP Netzwerke wie ZigBee gedacht ist.

Ich habe hier jetzt seit einer Weile einen Test laufen in dem das RS232 Bricklet alle 500ms eine Heizungsnachricht mit 19200 Baud 8N1 ohne Flowcontrol an meinen PC über ein FTDI Kabel sendet. Nach 6 bis 36 Stunden kommt die Heizungsnachricht nicht mehr korrekt an, sondern die einzelnen Zeichen sind teilweise durcheinander gewürfelt oder fehlen. Es kann auch sein, dass nur noch nicht-ASCII Zeichen mit Werten über 127 ankommen. Wir haben das jetzt soweit durchverfolgt, dass wir sicher sind, dass die Daten beim RS232 Chip auf dem Bricklet noch richtig ankommen, sie aber auf der RS232 Seite des Chip nicht wieder richtig herauskommen. Sprich irgendetwas veranlasst den Chip nicht richtig zu funktionieren. Eine weitere Feststellung ist, dass ein Reset des Bricks das Problem behebt. Ein bloßes Neusetzen der Konfiguration hat keinen Effekt. Es ist auch kein Problem mit der Baudrate. Wir müssen das noch weiter Debuggen, da es aber teilweise 36 Stunden dauert das Problem zu erzeugen wird sich das leider noch etwas hinziehen. Komisch ist dabei, das wir in unseren Tests während der Entwicklung des Bricklets dieses Problem nicht hatten. Wir haben dort allerdings auch ständig Daten in beide Richtungen gesendet. In euren beiden Fällen ist das Bricklet jedoch entweder nur Empfänger oder nur Sender. Möglicherweise hat das etwas mit dem Problem zu tun. vielleicht aber auch nicht, dass ist noch zu testen.

Die Problem mit dem Setup und dem RED Brick Reiter entstehen alle durch den zu hohen IMU Brick Reiter. Sobald der IMU Brick Reiter nicht mehr zu hoch ist verschwinden die anderen Probleme auch.

Ah, verstehe, das Fenster ist zu hoch. In diesem Fall liegt es am IMU Brick 2.0 Reiter. Dessen Minimalhöhe ist zu hoch. Wenn du den IMU Brick 2.0 absteckst, dann sollten auch der RED Brick Reiter wieder normal aussehen. Für den IMU Brick 2.0 Reiter kann ich das so lösen, dass die ganzen Graphen in einen Rahmen mit vertikalen Scrollbalken kommen. Dann ist das Problem behoben.

Die Screenshots sehen doch gut aus. Wo ist das Problem, was übersehe ich?