remotecontrol

Alle Jahre wieder weil Weihnachten ist: es scheint am Ende mit dem Datentransfer per WLAN zusammen zu hängen bzw. dem Vorhandensein der WLAN-Extension 1 oder 2. Ist die Extension auf dem Stack läuft das Programm nicht sauber oder die letzten 10 der 50 LED Pixel laufen "außer Kontrolle" (Programm läuft auf anderem Rechner und steuert per WLAN). Das passiert teilweise auch, wenn man Tests mit Brick-Viewer macht. Ich hab jetzt mal einen Red-Brick drunter und der Master wird direkt angesprochen, dann läuft es sauber. Ist etwas komisch, denn in früheren Firmware-Versionen hat das problemlos funktioniert. Evtl. noch eine "Spätfolge" der Umstellung auf DMA. Ich brauche keine Lösung hier; eher als Info falls jemand ein ähnliches Problem hat.

Hört sich etwas nach Thread-Dead-Locks an, wenn es nach Neustart des Programmes wieder normal geht. - Nutzt Dein Client auch mehrere Threads (neben jenen der TF API)? - Falls ja: wie synchronisieren die sich bei reconnect? - alles in Java?

Hast Du mal ins brickd.log geschaut? Da müsste der USB Connect eigentlich sichtbar sein? z.B.: 2018-11-29 17:43:52.867096 <I> <usb.c:191> Added USB device (bus: 1, device: 4) at index 0: Master Brick [6QGw3E] 2018-11-29 17:44:02.932305 <I> <network.c:260> Added new client (N: 127.0.0.1:37918, T: plain-socket, H: 21/21, A: disabled) 2018-11-29 17:45:55.967287 <I> <client.c:223> Client (N: 127.0.0.1:37918, T: plain-socket, H: 21/21, A: disabled) disconnected by peer Wenn dort gar nichts von USB steht: hast Du ein 2. USB Kabel zum Test (wobei wenn es auf Windows mit dem Kabel geht ...) ?

Übrings coole Sache mit der neuen LCD API :)

Ja so steht es auch in der Doku. Wenn ich mir die Werte ausgeben lasse, dann sind die oft konstant. Kann aber sein, dass es intern noch "feingranularer" ist und man das außen nicht sieht, dass der Wert tatsächlich anders ist. Passt aber soweit.

The client API does not 'track' bricklet UIDs, the master brick has this information. The timeout is an indicator that the master did not react in time to the request and this can indicate a wrong UID. Nevertheless the API allows to work completely without UIDs if you use the enumerate feature and device type detection, so happy coding

Hallo zusammen, Frage zum Touch-Callback: wenn ich einen Touch-Callback registriere wird dieser zyklisch aufgerufen, sowie ich auf das Display drücke und gedrückt halte. Die Registrierung schaut in etwa so aus: lcd_128x64_register_callback(getDevice(), LCD_128X64_CALLBACK_TOUCH_POSITION, (void*)touchCallback, this); lcd_128x64_set_touch_position_callback_configuration(getDevice(), 50, false); Klappt soweit. Ich sehe aber keinen Unterschied abhängig vom Parameter 4 (value_has_to_change): egal ob true oder false, im angegebenen Zyklus wird der Callback ausgelöst, wenn ich drücke. Was sollte der 4. Parameter bewirken ?

Hallo zusammen, Der Sensor passt ja zum Outdoor Bricklet. Dann würde ich davon ausgehen, dass der Regenwasser abkann und auch hohe Minusgrade. Allerdings hat der eine Anzeige: hält die auch -20° aus? Es gibt ja auch Anzeigen, die dann kaputt gehen. Könnt Ihr solche Informationen noch im Shop ergänzen? Viele Grüße

Eigentlich völlig analog, nur dass Du statt 1 Objekt des Colorbricklets drei hast mit unterschiedlichen IDs. Auf die IDs musst Du achten um ggf. auch die richtige Funktionalität des jeweiligen Bricklet zuzuordnen. Jetzt kannst Du wie bei einem Bricklet auch entweder zyklisch auslesen oder Callbacks für jedes Bricklet setzen. Der User-Parameter des Callbacks kann z.B. dazu verwendet werden, um die Bricklet-Nummer anzugeben oder einen Pointer auf ein eigens Objekt welches am Ende des Farbwert hält.

