borg

Alle Funksteckdosen die in der Dokumentation zusammengetragen sind haben A-D und 1-5 als DIP Switch, also 29 = 512 mögliche Adressen.

Grundsätzlich ist der Plan das es viele unterschiedliche Firmwares für die Hardware geben wird. Die Hardware heißt "Remote Bricklet". Die erste Firmware wird die "Remote Switch Bricklet"-Firmware sein, damit kann man dann Funksteckdosen steuern (ein paar unterstützte Geräte gibt es auch schon in der Doku: http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Remote_Switch.html#liste-unterstutzter-gerate). Als nächstes könnte ich mir gut eine "Remote Weather Bricklet"-Firmware vorstellen, welche die Temperatur von Standard-Außensensoren auslesen kann. Bzgl. der Frequenz: Der RFM69HW kann auf unterschiedlichen Frequenzen genutzt werden, unser Design und die dabeiliegende Antenne ist aber auf 433MHz ausgelegt.

Unfortunately i can't find any information on that in the manufacturer datasheet: www.jst-belgium.be/downloads/series/eSH_3.pdf‎ But we have Master Bricks here that are used for flashing that have Bricklets connected/disconnected to them several thousand times and they still work OK. No! In general Bricklet hotplug is not possible. It is only recommended in situations where a broken firmware is on a Bricklet and it needs to be reflashed with a working firmware.

+1 dafür! unbedingt *Trommelwirbel*... http://www.tinkerforge.com/de/doc/Low_Level_Protocols/Wireshark_Dissector.html

Ich denke es spricht nichts dagegen eine der Ubuntu brickv Versionen auf Debian zu installieren: add-apt-repository 'deb http://ppa.launchpad.net/borg/ppa/ubuntu saucy main' Ich befürchte auf launchpad kann man kein PPA für Debian direkt aufsetzten. Da bräuchten wir also ein eigenes Repository (was natürlich auch nicht unmöglich ist, nur mehr Aufwand ).

Nachdem ich ein Ubuntu PPA für pyqwt einrichten musste (http://www.tinkerunity.org/forum/index.php?topic=1933.0) hab ich nun zum testen auch brickv dort hochgeladen: https://launchpad.net/~borg/+archive/ppa Falls jemand von euch Ubuntu verwendet und Zeit zum Testen hat würde ich mich über Feedback freuen. Am besten ihr entfernt erst den alten brickv: sudo apt-get purge brickv und installiert dann brickv über das ppa: sudo add-apt-repository ppa:borg/ppa sudo apt-get update sudo apt-get install brickv Falls es da keine unvorhergesehenen Probleme gibt werde ich auch noch brickd zum PPA hinzufügen und das ganze automatisieren damit dort immer die aktuellste "stable" Version online ist. Das vereinfacht dann den Aktualisierungsprozess auf Ubuntu erheblich .

Die Bricks benutzen USB Geräteklasse FF, evtl muss man dafür extra etwas freischalten o.ä. in VMware? Wir benutzen hier VirtualBox um unterschiedliche Windows Versionen zu testen, das funktioniert problemlos.

Cool! Die Toolchain ist direkt aus GCC trunk gebaut? Falls das so ist sollten wir definitiv von der CodeSourcery Toolchain umsteigen, ich werde da mal ein paar Tests machen .

Schreib bitte eine Email mit der Bestellnummer und einen Link zu diesem Thread an info@tinkerforge.com, wir tauschen das LCD Bricklet dann aus.

OK, bin der Sache jetzt auf den Grund gegangen. Das Problem ist einfach eine Änderung an der sip API. Das python-qwt5-qt4 Paket wurde nicht korrekt neu gebaut nachdem die API sich verändert hatte. Die Source des Pakets ist OK. Ich hab ein debdiff an den Bugreport angehängt mit dem sich das Paket fixen lässt, allerdings ist das aufwändig Updates in einem Ubuntu-Release einzupflegen. Ich vermute das sich da so direkt keiner finden wird der den Papierkram auf sich nimmt. Für die Zwischenzeit hab ich ein PPA mit dem gefixten Paket erstellt: https://launchpad.net/~borg/+archive/ppa Auf die gefixte Version einfach updaten mit: sudo add-apt-repository ppa:borg/ppa sudo apt-get update sudo apt-get upgrade Damit funktioniert brickv dann wieder in Ubuntu 13.10. Sorry für die Probleme. Ist blöd gelaufen, wenn wir uns da drum gekümmert hätten bevor 13.10 released war, hätte man das Paket sehr einfach neu bauen können .

Grundsätzlich fällt mir da auf das die SSIDs nicht übereinstimmen. Anhand der SSID weiß die WIFI Extension mit welchem AP sie sich verbinden muss. Evtl könnte auch das Apostroph Probleme machen? Sollte es eigentlich nicht, wäre aber ein Versuch Wert die SSID auf etwas ohne Sonderzeichen zu ändern (nur zum testen). Der Hostname ist übrigens dazu da die Extension direkt über einen Namen ansprechen zu können, genauso wie bei einem PC. D.h. mit du kannst "connect" dann auf dem Hostnamen anstatt auf der IP aufrufen (die sich ändern kann). Ja, keine Panik . Nicht funktionierende Bricks nehmen wir natürlich zurück oder tauschen sie aus. Solange du auf einem Brick nichts mutwillig zerstört hast kannst du den auch nach 14 Tagen noch zurückgeben.

There is no hard date yet, but it will be released before christmas .

Kannst du mal ein Screenshot von den Einstellungen der WIFI Extension und von den relevanten Einstellungen der Fritz Box machen?

Guck mal ob vielleicht eines der Beinchen im Bricklet Stecker krumm ist (vom Master Brick oder vom LCD 20x4 Bricklet), das könnte ja unabhängig vom Kabel sein und könnte auch das Problem erklären.

Aktuell wird der Text nirgends zwischengespeichert in der Firmware, ich bin mir auch nicht sicher ob wir noch genug RAM übrig haben dafür. Allerdings sollte man auch vom LCD zurücklesen können, das haben wir allerdings bisher noch nicht gemacht. Ich schreibe es mir mal auf die TODO-Liste.

So, ich hab jetzt hier auch auf 13.10 geupdated und ich habe das gleiche Problem. Hab auf launchpad einen Bugreport gemacht: https://bugs.launchpad.net/ubuntu/+source/pyqwt5/+bug/1243102 Sieht so aus als wäre das python-qwt5-qt4 Paket einfach fehlerhaft gebaut worden.

Du kannst nicht zwei Funktionen mit dem gleichen Namen haben ("cb_temperature"). Nenne doch einfach die zweite Funktion in cb_temperature_ptc um, o.ä.

Die Delphi Bindings sind thread-safe, VCL ist aber nicht thread-safe. Da können wir allerdings nichts gegen machen. Wir müssen den Callback ja aus einem anderen Thread heraus aufrufen, wie soll das sonst gehen?

Da gibt es kein Argument, WEP ist nicht sicher: http://www.wardriving-forum.de/wiki/Aircrack-Tutorial/WEP_mit_Client Das GS1011MEES unterstützt im AP Modus leider kein WPA. Ich füge später in der Dokumentation einen Hinweis hinzu das WEP nicht sicher ist. Im nachhinein zu deaktivieren ist vermutlich keine gute Idee, das hätten wir dann von Anfang an machen müssen .

Hast du schonmal in die Datei reingeguckt, sieht das Sinnvoll aus darin? Sieht so aus als hätte der Brick Viewer ein Problem damit die Datei zu parsen. Welches Betriebssystem nutzt du? Dann testen wir das hier mal.

Ich befürchte die ist für Infrarot, da geht nicht viel Licht durch .

Das klingt für mich so als wäre einfach die Verbindungsqualität sehr schlecht. Wie weit ist denn der Stack vom Notebook entfernt? Kannst du dich mit der Fritz Box verbinden wenn du den Stack direkt neben die Fritz Box setzt (nur zum testen)? Ist die Antenne richtig drangeschraubt?

Du könntest mal gucken ob vielleicht einer der Pinne im Bricklet Stecker (am Master oder am Bricklet) krumm ist: http://www.tinkerforge.com/de/doc/_images/bricklet_connector_short_circuit.jpg Ein Kurzschluss zwischen dem Analog Pin und Masse könnte das Problem erklären.

Ich nehme an im Gerätemanager taucht auch nichts auf wenn du den Master anschließt? Ist denn irgendein Defekt zu erkennen (Bauteil abgebrochen o.ä.)? Grundsätzlich sind alle Bricks einmal getestet worden bevor wir sie verschicken, also kann es eigentlich nur ein Transportschaden oder evtl. ein Wackelkontakt sein, Schick eine Email mit der Bestellnummer an info@tinkerforge.com, wir tauschen den Master dann aus.

Du setzt immer alle Relais gleichzeitig. Angenommen du hast die Relais 1 und 2 an, dann ist der aktuelle Wert 6 = 21 + 22. tinkerforge call industrial-quad-relay-bricklet $uid set-value 6 Wenn du nun Relais 1 ausschalten möchtest setzt du den Wert 4 = 22. tinkerforge call industrial-quad-relay-bricklet $uid set-value 4 Vielleicht könnten auch die beiden Wikipediaartikel hier helfen: http://de.wikipedia.org/wiki/Dualsystem http://de.wikipedia.org/wiki/Bitmaske