photron

Brick Viewer 2.3.4 Add support for Real-Time Clock Bricklet Don't auto-update Thermocouple Bricket with Temperature Bricklet firmware Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.3.4 Support für Real-Time Clock Bricklet hinzugefügt Thermocouple Bricket wird nicht mehr mit Temperature Bricklet Firmware auto-aktualisiert Downloads: Windows, Linux, Mac OS X

Das Flat Flex Kabel müsste speziell angefertigt werden, die gibt es nicht von der Stange. Momentan gibt es da keine Pläne für. Es gibt schlicht sehr sehr wenig bis keine Nachfrage dafür, daher ist das softwareseitig auch noch unfertig.

Funktioniert der Touch Screen nur am RED Brick nicht, oder funktioniert er an einem anderen PC auch nicht? Es kann sein, dass im RED Brick Kernel der Treiber für den Touch Screen Controller fehlt oder nicht aktiviert ist. Ich konnte auf Anhieb nicht herausfinden, welcher Touch Screen Controller bei dem Display verbaut ist. Vielleicht kannst du das heraus bekommen, wenn du den Touch Screen an einem anderen PC anschließt. Alternative kannst du auch die Nummern von den zwei großen Chips auf der Rückseite ablesen und hier posten.

Du kannst pro Master Brick mit einem LED Strip Bricklet und drei freien Bricklet Ports 320 LEDS ansteuern. Für die nächsten 320 LEDs brauch du dann einen weiteren Master Brick mit einem weiteren LED Strip Bricklet und 3 freien Ports. Du kannst nicht 400 LEDs am Stück ansteuern. Du könntest deine 400 LEDs auf 2 Master Bricks + LED Strip Bricklets aufteilen: Master Brick 1 ---> LED Strip Bricklet 1 ---> 200 LEDs | PC ---> Master Brick 2 ---> LED Strip Bricklet 2 ---> 200 LEDs Die beiden Master Bricks können dabei in einem Stack sein. Die LEDs können flasche Farben anzeigen, wenn du sie nicht ansteuerst, denn dann können sie rauschen auf den Leitungen als Daten missversteht. Das beste Vorgehen ist also immer alle angeschlossenen LEDs anzusteuern und die die du nicht brauchst auf 0,0,0 (schwarz) zu setzen.

Ich habe gerade folgendes getestet: - GPU aus, Desktop aus, Spalsh aus, openHAB an, "Save and Reboot" - Dateisystem "Reboot and Expand" - openHAB Config geändert, gespeichert und "Reboot RED Brick" Funktioniert alles ohne Probleme. Bei dir funktioniert es also nicht über Brick Viewer einen Neustart zu machen? Mit welchem LED Zustand bleibt der Bootvorgang denn stehen? Normalerweise solltest du kurz die rote LED aufleuchten sehen. Dann sollte die rote ausgehen und die grüne leuchten. Nach einem Moment sollte die grüne dann blinken. Es funktioniert aber, wenn du durch Strom ab-/anstecken einen harten Neustart erzwingst?

Auf der GPIO Schnittstelle des RED Brick liegen auch UART Pins, ja. Die GPIO Schnittstelle ist aber momentan nur in Hardware vorhanden. Sie wird vom Kernel momentan weder passend konfiguriert, noch gibt es momentan ein passendes Flat Flex Kabel dazu. Das ist also nichts was du kurzfristig nutzen könntest.

Funktioniert hier. Sowohl "Reboot RED Brick" als auch "Restart Brick Daemon". Von was für einem Build sprichst du nach dessen Installation ein Neustart zwingend notwendig sein soll?

Wir verwenden hier z.B. diese SD Kartenleser: http://www.amazon.de/Transcend-TS-RDF5K-Kartenleseger%C3%A4t-MicroSDHC-microSDXC/dp/B009D79VH4/

So eine frei Speicherfunktion gibt es im System so nicht. Die UIDs der Bricks werden aus der UIDs des Mikrocontrollers abgeleitet und sind nicht änderbar. Die UIDs der Bricklets sind ein uint32 der Base58 kodiert dargestellt wird. Du könntest also eine Bricklet UID als 4 Byte freien Speicher missbrauchen. Der uint32 Wert darf nur nicht 0 sein.

