remotecontrol

Den Ansatz, das in diesem Fall über die Position im Stack zu machen finde ich eigentlich gut. Die Brick Reihenfolge im Stack kann man leicht erkennen (leichter als die Bricklet Ports) und wenn man den Stack zerlegt, um z.B. neue Firmware draufzuspielen, muss man nicht drauf achten, ob man danach den richtigen Stepper an Anschluss X oder Y hat. Mich wundert nur, dass die Abfrage nicht funktioniert hat, sollte eigentlich gehen.

Dein konkretes Problem hast Du aber immernoch nicht genauer beschrieben. Wenn Du den Enumerate verwendest, dann bekommst Du darüber doch die Position im Stack (0,1,2) und UID und den Typ (Master, Stepper) etc.. Damit kannst Du doch alles zuordnen was Du brauchst und mit der richtigen UID den einen oder anderen Stepper steuern. Und Dein Problem ist ... ?

OK, da kann ich nicht weiterhelfen.

Wenn Du über die Brickv-Console ein Programm startest, dann musst Du - ein laufendes X oder VNC haben - das Display des X-Servers kennen (remote ist nicht :0) - Zugriffsrechte auf das Display haben Wenn Du Dich z.B. mit einer ssh-Session anmeldest (die hat erstmal keine Verbindung zu X) kannst Du zwar über "export DISPLAY=:0" das Display auf das Hauptdisplay lenken, aber in einem X-Terminal des Hauptdisplays musst Du erstmal "xhost +" eingeben, damit Du von einem anderen Terminal graphische Anwendungen starten darfst, sonst könnte ja jeder auf Deinem Bildschirm was starten...

Es scheint aber eher so, als wäre Dein Update OK, aber der Start der Anwendung von der falschen Stelle aus passiert. Wenn Du Dich gegen den Desktop per VNC verbindest und dann aus einem XTerm die Anwendung startest: wann kommt dann für eine Fehlermeldung?

ist doch eher eine Fehlermeldung, dass sich die Anwendung nicht zum X-Server verbinden kann? Hast Du einen X-Server am laufen und startest die Anwendung aus einer X-Session?

Dem Emulator habe ich jetzt noch eine erste Version einer Qt-GUI verpasst . Die kann zwar noch nicht alle Devices anzeigen die der Emulator inzwischen kann, aber bringt dann doch den Zusatzeffekt, dass Multitouch und LCD-Buttons manuell bedient sowie Sensorwerte auch manuell verstellt werden können und nicht immer "vordefiniert" sind. Und: die GUI ist im Gegensatz zur App nicht anwendungsspezifisch, d.h. zeigt einfach den Brickletzustand an. Sie passt sich dynamisch den konfigurierten Devices an. Beim RemoteSwitch wird ebenfalls dynamisch für jeden neuen Code ein Schalter mit dem Code eingeblendet. Den Emulator kann ich nun mit und ohne GUI nutzen. Von der GUI nicht unterstütze Devices werden einfach ignoriert, aber weiter emuliert.

Falls es schon mal jemand geschafft hat, einen Type1 Tag jenseits der Page 15 zu lesen / schreiben, bin ich für sachdienliche Hinweise dankbar (welcher Typ und ob es besondere Vorkehrungen gab). Anbei mal der Tag-Typ, den ich gerade am Wickel habe.

