August 16, 2012 at 05:03 AMAug 16, 2012 Danke für den Hinweis AuronX, werde ich den Jungs gleich mal vorschlagen. Bzgl. TCP/IP, das stellt kein Problem dar. Haben es auf dem Raspberry Pi getestet. Eine reine C Implementierung schafft ohne Ende Nachrichten (>10.000/Sek). Das Stellt kein Flaschenhals dar. Testet man dies allerdings mit Python, so ist man schon wieder in der Nähe von 1.000/Sek. Und da kommt beim Brickd natürlich noch der USB Kram und das Messagehandling dazu.
August 16, 2012 at 09:06 AMAug 16, 2012 Um noch mal die Geschichte des Quadcopers anzusprechen. Denke über eine Implementierung mit dem PI hat man keine Chance! Ist einfach viiiel zu langsam. Da muss man sich eine Microcontroller Steuerung nehmen und über IC2 ansprechen. Ansonsten summieren sich die Latenzen von Auslesen + Auswerten + Signal an Motor etc auf eine zu hohe Zeit. Ein Quadcopter muss aber regelmäßig nachjustieren. Für autonome Flugmodelle könnte es reichen.
August 17, 2012 at 09:40 AMAug 17, 2012 Hallo zusammen, ist es moeglich die C- und Quadrokopterreaktionszeit-Detaildiskussion hier raus zu lassen? :) Ich wuerde mich aus Wetterstationssicht fuer das guenstige Bricklet entscheiden, da ich ggf. mehrere nutzen wuerde. Der Sensor sollte aus meiner Sicht vollkommen ausreichend sein. Das Argument von ArcaneDraconum auch die Temperatur abfragen zu koennen, wuerde mich ggf. aber auch zum teureren greifen lassen. Da bin ich wieder bei meinem Thema: Humiditybricklet nur noch direkt mit Temperatursensor anbieten. Zustimmung auch von meiner Seite zu Platinengroesse, die mit den anderen Bricklets stapelbar sein sollte. Hat der Sensor eine Oeffnung? Kann man den auf der Platine so anbringen, dass er nicht vollstaubt? Mein Humidity Bricklet habe ich als einziges Bricklet mit dem Sensor nach aufgeschraubt, damit die Oeffnung nicht zustaubt. Der Loetkolben
August 17, 2012 at 09:55 AMAug 17, 2012 Ich weiss, das ganze ist nun etwas überdreht, aber wie wäre es mit einem Wetterstationsbrick - so wie der IMU. Mit Temperatur-, Druck-, und Feuchtesensor. Event. noch der Lichtsensor drauf. Damit wäre schon eine gte Grundlage für ne Wetterstation geschaffen. Dazu noch 2-4 Brickletports für AnanlogIn und IO-x um externe Sensoren abzufragen. Fertig. Das Ding darf dann auch preislich in der IMU-Region sein...
August 17, 2012 at 09:58 AMAug 17, 2012 Author Hat der Sensor eine Oeffnung? Kann man den auf der Platine so anbringen, dass er nicht vollstaubt? Mein Humidity Bricklet habe ich als einziges Bricklet mit dem Sensor nach aufgeschraubt, damit die Oeffnung nicht zustaubt. Die Barometer Sensoren haben eine ähnliche Öffnung wie das Humidity Bricklet. Zum Thema Temperatur: Die würde ich wieder eher als eine "Chip Temperature" ansehen, wie bei den Bricks. Die Temperatur auf dem Temperature Bricklet ist um eine Größenordnung genauer. Wenn wir die beiden nebeneinander legen, sieht man durchaus schonmal einen Grad unterschied! Für eine Wetterstation also vielleicht nicht zu verwenden (kommt natürlich drauf an wie genau man es nimmt ).
August 17, 2012 at 10:01 AMAug 17, 2012 Author Ich weiss, das ganze ist nun etwas überdreht, aber wie wäre es mit einem Wetterstationsbrick - so wie der IMU. Mit Temperatur-, Druck-, und Feuchtesensor. Event. noch der Lichtsensor drauf. Damit wäre schon eine gte Grundlage für ne Wetterstation geschaffen. Dazu noch 2-4 Brickletports für AnanlogIn und IO-x um externe Sensoren abzufragen. Fertig. Das Ding darf dann auch preislich in der IMU-Region sein... Kann man vielleicht irgendwann machen, ich denke wir sollten uns aber erstmal auf neue Produkte konzentrieren und erst wenn das Sortiment "vollständig" ist anfangen gleiche Produkte in anderen Ausführungen bereitzustellen .
August 17, 2012 at 10:10 AMAug 17, 2012 @borg: zum Glück hast Du "vollständig" geschrieben. Euer Sortiment wird nie wirklich vollständig sein. Wenn ich hier im Forum lese, wie viele Ideen da rumgeistern - und das im positiven Sinne. Allerdings werden wohl nicht alle Ideen - für Euch interessante - Srückzahlen abwerfen.
August 17, 2012 at 10:12 AMAug 17, 2012 @borg: Noch eine Anmerkung zur Anmerkung vom Lötkolben: Wer eine relative Luftfeuchtigkeit misst, wird sich eigentlich auch immer für die Temperatur interessieren. Darum wäre diese Kombi nicht ohne. Falls es mal ein Humidity V2 gibt. Ein separates Temp. wird man auch immer brauchen können.
August 17, 2012 at 04:18 PMAug 17, 2012 Hallo ArcaneDraconum, ich danke fuer Unterstuetzung meiner Idee Humidity+Temperatur zusammenzufassen. Noch etwas zu Sache: Da ich es nicht genau beurteilen kann moechte ich folgende Frage stellen: Ist der genauer aufloesende Sensor ueberhaupt fuer den hier geaeusserten Verwendungszweck geeignet oder ist das nun eine Vermutung, weil er mehr Geld kostet? Der Loetkolben
September 6, 2012 at 07:49 AMSep 6, 2012 Guten Tag liebes TF-Team, ich möchte mal diesen Thread wiederbeleben. Wird das Barometerbricklet das New Bricklet in KW39 sein? Für welchen Sensor habt Ihr Euch entschieden?
September 6, 2012 at 09:54 AMSep 6, 2012 Author Wir werden den teuren Sensor nehmen, der hat ja doch mit Abstand am meisten Zuspruch gefunden hier im Thread. Leiterplatten wurden heute bestellt, KW 39 klingt also sehr realistisch!
September 6, 2012 at 10:17 AMSep 6, 2012 Na prima. Bis dahin sollte ja auch die WiFi-Extension verfügbar sein. Ich hoffe zumindest, dass sie bis dahin NOCH verfügbar ist und Ihr nicht gleich ausverkauft seid. Sonst ist ja schon die nächste Enttäuschung vorprogrammiert. :'( Hätte nie gedacht, dass Programmieren so einfach ist.
September 28, 2012 at 05:48 PMSep 28, 2012 Ich hab im Changlog zim Viewer gesehen,das ihr das Barometer Bricklet eingebaut habt. Wann kann man damit rechnen? Hab mir grad mal die API dazu angeschaut. Als Höhenmesser ist die Funktion ja auch eingebaut. Ebenso eine Kalibrierungsfunktion für den Höhenmesser. Ich nehme an die Funktion nimmt denn aktuellen Luftdruck als Nullpunkt für die Höhe und rechnet von da aus. Wäre es schwierig noch eine Funktion einzubauen wo man den Referenzdruck (QNH) selber angeben kann? In der Fliegerei wird ja der Höhenmesser immer auf MSL gerechnet. Mann müsste also den QNH übergeben können um die richtige Höhe zu bekommen.
September 28, 2012 at 09:19 PMSep 28, 2012 Author Ist jetzt im Shop . Übergeben des QNH ist im Moment nicht drin, wir hatten Probleme die maximale Plugin Größe für die Bricklets (4kb) einzuhalten. Das einzige was mir dazu einfällt, ist vielleicht beim calibrate den Luftdruck angeben zu können und 0 zu nutzen um ihm auf den aktuellen zu setzen. Mhh, würde jetzt natürlich die API brechen wo sie schon veröffentlicht ist. Mal schauen ob wir da am Montag noch schnell einbauen bevor die ersten Barometer Bricklets angekommen sind . Aber wenn wir es nicht mehr reinkriegen kann man das ja auch vergleichsweise einfach extern berechnen.
September 28, 2012 at 09:33 PMSep 28, 2012 Also im shop ist es bestimmt nicht mehr. Habs grad weggekauft.
October 1, 2012 at 04:44 PMOct 1, 2012 Wir haben uns angestrengt und noch genug Platz freibekommen um in Barometer Bricklet Plugin 1.1.0 eine SetReferenceAirPressure Funktion einzubauen, über die du von außen den Referenzluftdruck für die Höhenberechnung setzen kannst. Die alte Funktionalität von CalibrateAltitude ist als SetReferenceAirPressure(0) weiterhin vorhanden.
October 1, 2012 at 06:04 PMOct 1, 2012 Bitte Doku updaten (habe gerade C# geschaut und die ist alt) Done.
October 1, 2012 at 06:04 PMOct 1, 2012 Author Kurzer Hinweis: Wir haben heute schon ca. ~25 Bestellungen mit Barometer Bricklet gepackt die morgen rausgehen, die sind jetzt natürlich noch auf Firmware Version 1.0 und müssen erst geupdatet werden um dieses Feature zu haben! Alle Bestellungen die heute reingegangen sind und danach bekommen gleich die neue Firmware Version.
October 1, 2012 at 07:57 PMOct 1, 2012 Roger Vicktor Wieder einmal schnell reagiert wie man es bei euch gewohnt ist! Mal noch ne Frage. Hab ja schon die Bindings für das GPS gesehen. Ihr gebt ja nur die Positionsdaten zurück. Ein GPS Chip liefert aber noch mehr in seinen Datenstrom. Zum Beispiel die errechnete Geschwindigkeit und Richtung. Warum liefert ihr diese Daten nicht mit? Tante Edit sagt: Beim compilieren des Programmes mit dem bricklet_gps kommt folgender Fehler. 1>.\bricklet_gps.c(367) : error C2664: 'void (char,uint16_t,char,uint16_t,uint16_t,uint16_t,uint16_t)': Konvertierung des Parameters 4 von 'uint16_t [2]' in 'uint16_t' nicht möglich
October 1, 2012 at 09:26 PMOct 1, 2012 Mal noch ne Frage. Hab ja schon die Bindings für das GPS gesehen. Eigentlich sollten die noch garnicht mit released werden. Ihr gebt ja nur die Positionsdaten zurück. Ein GPS Chip liefert aber noch mehr in seinen Datenstrom. Zum Beispiel die errechnete Geschwindigkeit und Richtung. Warum liefert ihr diese Daten nicht mit? Tun wir doch, siehe speed und course in GetStatus. Tante Edit sagt: Beim compilieren des Programmes mit dem bricklet_gps kommt folgender Fehler. 1>.\bricklet_gps.c(367) : error C2664: 'void (char,uint16_t,char,uint16_t,uint16_t,uint16_t,uint16_t)': Konvertierung des Parameters 4 von 'uint16_t [2]' in 'uint16_t' nicht möglich Da hast du wohl einen Bug im Generator gefunden. Bisher wurde per Callback noch nie ein Array übergeben, daher ist das bis jetzt nicht aufgefallen. Das GPS Bricklet ist eben noch in Arbeit .
October 2, 2012 at 06:55 AMOct 2, 2012 Na sowas aber auch. Soll ich den Fehler mal eliminieren? Hatte gestern Abend keine Lust dazu. Habs nur mal kurz überflogen.
October 2, 2012 at 10:04 AMOct 2, 2012 Problem in bricklet_gps.c ist behoben und ich habe auch herausgefunden warum die Datei mit im ZIP war obwohl sie nicht sollte.
October 2, 2012 at 10:36 AMOct 2, 2012 Die Timeline sagt KW45 für GPS Bricklet. Im Moment testen wir einen Prototypen.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.