Hier die Funktion der Read Klasse ohne Klasse. Dazu ersetzt du in deinem Beispiel die cb_read Funktion durch diese Version: buffer = '' # Global buffer to collect all incoming data # Callback function for read callback def cb_read(message, length): s = char_list_to_string(message, length) # Append new data to global buffer global buffer buffer += s # Check if global buffer contains a complete response i = buffer.find('\r\n') if i >= 0: # Get response (without \r\n) from buffer response = buffer[:i] # Remove response (with \r\n) from buffer buffer = buffer[i + 2:] # Print response print('Response: ' + response) Im Read Callback kommen die Daten immer noch stückweise an, daran ändert sich nichts. Der Code nutzt jetzt aber einen globalen Buffer in dem alle eingehenden Stück gesammelt werden. Dann wird in den Buffer geschaut, ob eine komplette Antwort (endet mit \r\n) im Buffer zusammen gesammelt wurde. Wenn ja wird sie aus dem Buffer entfernt und ausgegeben.

Ah, da muss ein deaktiviert stehen!

Auf dem RED Brick ist Python 2.7 und Python 3.4 bereits standardmäßig installiert.

GPS Antenne: Du meinst du hast die extern GPS Antenne: https://www.tinkerforge.com/de/shop/gps-antenna.html Dafür bräuchtest du ein UF.L auf UF.L Verlängerungskabel. Das habe ich allerdings so noch nicht gesehen. Alternative kannst du eine GPS Antenne mit langem Kabel nehmen und SMA Anschluss plus einen SMA auf UF.L Adapter: http://www.amazon.de/Adafruit-GPS-Antenne-Anschlusskabel-SMA-Anschluss/dp/B00LX8MZAQ/ https://www.tinkerforge.com/de/shop/gps-pigtail-cable.html RED Brick: Die red_image_1_7_full.img.7z Datei ist ein 7-Zip Archive, dass du zuerst entpacken muss. Die enthaltene Image Datei kannst du dann z.B. mit dem Win32 Disk Imager Tool (Windows) oder dd (Linux/Mac) mittels eines SD Kartenlesers auf die SD Karte schreiben: http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#image-auf-sd-karte-kopieren Aktuell ist übrigens Image Version 1.8.

Der Wertebereich des Linear Poti ist 0 bis 100 abgebildet als uint16. Der Wertebereich des Rotaty Poti ist -150 bis +150 abgebildet als int16. uint16 bildet in den Java Bindings auf int ab und int16 auf short. Das zu ändern hieße entweder, eines der Poti in allen Bindings zu ändern, oder die kompletten Java Bindings zu ändern, das alle Integer als int abgebildet werden. Das wäre also eine großere Änderung. Solche Typ-Unterschiede für Dinge die vermeintlich gleich sein sollten gibt es sicher noch mehrere. Man würde dann also nicht nur diesen ändern sondern dann alle auf mal. Viel Arbeit auf allen Seiten mit wenig Gewinn. Ich denke wir werden das auf absehbare Zeit nicht ändern.

Das GPS Bricklet hat einen externen UF.L Antennenanschluss. Daran kannst du GPS Antennen anschließen die folgender Spezifikation genügen: http://www.tinkerforge.com/de/doc/Hardware/Bricklets/GPS.html#externe-antenne

Der Mali Typo ist korrigiert. Was das jetzt mit "Unnötig" und "Stress" zu tun hat verstehe ich allerdings nicht

Auch im Brick Viewer wird die Antwort in zwei Teile ankommen. Die beiden Teile werden aber so schnell hintereinander ankommen, dass es so aussieht als würden sie in einem Stück ankommen. RS232 ist streamorientiert, nicht paketorientiert. Es wäre auch okay, wenn die Daten Byteweise geliefert würden. Du musst einfach genauso wie Brick Viewer alle eingehenden Daten aneinanderhängen, um den Datenstrom zu rekonstruieren. Dann kannst du wie Brick Viewer den Datenstrom anhand der \r\n in die einzelnen Nachrichten zerlegen. class Reader(object): def __init__(self): self.data = '' def cb_read(self, message, length) self.data += ''.join(message[:length]) def get_next_message(self): i = self.data.find('\r\n') if i < 0: return None else: message = self.data[:i] self.data = self.data[i + 2:] return message

Ein Masseproblem könnte falsche Daten vielleicht erklären. Aber zumindest im -2427668000000000000000000000000.0 Beispiel fehlen ja auch einige Bits.

Meine Vermutung ist, das die Heizung mit einer nicht-standard Baudrate spricht und das Bricklet damit weniger gut zurecht kommt als dein Laptop. Wenn du für das Bricklet die Baudrate ein Stufen über oder unter 19200 stellst, ist es dann sofort vollständig kaputt? Oder ist es dann kaputter aber es sind immer noch heile Teile dabei? Gibt es keine Dokumentation zur Heizung die was über die Baudrate sagt?