Hallo TF-Team, ich muss nochmal nachhaken: ich kann diesen Chip-Typ definitiv nicht korrekt lesen (hab's mit mehreren versucht). Prüft Ihr das noch oder bleibt der eine in der Doku erwähnte Chip-Typ der einzige offiziell unterstützte Typ 1 Chip. Viele Grüße

Ich habe sowas ähnliches mit einem einfachen Socket-Protokoll gemacht. D.h. einen Dienst auf dem "Server" der einen Socket öffnet und die App verbindet sich dagegen und dann werden die Daten ausgetauscht. Theoretisch könntest Du das auch einfacher haben, wenn Du auf dem RED einen HTTP Server hast und dann Daten per HTTP austauschst, dann ist das Protokoll vordefiniert. Hängt ein wenig von den Anforderungen ab.

Wurde auch Studenten schon mal vorgeführt: http://www.tinkerunity.org/forum/index.php/topic,1542.msg10176.html#msg10176

Ich gehe mit einem kleinen Schraubenziehen links an die überstehende Zunge des Steckers und kann durch Drehen des Schraubenziehers den Stecker etwas lösen (weniger als 1mm, steht dann minimal schief). Das Gleiche auf der anderen Seite und damit ist der Stecker ausreichend locker, um ihn gerade von Hand abziehen zu können.

Ich konfiguriere die Bricklets im Rahmen des "enumerate" Callbacks der in verschiedenen Situationen aufgerufen werden kann. Damit habe ich eigentlich keine Probleme (C++). Ein typischer Fall auf den man achten muss: wenn Du eine laufende Anwendung hast und gehst dann per brickv auf den Brickd / Stack, dann konfiguriert der Brickv die Callbacks um. Das kannst Du über den enumerate-Callback erkennen und neu konfigurieren. Diese Art Konfiguration ist auch hilfreich, wenn Du im laufenden Betrieb des Stack resettest (per Taste oder per reset() aus der Anwendung). Dann bekommst Du wieder einen enumerate und kannst alles wieder sauber konfigurieren, ohne die Anwendung neu zu starten. Wenn Du das alles nicht brauchst, geht's auch ohne.

Es gibt "DC/DC Step-Up" Schaltungen, die Spannung erhöhen können (kleine Platine), gibts bei E-Bay oder auch anderswo. Die kosten unter 4€ / Stück. Damit kannst Du aus 3,5V auch recht genau 5 oder 6V machen. Die Leistung dieser Dinger ist begrenzt, für Servos sollte es aber reichen.

Meinst Du sowas? $idi4->setInterrupt(1 << 15); Das wird nicht geht, da hier das eine Bit um 15 Stellen geshiftet wird. Du kannst sowas nutzen: 1 << 0 -> 1 shift um 0 Bits == 1 1 << 1 -> 1 shift um 1 Bits == 2 1 << 2 -> 1 shift um 2 Bits == 4 1 << 3 -> 1 shift um 4 Bits == 8 oder natürlich die Zahlen 1,2,4,8 und Summen davon verwenden.

Hallo TF Team, ich habe neben den Forum Type 2 Tags aus dem Shops nun auch ein paar Forum Type 1 Tags (Topaz 512 Chip - http://www.amazon.de/gp/product/B00GYM3SG6?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s01). Aber es sieht so aus, als könne ich nur die ersten 14 Pages a 8 Bytes lesen (den 1. Block). Lese ich weiter, dann bekomme ich 0-Bytes und ab Page 33 kommen wieder die Daten, die ab Page 1 auch standen?? (Sowohl mit brickv, als auch mit meinem Programm) D.h. mit dem NFC-Bricklet kann ich nur die ersten 96 Bytes korrekt lesen, mit dem Tablet aber auch den Rest, da steht noch mehr drauf... Sind die Forum Type 1 so unterschiedlich und dieser wird nicht unterstützt? Viele Grüße

Das Beispiel erzeugt ein Listener-Objekt ohne Klassennamen direkt beim "add". Mach eine normale Klasse daraus mit Konstruktor und übergebe dem Konstruktor die IPconnection und die Zielliste. Für jede IPConnection brauchst Du dann eine Klassen-Objektinstanz. Dann kannst hast Du beim enumerate die Connection im Zugriff.

Nach Zerlegen und Zusammensetzen meines Gehäuses habe ich kurz danach mal die -99.99 erhalten (vermutlich statische Ladung, hatte das Bricklet berührt). Danach sind aber keine Callbacks vom Temp.-Bricklet mehr gekommen, alles andere im Stack hat aber noch funktioniert / reagiert. Bedeuten die -99.99 dass ich den Stack resetten muss oder sollten Callbacks weiterhin kommen und eigentlich alles normal funktionieren?

Hallo zusammen, eine Detailfrage zur Callback-Initialisierung: Der Muster-Code für einen Value-Reached Callback setzt erst die Debounceperiod, danach registriert es den Callback und ganz am Ende wird erst der Threshold gesetzt: // Get threshold callbacks with a debounce time of 1 seconds (1000ms) sound_intensity_set_debounce_period(&sound_intensity, 1000); // Register threshold reached callback to function cb_reached sound_intensity_register_callback(&sound_intensity, SOUND_INTENSITY_CALLBACK_INTENSITY_REACHED, (void *)cb_reached, NULL); // Configure threshold for "greater than 2000" sound_intensity_set_intensity_callback_threshold(&sound_intensity, '>', 2000, 0); Der "...register_callback" setzt ja nur einen Pointer in der IP-Connection. Ist aber die Reihenfolge der beiden anderen Aufrufe relevant, d.h. sollte/muss man erst die Debounce-Period setzen und danach den Threshold - oder macht das keinen Unterschied? Was passiert, wenn man erst den Threshold setzt, zu der Zeit ggf. das Limit schon erreicht wird und direkt ein Callback ausgelöst wird und 1ms danach erst die Debounce-Period gesetzt wird? Ist der Callback dann aktiv?

Schwitz - Gehäuse wieder komplett zerlegt alle Bricklets weg, Stack ausgebaut, Downgrade auf Firmware 2.2.0 und alles wieder zusammensetzen... Dabei konnte ich mit etwas Gefummel 2 Brickletkabel noch von 15 auf 6cm verkürzen. Dafür habe ich gleich noch ein "Sparekabel" ohne Bricklet am letzten freien Port nach außen gelegt (bloß nicht nochmal alles zerlegen). Und: Effekt ist weg ! Freut mich zwar, aber die Ursache ist leider ungeklärt ...

Du brauchst zwingend FW 2.3.0 auf dem Master.

Die beiden Funktionen sind kein Standard-C, sondern Microsoft-Erweiterungen. Die wirst Du ersetzen müssen. strlwr könnte man so umsetzen: #include<ctype.h> #include<string.h> char *strlwr(char *str) { char *s = str; while (*s) { *s = tolower(*s); ++s; } return str; } Bei mbsnbcmp musste ich erst nachsehen, was die macht (kannte ich nicht mal): das scheint eine Art strncmp zu sein (String compare mit begrenzter Anzahl Zeichen). strncmp ist Standard-C (denke ich). Nachtrag: strncmp funktioniert mit UTF-8 ggf. nicht korrekt. Verwendest Du das - multibyte Strings? Willkommen bei der Multi-Plattform Entwicklung

Also ich kann 44 pages (ab page 2) erfolgreich lesen. Damit habe ich insgesamt 46 pages, wovon nicht alle nutzbar sind, aber es ergibt die 184 Bytes (NFC Aufkleber, sollte aber mit Anhänger identisch sein).

Kleiner Nachtrag, wie ich auf die Anzahl der Bytes komme: Ich lese immer das ganze Tag ab Page 2, solange bis ich einen Lesefehler bekomme. Wenn ich das so mache, dann kann ich 176 Bytes lesen. Außerdem steht in Page 3 ein Größen Byte (hier 0x17 => 23) mal 8 = 184.

Hier ist noch was mit der Include-Definition schief: der Compiler-Aufruf setzt "-I/usr/include/qt4/QtGui" als Parameter. Deine Source includier "QtGui/QWindow", d.h. das Unterverzeichnis "QtGui" müsstest Du gar nicht mehr angeben in der Source oder die Include-Option beim Compilieren muss anders sein. Wenn das auf Windows funktioniert ist da noch etwas anders eingestellt oder Du nutzt ggf. eine andere Qt Version (welche nutzt Du eigentlich? 4 oder 5)?