borg

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 .

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 ).

Also wenn du ein andere Kabel für das LCD20x4 nimmst ist es OK? Oder ist es OK wenn du ein anderes Bricklet mit gleichem Kabel nimmst? Worauf ich hinaus will: Ist eine der Buchsen "ausgeleiert" oder ist einer der Stecker "ausgeleiert"?

Before you update the Master Brick firmware this problem wasn't there? What are the other Bricklets on the Master, is there a Dual Relay on there too?

Ja, sowas kann man auf Dauer machen, etwas ähnliches ist auch für DC/Stepper Brick und Inkrementalgeber Bricklets geplant.

Jop, das wird passen! Ich bin überrascht, dass doch so viele die mehr als doppelt so teure Variante vorziehen. Deutet ja im Moment alles stark darauf hin als sollten wir den MS5611-01BA benutzen. Ich denke wir werden mal einen kleinen Mockup aus IMU und MS5611-01BA bauen, wo aus Beschleunigungssensor-Werten und den Daten vom MS5611-01BA die höhe bestimmt wird. Das sollte dann natürlich auch gut funktionieren, sonst ist am Ende die Enttäuschung groß .

Hallo zusammen, wir können uns bezüglich des Sensors für das zukünftige Barometer/Altimeter Bricklet nicht einig werden. Wir haben folgende zwei Sensoren in der Endauswahl: MS5611-01BA: Auflösung: 0,01mbar (bei Verwendung als Altimeter 10cm) Wird von Quadrocopter Projekte zur Höhenbestimmung genommen (http://code.google.com/p/arducopter/) allerdings in Verwendung mit Kalmanfilter und Beschleunigungssensor-Werten Datenblatt: http://www.meas-spec.com/downloads/ms5611-01ba01.pdf Verkaufspreis: 21,99€ MPL115A1: Auflösung: 0,1mbar (bei Verwendung als Altimeter 100cm) Sehr wahrscheinlich nicht als Altimeter für Flugdrohnen verwendbar Datenblatt: http://www.freescale.com/files/sensors/doc/data_sheet/MPL115A1.pdf Verkaufspreis: 9,99€ Was meint ihr? Wir würden Momentan Aufgrund von endlicher Zeit und endlichen finanziellen Mitteln nur eine der beiden Varianten machen können!

Das wird wieder irgendeines von diesen Problemen zwischen Dual Relay und LCD 20x4 Bricklet sein. Ich befürchte, dass die Spannung beim LCD einfach zu weit absinken wenn du die Relays schaltest. Benutzt du eine Step-Down Power Supply? Ein USB Port liefert nunmal leider nur 500mA. Falls nicht könnte es hier evtl. schon etwas bringen wenn du die beiden Master einzeln per USB anschließt und an dem einen die Relais und den anderen das LCD 20x4 machst.

Mh, auf Durchsatz hatte ich jetzt nicht getestet, muss ich mal vergleichen.

@kuli: USB wird 1x pro ms gepollt vom Linux Kernel (oder auch von Windows, ist so im Standard definiert). Die Antwort auf ein getter ist immer direkt beim nächsten polling vom PC fertig. D.h. so eine Anfrage dauert minimal 1ms und maximal 2ms, je nachdem wo du dich gerade in diesem Abfragefenster befindest. Deswegen schreiben wir überall das unbedingt wenn möglich die Callbacks benutzt werden soll, da ist dann die absolut maximale Latenz nach auftreten eines Events 1ms, im Schnitt 500us.

Naja, wir müssen zwischen "Datenrate" und "Durchsatz" unterschieden. Die WIFI Extension hat eine höhere Datenrate als USB. Aber wenn du nun getter aufrufst, ist die Datenrate fast irrelevant. Interessant ist die Zeit die es dauert bis ein Paket vom PC beim Brick angekommen ist und wieder zurück (Round Trip Time). Hier ist WLAN natürlich langsamer als USB (aber immernoch viel schneller als Chibi).

Sind die 2-3 Sekunden von Programmstart bis Programmende? Im laufenden Programm sollte so eine Abfrage keine 2-3 Sekunden dauern, auch nicht mit Java.

Das wird nichts werden, dafür fehlt zum einen der Platz auf der Leiterplatte und zum anderen müssten wir dafür immer zwischen Command-Modus und Daten-Modus hin und her wechseln, dann schaffen wir noch weniger Durchsatz.

Wir haben schon ein Barometer/Altimeter-Bricklet Prototyp hier rumliegen. Es basiert auf dem MS5611-01BA01: www.meas-spec.com/downloads/ms5611-01ba01.pdf

Gibt jetzt eine Master Brick Firmware Version 1.2.4. Ich hab jetzt mit dem Aufbau im Anhang getestet, 5 Bricks und 10 Bricklets. Ich lasse den Aufbau mit JTAG Debugger und Logic Analyzer usw. erstmal hier für eine Woche oder so liegen, falls es noch irgendwelche Probleme gibt bitte einmal beschreiben wie ich meine Aufbau abändern muss um das Problem nachzustellen . Getestet hab ich mit 9600 Baud, 19200 Baud, 1 MBaud und 2 MBaud.

Gibt jetzt Master Brick Firmware Version 1.2.4, bitte einmal damit probieren .

Gibt jetzt Master Brick Version 1.2.4, bitte damit einmal probieren!

Firmwares: Master Brick 1.2.4 Send empty message if slave has timeout, to allow slave to process buffer Download Firmwares: Master Brick

Firmwares: Master Brick 1.2.4 Sende leere Nachricht falls RS485 Slave einen timeout hat, dadurch kann ein voller Buffer beim Slave abgearbeitet werden Download Firmwares: Master Brick

Das IMU Plugin vom Brick Viewer benutzt OpenGL, das ist der einzige Unterschied der mir zu anderen Bricks/Bricklets einfällt.

Ui, es gibt schon den ersten Pull Request mit Übersetzungen: https://github.com/Tinkerforge/generators/pull/16 . Was meint ihr wie wir unterschiedliche Sprachen in der Dokumentation behandeln sollen? Ich hab im Pull Request etwas dazu geschrieben.

@ArcaneDraconum: Da geben wir dir absolut recht! Ein gutes Gehäuse würde vermutlich auch einige der ESD Probleme lösen die hier ein paar Leute haben. Auf Dauer müssen Gehäuse her. Die Frage ist was so ein Gehäuse kosten darf und auch ob der Formfaktor den wir gewählt haben da überhaupt für geeignet ist... Wir haben gerade ein Projekt für einen Industriekunden fertiggestellt, welches in einem hübschen Hutschienengehäuse verbaut wird. Leider scheinen mir die Stackbarkeit und die Bricklet Ports nur schwer mit den Standard Hutschienengehäusen vereinbar zu sein .

@chariowalda: Der OMAP3730 Ist ja erstmal nur ein Prozessor. Das von mir verlinkte Breakout Board hat aber schon die ganze externe Beschaltung usw drauf. Ein kleiner Fehler bei der Beschaltung und so eine CPU im Ghz Bereich strahlt wie ein Weltmeister . Die externe Beschaltung für den OMAP3730 könnten wir uns zwar vom Beagleboard-xM abgucken, aber leider hat TI da kein Interesse dran. Wir haben schonmal mit TI darüber gesprochen (bzgl des OMAP3530). Für die ist eine Abnahmemenge von 1000 Stück uninteressant. Für uns wäre das aber schon das absolute Maximum... So ein Breakoutboard was zwischen unsere Board-to-Board Stecker passt und von einer Drittfirma kommt die davon wiederum große Stückzahlen macht wäre für uns absolut perfekt!

Eine kurze Googlesuche hat mir das hier rausgeworfen: http://www.co2meter.com/products/k-30-co2-sensor-module Das sollte man an ein Analog In Bricklet anschließen können.

Also du möchtest etwas haben über das du mit einem Arduino kommunizieren kannst? Oder möchtest du direkt I2C Sensoren ansteuern, z.B. über das Breakout Bricklet? Über ein Arduino mit einem I2C Sensor zu kommunizieren ist ein bisschen von hinten durch die Brust ins Auge . Die Bricks haben mehr Rechenleistung, mehr RAM, mehr Flash als die meisten Arduinos. Was fehlt ist das "On Device Programming Interface". Unser inoffizieller Schlachtplan dafür ist folgender: Warten bis das Arduino Due raus ist: http://www.heise.de/hardware-hacks/meldung/Neue-Arduino-Mikrocontroller-Boards-1346308.html Arduino API für den Cortex M3 für unsere Bricks kompatibel machen und unseren Code mit der API neuschreiben API (basierend auf der Arduino API) für die Funktionalität der Bricks/Brickelts bereitstellen Damit erfinden wir zum einen das Rad nicht neu (Die Arduino Jungs sind ja ganz offensichtlich sehr gut daran einfach zu bedienende API zu machen und sie sind gerade dabei es für unsere CPU zu machen). Und zum anderen können die ganzen Arduino Beispiele dann auch auf unseren Bricks ausgeführt werden. Falls es darum geht I2C Sensoren direkt vom PC aus anzusteuern: Für bestimmte Kategorien von I2C Sensoren ist das sicherlich möglich, so ganz Allgemein ist wäre das allerdings sehr schwierig. Dafür ist USB leider einfach nicht gut geeignet .