remotecontrol

Zu 1: über das Problem bin ich auch gestolpert, da hast Du im anderen Thread ja drauf geantwortet. Ich bin übrigens auf 184 Byte brutto bekommen, da in der Page 3 ein Größenbyte drin ist. Und das ergibt bei mir 184 Bytes. Zu 2/3: weiss ich nicht genau Zu 4: 0x91 ist 0b10010001 - da ist das MB Bit doch gesetzt und ME nicht? Hast Du vielleicht eine falsche Bit-Reihenfolge? In C sieht meine Struktur so aus: struct MessageFlags { unsigned TNF: 3; unsigned IL : 1; unsigned SR : 1; unsigned CF : 1; unsigned ME : 1; unsigned MB : 1; } ATTRIBUTE_PACKED; Und damit konnte ich die auf den Tags vordefinierte Message inzwischen korrekt auslesen. Die Message verwendet doch well-known-types? 0x55 beim Message Typ ist "URI", das Byte danach definiert den URI Prefix, 0x01 ist "http://www.", das wird vor den Rest der Daten gepackt. Ergibt dann "http://www.tinkerforge.com" (bin nicht ganz sicher, was Du hier meinst). Zu 5. 0x51 ist binär 0b01010001 - da ist MB=0 und ME=1, ist doch OK? Zu 6. 0x54 ist Text, 0x02 danach ist die Länge eines Language-Code (kommt direkt danach), hier 0x65 0x6E = "en" und danach kommt dann der eigentliche Text in UTF-8.

So langsam verstehe ich mehr, die Doku im Shop verstehe ich dennoch nicht. Ich konnte den vordefinierten Inhalt jetzt korrekt auslesen (NDEF Message mit 2 Teilen, Teil 1 eine URL, Teil 2 eine Text-Message mit Sprache 'en'). Demnach ist der Aufbau Forum Typ 2 doch aber: Page 0-1 enthalten die Tag-ID Page 2 hat u.a. 1 Byte für die Gesamtgröße des Tags und hat 2 Lock Bytes zum read-only setzen des Tag Page 3 beinhaltet eine NDEF Kennung ab Page 4 beginnen die NDEF Daten (wenn man NDEF nutzen will, sonst kann man das überschreiben). Dann passt das auch mit den 168 Bytes: das Tag hat 184 Bytes brutto, minus 8 read-only, minus 8 für Lock-Bytes und NDEF Intro => 168. Wenn ich neue NDEF-Daten schreiben will, muss ich aber Page 4 neu schreiben. Darum verstehe ich das hier im der Shop Doku nicht so recht: Hier sind wohl Page 2-3 gemeint (weil die Zählung an anderer Stelle bei 0 beginnt) - oder? Die Anzeige im brickv beginnt auch erst bei 5 und nicht bei 4 - warum?

Du hast qmake im Home-Verzeichnis aufgerufen oder ist das hier nur eine abgekürzte Schreibweise unten? Da Du make im "bin" aufrufst, ist dort ein neues "Makefile" entstanden? Ist der Timestamp aktueller als auf Deinem PC? Der Fehler sieht nämlich danach aus, dass noch das Windows-Makefile aktiv ist oder Du hast fixe Windows-Einstellungen hinterlegt. Die GNU-Compile-Doku sagt zu dem Schalter: => diese Compile-Option gibt es wohl nur unter Windows.

I'm not a Python specialist, but Python also has a native thread implementation if you would use start_new_thread. With "real-threads" (all in one process) you don't have such problems, I use quite a lot of threads in C++ and Java. But if you fork() the process is different and that is not the "regular" usage for the IPConnection ...

Normalerweise gibt es bei QT doch eine Projektdatei. Mit qmake und der Projektdatei kann man in einem Buildverzeichnis ein Makefile generieren. Dieses Makefile ist spezifisch (auf jedem Rechner ggf. anders). D.h. ich dachte man müsste auf dem RED auch nur qmake aufrufen und danach make im build-Verzeichnis. Oder ist das bei Dir anders? Ansonsten könntest Du über den Qt-Creator per Rechtsclick auf das Projekt (nicht die pro-Datei) den Befehl "qmake ausführen" aufrufen. In der Console siehst Du, was ausgeführt wird. Mit diesen Befehlen kann ich ein kleines Projekt bei mir bauen: mkdir build_dir cd build_dir qmake /absoluter_pfad/zu/qt_test.pro -r -spec linux-g++ CONFIG+=debug make Sowas schon mal ausprobiert?

Du musst doch eigentlich nur "qmake" mit dem QT Projektfile aufrufen - oder? (bin kein QT Kenner). Oder wie übersetzt Du das Projekt aktuell? Und im Rahmen vom RED wird beim Upload per Brickv automatisch "make" aufgerufen und Du suchst ein makefile, welches intern den qmake startet?

Welche Firmwareversionen haben die Bricks? Die müssen alle 2.3.0 haben um mit dem RED und zusammen zu funktionieren. Dazu alle mal einzeln per USB anschließen und im brickv prüfen.

