
photron
Administrators-
Gesamte Inhalte
3.184 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
52
Alle erstellten Inhalte von photron
-
Scheint also wirklich der Sensor ein Problem zu haben. Wirklich ungewöhnlich, dass das gleich mit zweien zu gleichen Zeit passiert. Hast du beide Stationen schon ähnlich lange in Betrieb, sind also beide Bricklets schon ähnlich lange in Benutzung? Ich habe mal die CRC Prüfung rausgenommen im angehängten Plugin. Kannst du mal testen, was das ändert? Ich würde erwarten, dass du jetzt wieder Werte bekommst die aber stark neben der Wirklichkeit liegen, weil die Kalibrierungsdaten korrupt sind, oder auch die rohen Messwerte an sich nicht richtig ausgelesen werden können. barometer-bricklet-no-crc-check.bin
-
10 mbar, -40 °C und 0 m zeigen ein Problem mit der Kalibrierung des Sensors auf dem Barometer Bricklet an. Der Sensor ist vom Hersteller kalibriert. Diese Kalibrierung wird zusammen mit einer CRC Prüfsumme auf dem Sensor gespeichert. Das Bricklet liest beim Start die Kalibrierungsdaten samt Prüfsumme aus und kontrolliert, ob die Prüfsumme passt. Wenn sie nicht passt, dann wird dauerhaft 10 mbar, -40 °C und 0 m ausgegeben. Das kann jetzt bedeuten, dass der Sensor auf deinem Barometer Bricklet defekt ist, bzw. die Kalibrierungsdaten korrupt sind. Ist mir aber noch nicht untergekommen, wenn ich mich richtig erinnere. Es kann aber auch bedeuten, dass die I2C Kommunikation zwischen Sensor und Brick gestört ist. Da das Bricklet aber noch auftaucht, kann dessen EEPROM noch per I2C angesteuert werden. Wodurch ein generelles I2C Problem unwahrscheinlich ist. Ein paar Fragen und Vorschläge ins Blaue dazu: - Ist das Bricklet alleine am Master Brick, bzw funktioniert es wenn es alleine ist? - Haben die Stecker an Brick und Bricklet verbogene Kontakte? Auch wenn das unwahrscheinlich ist, da das EEPROM funktioniert. - Ein anderes Bricklet Kabel, anderen Port am Brick, anderen Brick testen (auch unwahrscheinlich als Ursache, aber dennoch) - Auf dem Bricklet sind auch noch alle Bauteile vorhanden? http://www.tinkerforge.com/de/doc/_images/Bricklets/bricklet_barometer_vertical_800.jpg
-
Den "richtigen" Luftdruck gibt es ja so erstmal nicht Es kommt darauf an was du tun willst. Wenn du das Barometer Bricklet für meteorologische Zwecke verwenden willst und den Luftdruck wie auf Wetterkarten üblich darstellen willst, dann ist QFF Wert das richtige für dich. Diesen hast du schon ja schon nach der barometrischen Höhenformel bestimmt. Den Referenzluftdruck benötigst du nur, wenn du das Barometer Bricklet zur Luftdruck-basierten Höhenmessung verwende willst, wie FlyingDoc schon richtig erklärt.
-
Alle Funktionen der C/C++ Bindings geben einen int zurück. Dies ist ein Fehlercode, nicht der aktuelle Zustand des Quad Relays. Siehe http://www.tinkerforge.com/de/doc/Software/Bricklets/IndustrialQuadRelay_Bricklet_C.html#api Getter geben Werte in Variablen zurück. Du übergibst industrial_quad_relay_get_value einen Pointer auf ein uint16_t Variable und dahin schreibt die Funktion dann den aktuellen Zustand des Quad Relays: uint16_t value = 0; industrial_quad_relay_get_value(&iqr, &value); printf("%u", value);
-
Brick Daemon 2.0.8 Fix dynamic loading of libudev on Linux Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X
-
Brick Daemon 2.0.8 Dynamische Laden von libudev auf Linux korrigiert Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X
-
Es sieht so aus als ob du bricklet_industrial_quad_relay.c und ip_connection.c nicht mitkompilieren würdest. Daher dann auch die Undefined Symbol Fehler.
-
Brick Daemon 2.0.7 Add OpenWrt package Makefile (thanks to bjoern-r) Debian package now works with libudev0 and libudev1 Use GetSystemTimePreciseAsFileTime() on Windows 8 for more precise log timestamps Fix race between socket select thread and USB poll thread on Windows Fix text of some USB related error messages Don't set SO_REUSEADDR for server socket on Windows Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X
-
Brick Daemon 2.0.7 Makefile für OpenWrt Package hinzugefügt (Dank an bjoern-r) Debian Package funktioniert jetzt mit libudev0 und libudev1 Auf Windows 8 wird GetSystemTimePreciseAsFileTime() für genauere Zeitangaben im Log verwendet Race zwischen dem Socket Select Thread und dem USB Poll Thread auf Windows verhindert Text einiger USB bezogener Fehlermeldungen korrigiert SO_REUSEADDR wird für den Listen Socket auf Windows nicht mehr verwendet Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X
-
[C/C++] Raspberry Pi - Programm verändern?
Thema antwortete auf photrons FloB in: Software, Programmierung und externe Tools
Der Trick mit getchar() an der Stelle ist, dass das getchar() erst returnt wenn eine Taste gedrückt wird. Wüsste spontan nicht warum das Probleme machen sollte. Was meinst du denn mit "es hat erst funktioniert" als du das geändert hast? Hat sich das Programm dann vorher einfach direkt wieder beendet, oder lief es aber die Callbacks taten nichts? Als Alternative kannst du while(1) { sleep(10); } nehmen, dann belegt dein Programm nicht mehr 100% CPU. -
NetIO-Steuerung
Thema antwortete auf photrons mccrossen in: Software, Programmierung und externe Tools
Doch, klar funktioniert das. Du brauchst halt irgendwo einen PC auf dem dem die Shell Bindings als Proxy laufen. Siehe: http://www.tinkerforge.com/de/doc/Software/NetIO_Setup.html#listen-befehl Also "tinkerforge --host meine-ethernet-extension listen" starten. Und um es mit Loetkolbens Darstellung zu sagen: [stack mit Ethernet Extension (4223)] <--- [shell Bindings (4217)] <--- [NetIO App] -
NetIO-Steuerung
Thema antwortete auf photrons mccrossen in: Software, Programmierung und externe Tools
Shell Bindings 2.0.3 mit listen Modus. Dazu hier auch eine Anleitung für NetIO: http://www.tinkerforge.com/de/doc/Software/NetIO_Setup.html -
[TCP/IP] ASCII Daemon für brickd
Thema antwortete auf photrons mth in: Software, Programmierung und externe Tools
Shell Bindings 2.0.3 mit listen Modus. Dazu hier auch eine Anleitung für NetIO: http://www.tinkerforge.com/de/doc/Software/NetIO_Setup.html Loetkolben, mir ist keine Alternative zu NetIO bekannt. Ich muss aber zugeben auch nicht aktiv danach gesucht zu haben -
Bindings: C/C++ 2.0.11, C# 2.0.11, Delphi 2.0.13, Java 2.0.12, PHP 2.0.10, Python 2.0.11, Ruby 2.0.11, Shell 2.0.3, VB.NET 2.0.7 Fix signature of edge count functions in IO-16 Bricklet API [all] Add listen mode for handling incoming commands over a TCP/IP connection [shell] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, Shell, VB.NET
-
Bindings: C/C++ 2.0.11, C# 2.0.11, Delphi 2.0.13, Java 2.0.12, PHP 2.0.10, Python 2.0.11, Ruby 2.0.11, Shell 2.0.3, VB.NET 2.0.7 Signatur der Flankenzählerfunktionen in der IO-16 Bricklet API korrigiert [alle] Listen Modus zur Behandlung eingehender Befehle über eine TCP/IP Verbindung hinzugefügt [shell] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, Shell, VB.NET
-
Das ist im Prinzip ein bekanntes Problem. Mir war bekannt, dass nach einen Host Standby auf Linux und Mac OS X Bricks an USB nicht mehr richtig kommunizieren. In beiden Fällen hilft ein Neustart des Brick Daemon oder des Bricks selbst. Ich denke im Moment, dass das Problem nicht in brickd selbst liegt. Das ein Neustart von brickd hilft liegt wahrscheinlich daran, dass dann das USB Device neu initialisiert wird durch brickd. Da brickd das Problem aber nicht erkennen kann, kann er auch nicht versuchen dies als Abhilfe zu verwenden. Neu ist, dass das Problem auch Windows betrifft. Ich kann es wie von dir beschreiben auf Windows 8 mit einem Servo Brick und auch mit einem Master Brick reproduzieren. Im Unterschied zu Linux und Mac OS X hilft hier ein Neustart von brickd nicht, sondern nur ein Reset des Bricks hilft. Es ist mir nicht klar wo das Problem genau liegt und wie es zu beheben sei
-
[Java] Problem auf Raspberry Pi mit aktuellen Bindings
Thema antwortete auf photrons Equinox in: Software, Programmierung und externe Tools
Ich hatte Java Bindings Versionen 2.0.10 und 2.0.11 unbeabsichtigter Weise mit Java 7 kompiliert, da ich für Tests Java 7 brauchte und dann nicht daran gedacht hatte meine Java Version wieder zurück auf 6 zu setzen. Ich habe gerade Versionen 2.0.10 und 2.0.11 neu mit Java 6 kompiliert und neu hoch geladen. Damit sollte das Problem behoben sein. -
generate_makefile.bat CMake Error
Thema antwortete auf photrons Monti in: Software, Programmierung und externe Tools
CMake kann make und GCC für ARM nicht finden, entweder weil du sie nicht installiert hast, oder weil sie nicht im PATH sind. Siehe folgende Anleitung dazu: http://www.tinkerforge.com/de/doc/Software/Firmwares_And_Plugins.html#compiler-und-tools-installieren -
[TCP/IP] ASCII Daemon für brickd
Thema antwortete auf photrons mth in: Software, Programmierung und externe Tools
Die Shell Bindings haben einen neuen Befehl gelernt: listen. Dieser öffnet einen TCP/IP Socket auf Port 4217 und nimmt die gleichen Befehle entgegen wie die Shell Bindings selbst auf der Kommandozeile. Hier ein Beispiel: $ tinkerforge listen $ echo "call ambient-light-bricklet f6y get-illuminance" | nc -w1 localhost 4217 illuminance=307 Angehängt eine Shell Bindings Version mit listen Befehl zum Testen. tinkerforge -
Nein. Das ganze ist so: Intern wird die Spannung jede Millisekunde gemessen und über 50 Messwerte wird dann der Mittelwert gebildet. Diesen Mittelwert kannst du dann über GetVoltage abfragen oder dir über OnVoltage mitteilen lassen. Über die Periode von OnVoltage kannst du einstellen wie häufig dir neue Werte mitgeteilt werden. Wenn sich der Mittelwert nicht ändert wird OnVoltage nicht aufgerufen. Wenn er sich ändert wird OnVoltage sofort aufgerufen. Dann aber erst frühstens wieder nach der eingestellten Periode. Wenn sich also der Mittelwert ständig ändert bekommst du alle Periode Millisekunden einen Callback. Vor Version 2.0.3 was das Averaging fest auf 50. Dass heißt, der Mittelwert wurde über 50 Messwerte bestimmt und konnte sich daher nur alle 50 msec ändern. Damit wurde dann OnVoltage auch höchstens alle 50 msec aufgerufen, selbst wenn du die Periode von OnVoltage kleiner eingestellt ist. Durch die Mittelwertbildung bedingt werden Änderungen der Spannung im Worst Case erst um Länge der Mittelwertbildung Millisekunden verzögert gemeldet. Mit Version 2.0.3 kann das Averaging jetzt zwischen 1 und 255 Werten eingestellt werden. Dadurch hast du Kontrolle darüber ob du Änderungen ohne Verzögerung haben möchtest, oder glattere Werte. Zu deinem Beispiel, bei einer Periode von 1000 Millisekunden und Averaging von 100 Werten bekommst du im Worst Case eine Spannungsänderung erst nach 1100 Millisekunden durch OnVoltage mitgeteilt. Im Best Case direkt, wenn gerade die Periode angelaufen ist und die Spannungsänderung der 99. der 100 Werte pro Mittelwert ist.
-
Question about Analog In Bricklet Specs.
Thema antwortete auf photrons blackfox in: General Discussion
That's just fine. You could use the symbol RANGE_UP_TO_3V instead of the magic value 5, but that's just a matter of taste: $range = $ai->setRange(BrickletAnalogIn::RANGE_UP_TO_3V); -
Industrial Digital In 4 Bricklet und eigenständiges zählen von Impulsen
Thema antwortete auf photrons mth in: Allgemeine Diskussionen
Hast recht, das fehlte. Ist jetzt verbessert -
Question about Analog In Bricklet Specs.
Thema antwortete auf photrons blackfox in: General Discussion
Brick Viewer doesn't know about this new range yet, but you can use your own program to set it. -
Bindings: C/C++ 2.0.10, C# 2.0.10, Delphi 2.0.12, Java 2.0.11, PHP 2.0.9, Python 2.0.10, Ruby 2.0.10, Shell 2.0.2, VB.NET 2.0.6 Add edge counters to Industrial Digital In 4, IO-4 and IO-16 Bricklet [all] Make averaging length configurable for Analog In Bricklet [all] Avoid void pointer to function pointer cast warnings with MSVC [C/C++] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, Shell, VB.NET