batti Geschrieben August 16, 2012 at 05:03 Geschrieben August 16, 2012 at 05:03 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. Zitieren
M4ST3R Geschrieben August 16, 2012 at 09:06 Geschrieben August 16, 2012 at 09:06 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. Zitieren
Loetkolben Geschrieben August 17, 2012 at 09:40 Geschrieben August 17, 2012 at 09:40 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 Zitieren
ArcaneDraconum Geschrieben August 17, 2012 at 09:55 Geschrieben August 17, 2012 at 09:55 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... Zitieren
borg Geschrieben August 17, 2012 at 09:58 Autor Geschrieben August 17, 2012 at 09:58 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 ). Zitieren
borg Geschrieben August 17, 2012 at 10:01 Autor Geschrieben August 17, 2012 at 10:01 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 . Zitieren
ArcaneDraconum Geschrieben August 17, 2012 at 10:10 Geschrieben August 17, 2012 at 10:10 @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. Zitieren
ArcaneDraconum Geschrieben August 17, 2012 at 10:12 Geschrieben August 17, 2012 at 10:12 @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. Zitieren
Loetkolben Geschrieben August 17, 2012 at 16:18 Geschrieben August 17, 2012 at 16:18 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 Zitieren
ArcaneDraconum Geschrieben September 6, 2012 at 07:49 Geschrieben September 6, 2012 at 07:49 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? Zitieren
borg Geschrieben September 6, 2012 at 09:54 Autor Geschrieben September 6, 2012 at 09:54 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! Zitieren
ArcaneDraconum Geschrieben September 6, 2012 at 10:17 Geschrieben September 6, 2012 at 10:17 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. Zitieren
FlyingDoc Geschrieben September 28, 2012 at 17:48 Geschrieben September 28, 2012 at 17:48 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. Zitieren
borg Geschrieben September 28, 2012 at 21:19 Autor Geschrieben September 28, 2012 at 21:19 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. Zitieren
FlyingDoc Geschrieben September 28, 2012 at 21:33 Geschrieben September 28, 2012 at 21:33 Also im shop ist es bestimmt nicht mehr. Habs grad weggekauft. Zitieren
photron Geschrieben October 1, 2012 at 16:44 Geschrieben October 1, 2012 at 16:44 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. Zitieren
AuronX Geschrieben October 1, 2012 at 16:48 Geschrieben October 1, 2012 at 16:48 Bitte Doku updaten (habe gerade C# geschaut und die ist alt) Zitieren
photron Geschrieben October 1, 2012 at 18:04 Geschrieben October 1, 2012 at 18:04 Bitte Doku updaten (habe gerade C# geschaut und die ist alt) Done. Zitieren
borg Geschrieben October 1, 2012 at 18:04 Autor Geschrieben October 1, 2012 at 18:04 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. Zitieren
FlyingDoc Geschrieben October 1, 2012 at 19:57 Geschrieben October 1, 2012 at 19:57 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 Zitieren
photron Geschrieben October 1, 2012 at 21:26 Geschrieben October 1, 2012 at 21:26 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 . Zitieren
FlyingDoc Geschrieben October 2, 2012 at 06:55 Geschrieben October 2, 2012 at 06:55 Na sowas aber auch. Soll ich den Fehler mal eliminieren? Hatte gestern Abend keine Lust dazu. Habs nur mal kurz überflogen. Zitieren
photron Geschrieben October 2, 2012 at 10:04 Geschrieben October 2, 2012 at 10:04 Problem in bricklet_gps.c ist behoben und ich habe auch herausgefunden warum die Datei mit im ZIP war obwohl sie nicht sollte. Zitieren
Nic Geschrieben October 2, 2012 at 10:28 Geschrieben October 2, 2012 at 10:28 Ein GPS-Bricklet :P, prima, wann solls das geben ? Zitieren
photron Geschrieben October 2, 2012 at 10:36 Geschrieben October 2, 2012 at 10:36 Die Timeline sagt KW45 für GPS Bricklet. Im Moment testen wir einen Prototypen. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.