Du sagtests in Putty XON/XOFF Softwareflusskontrolle aktiviert zu haben. War das wirklich nötig damit es funktioniert? Das scheint mir komisch, wenn du sagst beim Bricklet zwingend Hardwareflusskontrolle aktivieren zu müssen. In der heilen Ausgabe kommt diese Zeichenkette vor: -2427668000000000000000000000000.0 Die taucht auch in der kaputten Ausgabe wieder auf, aber so (hex-escaped): -24276\x82\x82\x82\x82\x82\x82\x82\x82\xc1\x82\x82\x82\x82\x82\x82\x82\x98\x980000.0 Zuerst fällt auf, dass die kaputt Version 4 Zeichen kürzer ist. Betrachtet man das ganze dann binär und versucht das zu Deckung zu bringen sieht das so aus: heile 00101101 00110010 00110100 00110010 00110111 00110110 00110110 00111000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00110000 00101110 00110000 kaputt 00101101 00110010 00110100 00110010 00110111 00110110 10000010 10000010 10000010 10000010 10000010 10000010 10000010 10000010 11000001 10000010 10000010 10000010 10000010 10000010 10000010 10000010 10011000 10011000 00110000 00110000 00110000 00110000 00101110 00110000 Im Mittelteil sieht das doch halbwegs ähnlich aus. Es scheint nicht so zu sein, dass die kaputten Teile völlig zufällig kaputt sind. Hast du mal versucht die Baudrate eine Stufe rauf oder runter zu stellen?

Die heile Ausgabe besteht nur aus ASCII Zeichen. Das ist also kein Problem mit dem Zeichensatz. Das sollte in Putty mit UTF-8 und Latin1 gleich gut funktionieren, da beide ASCII auf die gleiche Weise enthalten. Sprich in Putty von UTF-8 auf Latin1 umzustellen ist nicht nötig, wenn doch dann ist da etwas faul. Die kaputt Ausgabe beinhaltet im Brick Viewer im ASCII Anzeigemodus viele Punkte, also Werte die in ASCII keinem darstellbaren Zeichen entsprechen. Kannst du so ein kaputte Ausgabe mal aus dem Hex Modus hier zeigen, damit wir sehen können welche Werte sich hinter den Punkte verstecken? Die kaputt Ausgabe ist ja nicht vollständig kaputt. Da sind ja auch mitten drin noch heile Teile. Hast du vielleicht ein Wackelkontaktproblem, das nur das RS232 Bricklet betrifft?

RED Brick Image 1.8 Disable unnecessary OTG detection on Mini-USB port Increase image size from 5GB to 7GB Enable more HID and Bluetooth kernel drivers Install sunxi Mali GPU driver into the correct directory Manually install snmp-mibs-downloader to workaround Debian packaging problem Update Brick Daemon to version 2.2.2 Update Brick Viewer to version 2.3.3 Update all API bindings: C/C++ 2.1.10, C# 2.1.9, Delphi/Lazarus 2.1.10, Java 2.1.8, JavaScript 2.0.8, LabVIEW 2.1.8, Mathematica 2.1.8, MATLAB/Octave 2.0.8, Perl 2.1.8, PHP 2.1.8, Python 2.1.8, Ruby 2.1.8, Shell 2.1.8, Visual Basic .NET 2.1.8 Download: RED Brick Image

RED Brick Image 1.8 Unnötige OTG Erkennung am Mini-USB Port deaktiviert Image von 5GB auf 7GB vergrößert Mehr HID und Bluetooth Kernel-Treiber aktiviert sunxi Mali GPU Treiber ins richtige Verzeichnis installiert snmp-mibs-downloader installiert, um ein Debian Packaging Problem zu beheben Brick Daemon auf Version 2.2.2 aktualisiert Brick Viewer auf Version 2.3.3 aktualisiert Alle API Bindings aktualisiert: C/C++ 2.1.10, C# 2.1.9, Delphi/Lazarus 2.1.10, Java 2.1.8, JavaScript 2.0.8, LabVIEW 2.1.8, Mathematica 2.1.8, MATLAB/Octave 2.0.8, Perl 2.1.8, PHP 2.1.8, Python 2.1.8, Ruby 2.1.8, Shell 2.1.8, Visual Basic .NET 2.1.8 Download: RED Brick Image

Hast du auf dem RS232 Bricklet die aktuelle Firmware 2.0.2 drauf? Der Tab in Brick Viewer für das Bricklet zeigt unten 3 verschiedene Error Counter an? Stehen die alle bei 0?