borg

Ich kenne i2cget nicht und mir ist nicht ganz klar was du mit 0x48 und 0x50 machst. Auf jeden Fall ändert sich die Adresse des I2C Teilnehmers nicht, solange du nicht änderst was an SEL angeschlossen ist. Was hast du denn beim Breakout Bricklet an SEL angeschlossen, GND, 3.3V, SDA oder SCL? Im Datenblatt sind die Adressen in Table 12 beschrieben: Wenn du SEL auf GND legst, möchtest du von I2C Adresse 1001000 und Register Adresse 0 zwei 8 Bit Werte auslesen. Von außen drauf geguckt sieht es so aus als würdest du je 1 Byte von I2C-Adresse 0x48 und 0x50 lesen. Das wäre nicht sinnvoll.

Für die Werte 0x18 und 0xff komme ich auch auf 24,9°C, ja: >>> ((((0x18 << | 0xff)) >> 4)/16.0 24.9375 Wobei da vermutlich irgendwas noch nicht stimmt wenn der letzte Wert immer 0xFF ist. Steigt die Temperatur denn wenn du mit dem Finger auf den Sensor packst? Ein Reset sollte auch nicht notwendig sein, ist bei der Temperature Bricklet Firmware nicht implementiert.

"<<" ist eine bitweise Verschiebung. "|" und "&" sind bitweise Oder und Und. Alle drei erklärt hier: http://de.wikipedia.org/wiki/Bitweiser_Operator Ansonsten ist nur noch eine Multiplikation und eine Division im Quellcode. Sprachunabhängig ist die Temperatur-Repräsentation im Datenblatt beschrieben, Seite 6 und 7.

Schwer zu sagen was da passiert. Hast du einen Logic Analyzer da? Mein vorgehen hier wäre jetzt die SPI-Kommunikation einmal komplett aufzunehmen, um zu gucken wo genau etwas schief geht. Optimalerweise würdest du für das Debuggen noch ein paar zusätzliche GPIO Pinne nutzen um anzuzeigen wann CAN/LIN-Bus Kommunikation beginnt/endet etc. Damit kannst du dann gucken ob es dort Überschneidungen gibt o.ä. die zu Problemen führen!

Zusammenkopiert aus dem Quellcode (ungetestet): #define TEMP_SCALE_MUL 100 #define TEMP_SCALE_DIV 16 int16_t two_complement_12_to_16(const int16_t value) { if(value & (1 << 11)) { return value | 0xF000; } return value; } uint16_t value = (first8bit << | second8bit; uint16_t result = two_complement_12_to_16(value >> 4)*TEMP_SCALE_MUL/TEMP_SCALE_DIV; In "result" sollten am Ende 100stel Grad stehen.

Die Daten sind 12 Bit im Zweierkomplement. Aber anstatt Reverse Engineering zu betreiben kannst du auch einfach bei uns in den Source Code gucken, ist doch alles Open Source: https://github.com/Tinkerforge/temperature-bricklet/blob/master/software/src/temperature.c Siehe temperature_read und two_complement_12_to_16. Oder vielleicht noch einfacher, die Datenblätter der Sensoren die wir nutzen sind immer mit im GIT: https://github.com/Tinkerforge/temperature-bricklet/blob/master/datasheets/tmp102.pdf?raw=true

Mhh, ich würde vermuten das die Pumpe einen zu hohen Anlaufstrom hat .

That seems to be a string encoding problem. I just tested it on my PC, here the strings seem to be encoded as utf-8. You probably have to enable utf-8 encoding in your php.ini: http://stackoverflow.com/questions/1605760/how-to-best-configure-php-to-handle-a-utf-8-website

If you print $temperature, is that also "null"? Your PHP seems to evaluate "Temperature: $temperature °C" as null. I am not sure why that is. Perhaps you can try to change the string bit for bit, to find what excatly the reason is!

"null" means probably that the object "null" is returned, not the integer 0. Are the PHP Bindings up to date?

You can use them in the same LAN, but that is about it .

Mh, die Konfiguration der Clock findet in bricklib/drivers/board/board_lowlevel.c in low_level_init statt: https://github.com/Tinkerforge/bricklib/blob/master/drivers/board/board_lowlevel.c Nutzt ihr einen externen oder den internen Quarz?

Wenn du die WIFI/Ethernet Extension benutzt brauchst du keinen brickd auf dem PC (sonst schon).

Klar, genauso wie eine java .jar nicht ohne eine jre lauffähig ist, oder Python nicht ohne den Python-Interpreter.

Klar, du musst halt mono installieren (was in den repos drin ist, "mono-runtime" heißt das Paket unter Debian). Genauso wie du java installieren würdest. Wie AuronX schon sagt, die Libs für C#/VB.NET die wir hier verbreiten werden unter Linux mit mono gebaut. Funktionieren aber auch einwandfrei in VS. Das nächste Starter Kit hat ein großes Beispiel welches C# benutzt (mit GUI usw) welches direkt unter Windows/Linux läuft.

Es gibt eine inkompatibilität zwischen 1.x.y und 2.x.y, weil wir da das Protokoll geändert haben (auch das was über den lokalen Socket geht). Alles was 1.x.y und alles was 2.x.y ist, ist zueinander kompatibel .

Oh, das hätte ich jetzt nicht erwartet. Gut zu wissen .

Eine mit C#/VB.NET erstellte .exe kannst du so wie sie ist unter Linux ausführen, das ist in der Tat unproblematisch und sogar besser integriert als Java. Viele Programme die in C# geschrieben sind verwenden allerdings low-level WinAPI oder DirectX oder vergleichbares. Dadurch funktionieren sie dann wieder nicht out-of-the-box unter Linux. Genauso wie ein Java-Programm welches eine "Windows only"-Library verwendet. Bei C# ist es viel üblicher WinAPI o.ä. zu verwenden als bei Java. Dadurch lassen sich viele Programme die auf der CLR laufen dann doch nicht unter Linux ausführen...

Das ist in der Tat unschön, ich schreib es mir mal auf die TODO-Liste das für die nächste Version umzubenennen. @AuronX: Objektorientierte C++-Bindings wären natürlich besser. Wir haben nur erst noch ein paar andere Sprachen die wir vorher unterstützen wollen. Die aktuellen C/C++ Bindings sind schon absolut legales C++, sie verwenden nur keine Klassen . Das ist schon ein bisschen was anderes als eine C-Lib in C# einzubinden (z.B.).

Firmwares: Servo Brick 2.0.3 Fehlende Defines für enable/disable API der "reached Callbacks" hinzugefügt Download: Servo Brick

Firmwares: Servo Brick 2.0.3 Add missing defines for enable/disable API for reached callbacks Download: Servo Brick

Ja, sonst müssten wir entweder die API duplizieren (mit allem drum und dran, Dokumentation etc) oder den Generatoren beibringen das ein "Device" unterschiedliche Device Identifier haben kann (das wäre eine Monster-Aufgabe). Da ist es viel einfacher Behandlung dafür in den Brick Viewer einzubauen.

Das wird mit dem nächsten Brick Viewer Update gefixt, im GIT ist der Fix schon drin. Die beiden LCD Versionen haben den gleichen Device Identifier (d.h. sie nutzen die gleichen API Bindings). Das kann der aktuelle Brick Viewer noch nicht abbilden (die nächste Version kann es dann).

In 99% der Fälle wenn der Raspberry Pi abstürzt ist die Spannung nicht hoch genug. Wenn du ein Multimeter hast kannst du mal zwischen TP1 und TP2 auf dem RPi die Spannung messen (optimalerweise wären es 5V).

Das ist in größeren Stückzahlen sogar günstiger. Allerdings ist das über 1cm breiter und passt nicht zwischen die Board-To-Board Stecker . Das wird kein Problem machen, da die Fritz Box auch für g-Netze eine Modulation verwendet die das WLAN Modul versteht. Vermutlich sind die APs im industriellen Umfeld von Frostie absichtlich so konfiguriert, dass sie nur eine Modulation unterstützen um einen möglichst hohen Durchsatz zu erreichen.