borg

Komisch, ist mir bisher noch nicht aufgefallen. Hab auch gerade ein paar Threads durchgeguckt und hab nichts auffälliges gefunden .

Sieht interessant aus. Wenn ich das richtig sehe benutzt der TM1829 ein sehr ähnliches Protokoll wie der WS2801. Es verwendet allerdings keine Clock-Leitung sondern fest definierte Timings die man einhalten muss. Das interpretiere ich zumindest aus dem Datenblatt, aber mein Chinesisch ist ein bisschen eingerostet... Beim schnellsten Timing braucht man 7.2ms um einen "Frame" zu schreiben. Das ist natürlich leider ein bisschen langsam für ein Bricklet, wenn man das implementiert würde das LED Strip Bricklet an der Stelle andere Bricklets ausbremsen. Wäre aber vielleicht trotzdem eine Überlegung Wert auch das TM1829-Protokoll zu implementieren. Günstiger sind die Streifen natürlich, aber dafür kann man dann auch nur immer drei Pixel im Tandem kontrollieren.

Aus Deutschland gibt es die WS2801 Streifen auch noch im Shop von "led-studien.de": http://shop.led-studien.de/

12V ist kein Problem, dafür haben wir es extra ausgelegt.

Interessant. Anhand des Bildes sieht es so aus als wäre da ein IC pro drei RGB LEDs drauf. D.h. es werden vermutlich immer 3 LEDs die gleiche Farbe anzeigen. Vielleicht verwenden die eine LPD6803? Der könnte sowas. Kann man natürlich nur raten anhand vom Bild. Einen LPD6803 könnte die Hardware auch unterstützen, müsste man "nur" ein passend Bricklet Plugin für schreiben .

Das LED Strip Bricklet steuert bis zu 360 WS2801 ICs einzeln an (kein Multiplexing o.ä.): https://www.sparkfun.com/products/10444. An einem WS2801 ist für gewöhnlich eine RGB LED angeschlossen. D.h. man kann jedes Pixel einzeln ansteuern. Zur genauen Funktionsweise vom WS2801 siehe das Datenblatt bei Sparkfun. Zu den Aldi LED-Streifen: Für gewöhnlich kannst du da mit der Fernbedienung nur die Farbe des kompletten Streifen ändern und da wird vermutlich einfach 3x PWM komplett durchgeschleift. Das hat im Prinzip gar nichts mit dem LED Strip Bricklet zu tun, außer das der Name ähnlich klingt .

Hast du mal einen Link zu einer Funksteckdose mit Master ON/OFF?

Das nächste Kit was wir veröffentlichen wird die LED Pixel verwenden und entsprechend das Zubehör was man dafür benötigt ist dann auch einzeln im Shop. Da ist dann auch das Netzteil dabei. Wir die Netzteile sogar schon bestellt, die sind aber noch nicht angekommen bei uns und entsprechend auch noch nicht im Shop .

Wir haben ein paar Umrechnungen in brickv, an denen kannst du dich orientieren: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/gps/gps.py def make_ddmm_mmmmm(self, degree): dd = degree / 1000000 mm = (degree % 1000000) * 60 / 1000000.0 mmmmm = (mm - int(mm)) * 100000 dd_str = str(dd) mm_str = str(int(mm)) mmmmm_str = str(int(mmmmm + 0.5)) while len(mm_str) < 2: mm_str = '0' + mm_str while len(mmmmm_str) < 5: mmmmm_str = '0' + mmmmm_str return u'{0}° {1}.{2}’'.format(dd_str, mm_str, mmmmm_str) def make_dd_dddddd(self, degree, url=False): if url: return '%2.6f' % (degree / 1000000.0) else: return u'%2.6f°' % (degree / 1000000.0) def make_ddmmss_sss(self, degree): dd = degree / 1000000 mm = (degree % 1000000) * 60 / 1000000.0 ss = (mm - int(mm)) * 60 sss = (ss - int(ss)) * 1000 dd_str = str(dd) mm_str = str(int(mm)) ss_str = str(int(ss)) sss_str = str(int(sss + 0.5)) while len(mm_str) < 2: mm_str = '0' + mm_str while len(ss_str) < 2: ss_str = '0' + ss_str while len(sss_str) < 3: sss_str = '0' + sss_str return u'{0}° {1}’ {2}.{3}’’'.format(dd_str, mm_str, ss_str, sss_str)

Aktuell unterstützt das LED Strip Bricklet nur WS2801. Unterstützung für andere ICs ist aber geplant, möglich ist es auf jeden Fall.

Hallo Nemo, braun? Nunja, ich denke es sollte nach "Kupfer" glaenzen. Wenn das wirklich direkt die Leiterbahnbeschichtung ist, dann bin ich gespannt wie sich das nach laengerer Zeit in der Erde verhaelt. Zum Vorfreuen: Moisture Bricklet Der Loetkolben Was man da glänzen sieht ist Gold: http://en.wikipedia.org/wiki/Electroless_nickel_immersion_gold

There is no API to do that. It would be possible to turn it of by changing and recompiling the firmware.

Richtig. Das Protokoll des PT/HX2262 unterstützt in Theorie 1024 unterschiedliche Adresse, davon bieten die ganzen Steckdosen für gewöhnlich 512 an. Das Remote Bricklet selbst ist da nicht beschränkt, das kann einfach beliebige Daten im 433MHz Frequenzbereich senden/empfangen. Die meisten Intertechno Funkempfäger basieren übrigens auch auf dem HX2262, auch die Unterputz-Empfänger . Wenn du Verschlüsselung/Authentifizierung möchtest musst du sowas wie HomeMatic nehmen: http://www.elv.de/homematic-2-kanal-funk-dimmer-phasenabschnitt-aufputzmontage.html Das HomeMatic-Protokoll kann man allerdings leider nicht auf einem Bricklet implementieren, viel zu komplex.

Jo. Wenn die neuen Bricklets veröffentlicht sind werde ich mir mal eine Auswahl von günstigen 433MHz Wetterstationsaußensender kaufen (sowas: http://www.amazon.de/TFA-30-3120-90-Aussensender-mit-Display/dp/B000R9BCAG/ref=pd_bxgy_hg_img_y#productDescription) und die alle an den Logic Analyzer klemmen. Ich vermute das die meisten davon die gleichen ICs verwenden, ähnlich wie bei den Funksteckdosen.

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.