Ist die Reihenfolge korrekt: Skript wird beim Shutdown aufgerufen, bevor der brickd runtergefahren wird und USB deaktiviert wird? Beim Shutdown geht alles sehr schnell. Theoretisch auch möglich, dass sofort nach dem Skript der brickd gekillt wird -> ggf. mal einen "sleep 1" ins Skript mit aufnehmen. Und um zu testen, ob das Skript aufgerufen wird mal ein "echo DONE > /home/tf/script_called" oder so ähnlich.

Ok, also Kategorie DAO 😯. Vielen Dank, ich probiere das dann nochmal so aus wie gerade beschrieben.

Ich brauche mal etwas Platz und verkaufe folgende nicht mehr benötigte Bricks/Bricklets (sind alle funtionsfähig): 2x DC Brick (mit 1 grün und 1 schw. Stecker): je 25,00 € 1x Servo Brick (mit 1 schw. Stecker): 25,00 € 1x WIFI Extension (1.0) inkl. kleiner Antenne: 20,00 € 1x Ambient Light (1.1): 3,00 € 1x Distance US: 6,00 € Jeweils ohne Montage Kit. Wenn jemand alles zusammen nimmt, gebe ich noch Montagekits und ein paar Kabel dazu. Versand erfolgt gegen Vorab-Überweisung. Die Versandkosten betragen je nach Versandart 2-5 €. Bei Interesse bitte eine Personal Message senden.

Nein RS485 (Extension) habe ich nicht, aber einen Stapel mit 3 Master und 12 verschiedenen Bricklets, also ziemlich gemischt. Mit dem Update habe ich auch das Gesamtsystem etwas umgebaut, d.h. die Brickletreihenfolge ist jetzt anders (könnte evtl. was ausmachen), aber ich habe in den letzten drei Tagen keinen einzigen Fehler mehr im Protokoll und vorher 20 - 50 pro Tag. Scheint auch ohne RS485 eine Verbesserung zu sein.

Zu den letzten Firmware Updates habt Ihr dieses geschrieben: Gehört das Barometer Bricklet auch zu jenen die I2C nutzen? (Wenn ich mir das Datenblatt ansehe würde ich sagen: JA) Bei mir läuft es jetzt auf jeden Fall stabiler . Früher hatte ich oft einige Sprünge in den Werten, die ich per Software ignoriert habe. Das tritt jetzt seit dem Update nicht mehr auf!

PINs sehen gut aus, Bricklet reagiert auch auf Setzen der Status LED. Ich sende das mal ein.

Das hatte ich gestern noch vergessen zu schreiben: nein, die Werte ändern sich nicht, wenn ich die Zelle von Hand belaste (ist noch nicht verbaut). D.h. ich hab die mal kalibriert mit 0g und einmal mit 100g (ohwohl kein Gewicht auflag) und danach von Hand "gebogen", aber die Werte ändern sich nicht sinnvoll.

Also angeschlossen ist es wohl richtig. Aber die Werte springen auch in Ruhe wild hin und her (siehe Screenshot). Selbst wenn ich kalibriere, dann springen die Werte ohne Last zwischen -300 und 1200 Gramm hin und her. Und das sollte sicher nicht sein. Kann das Bricklet eine Macke haben? Kann ich an die Signaleingänge einen Widerstand anschließen, der zu einer bestimmten Messung führen müsste ? Wenn ich ohne Strom den Widerstand an den Signaleingängen des Bricklets messe werden 1,00 KOhm angezeigt. D.h. der Kontakt scheint da zu sein.

Wenn ich den Widerstand der Wägezelle (zwicshen grün/weiß) mit einem Multimeter messe werden genau 1.000 K Ohm angezeigt - scheint ein plausibler Wert für einen 1Kg Sensor zu sein. Also Kabel der Zelle scheinen OK. Kann es sein dass das Bricklet defekt ist? Kann ich das mit irgendeinem Widerstand prüfen?

Wenn Du mit dem Brickviewer den Stapel mit WIFI anschaust: wird die WIFI Ext. beim Masterbrick angezeigt? Wenn nein ist was faul. Wenn ja (WIFI wird als Extension im Brickviewer angezeigt), dann muss die 1x konfiguriert werden: Du musst das Netzwerk auswählen und vermutlich auch das WLAN Passwort eingeben. Ich hab mal einen Screenshot gemacht wie das bei mir aussieht. Die rot markierten Stellen hab ich dann konfiguriert.