D.h. Du hast den Servobrick auch schon mal einzeln (ohne die anderen und ohne USB-Stromversorgung) per USB an einen Rechner gesteckt, brickv geöffnet und kurz danach war er im Brickv nicht mehr da? Was sagt das brickd.log? Mit demselben USB-Kabel lassen sich andere Bricks ansprechen?

Hallo zusammen, im Shop steht, dass die Kapazität des NFC Aufklebers 168 Bytes sind. In der Doku steht, dass für Typ 2 die Pages 0-1 reserviert sind (2 wohl unbenutzt) und eigentlich erst ab Page 5 gelesen werden sollte. Ich habe jetzt mal das Tag gelesen, bis der Page-Request auf Fehler läuft und da komme ich dann auf 160 Bytes (ab Page 5 inklusive), also 168 Bytes ab Page 3 (168 beschreibbare Bytes plus 3 read-only pages). Ein Hinweis in oder Doku wie diese 168 Bytes zu interpretieren sind wäre hilfreich, z. B. 168 Bytes inkl. Lock-Bits am Anfang/Ende, ohne Tag-Id, also 152 Bytes netto (wenn meine Rechnung stimmt). Übrigens: wie ist eigentlich die dort vordefinierte Zeichenfolge codiert? Neben dem gut lesbaren Anteil sehe ich Bytes 0x10 und 0x01 - ist heute Abend irgendwie zu hoch für mich . Viele Grüße

Yes it is OK, to use a Bricklet from multiple clients. But I think the fork() is a problem for the network connection: if you fork() after a call to IPConnection.connect() then both processes share the same network port. If both processes still use this port, then this will lead to confusion. This might be OK as long as only one child uses the connection, but is not OK if both processes read and write to that connection. In this case each process needs an own connection (IPConnection opened within the forked process).

You are using Linux? Then python's fork() should call Linux' fork() and would copy the process and if you don't execute another program in the forked process, you have a clone of the parent process with different address space. Both proesses share open file and network handles and I don't know what happens in this case with the IPConnection. In forked() processes I would open a new IPConnection (so start the init after fork()).

You use multiple threads? If you send commands to the stack from within a callback you must be aware that only one callback can be active at a time and you should not wait in a callback for the execution of another callback.

Meine Kabel sind eigentlich schon auf Minimum (meist 15cm, aber eben 10 davon und 2 kommen bald noch dazu) aber ich kann das mit der Geschwindigkeit ja mal probieren. Vielleicht sind es ja auch Störungen, die dazu führen, dass das LCD ab und zu Befehle nicht ausführt (dazu habe ich einen anderen Post)? Wäre das denkbar: einfach zu viele Kabel zu dicht?

Den Effekt (Stack-Hänger) hatte ich zwar noch nicht, aber beim Barometer Bricklet hatte ich vereinzelt (1x pro Monat) fehlerhafte Werte in der Art, das ein riesiger Sprung da war (auch von anderem User berichtet) und nach Umbau meines Stacks habe ich das nun vereinzelt (aber doch 2-4mal pro Tag) beim Temp.-Bricklet, beim Barometer-Bricklet nicht mehr. Sind das Störungen auf der Leistung oder was könnte sowas bewirken?

Du kannst nur einen Callback dieser Art setzen. Alternativ kannst Du aber einen value change Callback verwenden (CALLBACK_ILLUMINANCE). Der wird bei jeder Änderung der Lichtverhältnisse aufgerufen. In dem Callback könntest Du dann abhängig vom aktuellen Wert das Licht ein oder ausschalten. Ansonsten musst Du Dich anderweitig darum kümmern das Licht auszuschalten. Im Akt. Code wird genau 1x zu Beginn dass Licht ausgeschaltet.

Mir ist noch nicht klar, was Du erreichen willst. Das ist ein Akkupack mit 10400mAh; bei vier Zellen vermutlich 4 Zeilen a 2600mAh. Wenn Du messen willst, wie viel Kapazität schon verbraucht wurde, kommst Du mit dem Voltage/Current Bricklet hin.

Hast Du keine Typenbezeichnung von am Akkupack?

Da ich auch noch ein paar neue Funktionen entwickle starte ich die Anwendung gerade öfter neu ... Dabei musste ich nun feststellen, dass auch die Callback-Initialisierung vom SoundIntensity-Bricklet nicht mehr stabil funktioniert, d.h. ich starte die Anwendung, setzte einen Callback mit Min 950 (Option '>' und alle 40ms) und der Callback wird nicht aufgerufen . Am leichten Blinken der Master-LEDs kann ich inzwischen erkennen, ob der Callback aktiv ist oder nicht (und nur nicht an der Anwendung ankommt) und hier ist der Callback nicht aktiv gewesen. Starte ich die Anwendung danach nochmal neu (Initialisierung ist immer gleich ...) => der Callback wird mit hoher Wahrscheinlichkeit wieder aufgerufen (Stack dabei nicht neu gestartet). Ein Gedanke war noch, dass es aufgrund der vielen Bricklets und Kabel zu Störungen kommt. Aber sind 10 Bricklets viel? Kabel verkürzen ist eigentlich kaum mehr möglich, aktuell habe ich 1x 6cm, 7x 15cm und 2x 20cm (die 'alten' nicht gedrehten Kabel). Ich werde wohl nicht drum herum kommen, als alles wieder zu zerlegen und nochmal die alte Firmware drauf zu spielen.

