borg

Die IMU kann in einer beliebigen Lage stehen, das kannst du alles mit einer Quaternion-Multiplikation wieder zurück rechnen! So wie hier: http://www.tinkerforge.com/doc/Hardware/Bricks/IMU_Brick.html#how-to-get-angles-that-are-independent unter "def make_relative_coordinates(self, x, y, z, w):"

Naja, die beiden Board-to-Board Stecker haben 60 Pinne, was meint ihr was so ein 60 Pinniges Kabel kosten würde? Da sind 6 USB Kabel und ein USB Hub um einen Faktor 10 günstiger . Desweiteren sprechen wir SPI mit sehr hoher Frequenz über die BTB Stecker. Es ist gar nicht sicher, dass dies überhaupt stabil funktionieren würde.

Mhhh, das ist eine gute Idee. Sollten wir definitiv machen .

The timeline for that depends on the quantities of the LCD20x4 Bricklets we sell. We currently have about 1000pcs in stock, the next batch will have the new features. We can't throw these 1000 circuit boards away to introduce the a feature faster. That is financially not possible for us .

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.