Hab nochmal etwas mehr getraced: - das Ganze passiert nur direkt nach Einschalten des Bricks (Stromversorgung ein) - zu Beginn kommen die Callbacks im 100ms Abstand (siehe Zeitstempel, Data ready 1) - dann höhren sie unerwartet auf (Data ready 0), ich protokolliere noch alle 5 Sekunden ob das gesendet werden darf. 2017-12-31 11:58:52.982332 Callback active with updateDelay 200 2017-12-31 11:58:52.982429 Style liquidDots 2017-12-31 11:58:52.982500 Data ready 1 2017-12-31 11:58:52.982611 Set frame duration to 100 2017-12-31 11:58:52.988087 Current: 35, Voltage: 10752, LED voltage: 4848 2017-12-31 11:58:53.006178 Data ready 1 2017-12-31 11:58:53.107121 Data ready 1 2017-12-31 11:58:53.208122 Data ready 1 2017-12-31 11:58:53.309099 Data ready 1 2017-12-31 11:58:53.410485 Data ready 1 2017-12-31 11:58:53.512849 Data ready 1 2017-12-31 11:58:53.612232 Data ready 1 2017-12-31 11:58:53.713142 Data ready 1 2017-12-31 11:58:53.814070 Data ready 1 2017-12-31 11:58:53.915499 Data ready 1 2017-12-31 11:58:54.017579 Data ready 1 2017-12-31 11:58:54.117174 Data ready 1 2017-12-31 11:58:54.218161 Data ready 1 2017-12-31 11:58:54.319157 Data ready 1 2017-12-31 11:58:54.420282 Data ready 1 2017-12-31 11:58:54.521143 Data ready 1 2017-12-31 11:58:59.525412 Data ready 0 2017-12-31 11:59:04.525591 Data ready 0 2017-12-31 11:59:09.525745 Data ready 0 Starte ich die Anwendung neu ohne den Brick von der Stromversorgung zu trennen läuft es dauerhaft normal. Mir völlig unklar wieso noch ca 1.5 Sekunden die Callbacks nicht mehr kommen.

Hallo zusammen, ich habe mal alle Firmwares aktualisiert und habe jetzt ein anderes Verhalten beim LedStrip-Bricklet: ich bekomme keine Frame redered callbacks mehr. Ich rufe der Reihe nach led_strip_set_frame_duration led_strip_register_callback auf und fange dann an Daten zu senden, aber nichts passiert: man sieht dass der erste Datensatz ankommt, aber kein Callback, d.h. ich sende dann nicht weiter. Ich habe mal eingebaut, dass das Programm per Signal led_strip_set_frame_duration+led_strip_register_callback nochmal aufruft => danach startet der Zyklus. Was ist anders als früher, dass der erste led_strip_register_callback keine Wirkung zu haben scheint?

Hallo, habe gerade mein Load Cell Bricklet und eine 1Kg Wägezelle bekommen, aber der Brickv zeigt immer über 8200 Kg an. Wenn ich die Wägezelle abklemme ist das Ergebnis dasselbe, d.h. scheint als wäre kein Kontakt. Ich habe die Anschlüsse jetzt aber schon 3x rein raus und geprüft -> die müssten Kontakt haben. Reihenfolge ist grün, weiß (Signal) und schwarz, rot Ist das falsch oder was könnte sonst noch schief laufen?

Inzwischen kann der Emulator + GUI auch noch - OLED - DualButton - und einige andere ...

Hallo Jens, die minimale Updatezeit der Bricklets liegt bei 1ms. Wenn sich der Ball mit 2m pro Sekunde bewegt und ca. 2cm Durchmesser hat, dann bräuchten die 2cm ca. 1/100 Sekunde = 10ms um die Torlinie zu passieren (oder habe ich mich jetzt vertan?). Das könnte man vermutlich messen, geht auch einfach per Interrupt. Aber je höher die Geschwindigkeit, umso ungenauer wird das. Ich hab kein Gefühl, wie schnell zu ein Ball sein kann. Ich vermute schon mehr als 2m/s. Und wie ist das mit der UV Diode gedacht? Viele Grüße

Das siehst Du leider richtig: der das Protokoll der Funksteckdosen lässt es nicht zu, den aktuellen Zustand abzufragen, daher kann das RemoteSwitch Bricklet das auch nicht. Ich mache das aktuell so, dass ich bei Start des Programmes die Steckdosen erstmal ausschalte, damit ich einen einigermaßen gesicherten Grundzustand habe. Die Restunsicherheit bleibt, dass der Schaltvorgang nicht erfolgreich durchgeführt wurde.