Ich hab's mal mit einem 80cm IR-Sensor und dem klaren Wetterstationgehäuse ausprobiert: wenn das Plexiglas ganz dicht auf dem Sensor liegt funktioniert es gut (ohne merkliche Beeinträchtigung). Entferne ich das Plexiglas aber, dann wird der Sensor gestört: in 2cm Abstand, misst er ca. 40cm, in 5cm misst er 10cm (was Minimum für den Sensor ist). Dazu kommt das, was NIC geschrieben hat: bei Sonneneinfall kann sich das nochmal ändern. Ggf. kannst Du den Sensor ja unten raus schauen lassen (die Front hat unten ja eine Ausbuchung).

In another thread there was a post that the default screen resolution of the RED is 1920x1080, but no result to which screen resolution the user could change it (German: http://www.tinkerunity.org/forum/index.php/topic,2699.msg17308.html#msg17308). To use xrandr is correct, but I'm not sure if it is possible to change the screen resolution to that value. I had three different embedded boards now and they all had a native resolution (which if 1920x1080 for the RED) and a very limited possibility to change the screen resolution. Regarding the display, the embedded boards are not that flexible.

Hi, icon_connect connects to the brickd via TCP/IP or directly to the stack if an externet or WIFI extension is present. If you connect to a brickd, you'll always get an OK back even if no brick is connected via USB (except the network connection is down). But if you trigger an enumerate, you will not see the stepper, if it is not connected via USB. I'm not sure what you mean, can you explain it a bit more detailed?

Die Stromversorgung über den RasPI reicht aus. Anstelle des Distance IR würde ich mir überlegen, ein MotionDetector Bricklet zu verwenden. Das ist zwar größer, aber erkennt Bewegungen auch, wenn man sich etwas seitlich dem Bricklet nähert. Bei mir geht die Beleuchtung dann schon auf einige Entfernung an und nicht erst, wenn ich direkt davor stehe. Wenn Du genau das nicht willst, ist Distance IR eine Möglichkeit. Hinter Plexiglas habe ich aber noch nicht ausprobiert. Ich würde annehmen, dass das Gehäuse die Funktion beeinträchtigt.

Die Information bekommst Du über den Enumerate raus. Z. B. liefert der Enumerate beim Connect (Enumerate Type == 0) Informationen dieser Art: UID: 6wTCtc Enumeration Type: 0 Connected UID: 0 Position: 0 Hardware Version: 1.0.0 Firmware Version: 2.0.5 Device Identifier: 14 UID: cJW Enumeration Type: 0 Connected UID: 6wTCtc Position: a Hardware Version: 1.1.0 Firmware Version: 2.0.0 Device Identifier: 25 Die UID 6wTCtc ist ein Servobrick (da Device Identifier == 14), der Servobrick ist der unterste Brick im Stack, da "Connected UID == 0". Ein Masterbrick hätte hier den Identifier 13. Die UID cJW (Device Identifier = 25, das ist ein Distance IR Sensor) ist angeschlossen an 6wTCtc, d.h. dieses Bricklet hängt an dem Brick mit der "Connected UID". Du kannst das nicht direkt abfragen, nur über diese Informationen aus dem Enumerate ableiten.

Im ersten Enumerate wandle ich die Typ-IDs in spezifische Objekte (LCD, Ambilight etc.) und damit arbeitet die Anwendung dann weiter (UIDs kennt die Anwendung eigentlich nicht), d.h. die Liste der Bricks / Bricklets "merke" ich mir eigentlich, um Befehle senden zu können. Das meine ich mit "merken". Nicht dass ich mir die Enumerate Info 1:1 merke, aber indirekt die Informationen, die ich daraus gewinne.

Hallo foley, ich versuche immernoch, mich von Python fern zu halten ... Was mir aber dennoch auffällt: Du machst 2 IPConnections auf, dass ich nicht notwendig und evtl. sogar kontra-produktiv (hab's selber noch nie so ausprobiert). Du solltest beide Bricklets bei der einen IPConnection registrieren. 2 IPConnections machen nur Sinn, wenn Du gegen 2 unterschiedliche Hosts arbeitest. Den Aufruf von 'raw_input' musst Du vor dem Disconnect machen, sonst hast Du die Verbindung ja schon getrennt und nichts geht mehr. Generell: eine Illuminance > 200 Lux ist schon recht hell. Teste erstmal mit dem brickv, welche Helligkeitswerte Du so erreichst, sonst wird der Callback ggf. nie ausgelöst.