borg

Over USB this is not possible. The kernel of your operationg system polls the USB device 1000 times per second, that is specified in the USB standard. There is no way around that. You would have to write you own C firmware to achieve higher read out rates. The microcontroller can read and convert adc values with a frequency of max 6MHz.

Du meinst mit dem Mini-Arduino Bricks steuern? Gehen tut das sicherlich (am Debug Brick anschließen und die Brick Firmware dafür abändern). Ob das so schrecklich Sinnvoll ist weiß ich aber nicht. Alles was du auf dem Ding programmieren könntest, könntest du auch direkt auf dem Brick . Man könnte damit natürlich ganz Einfach unsere Bricklets ansteuern! Dazu einfach ein Bricklet an ein Breakout Bricklet stecken und die entsprechenden Pinne (AD oder I2C) mit dem Arduino verbinden .

Also grundsätzlich wird jedes Bricklet Plugin 1000x pro Sekunde aufgerunfen. Dies macht sehr viel Sinn, da USB auch mit dieser Frequenz abfragt. Um so einen Frequenzmesser zu implementieren müssten wir also echte Hardwareinterrupts vom Microcontroller nehmen. Damit ist das in Theorie ohne Probleme möglich. Aber... Je nach Brick wird das mehr oder weniger gut funktionieren. Zum Beispiel spricht das IMU Brick nahezu durchgängig I2C oder macht Berechnungen die nicht unterbrochen werden dürfen. Dort würde der Interrupt also fast immer unterdrückt und das ganze funktioniert nicht mehr richtig. Alternativ hätte der IO4 Interrupt eine höhere Priorität und das IMU liefert kaputte Daten. Auch nicht gut. Sprich wir hätten auf einmal Funktionalität die nur auf bestimmten Bricks gut funktioniert und vielleicht auch nicht mehr mit anderen Bricklets zusammen usw usw. Die Gedanken intern etwas mit hoher Frequenz Interrupt basiert zu implementieren hatten wir schon oft, allerdings ist das Aufgrund der extremen Modularität nur schwer umzusetzen ohne die Stabilität zu gefährden. Ich schreibe es trotzdem nochmal auf die TODO Liste und gucke es mir nochmal an. Mitzählen wie oft es High->Low oder Low->High Flanken gab könnte man evtl noch irgendwie hinbekommen. Das ganze mit Zeitstempel ist aber sehr schwierig. Wie würde die API dazu aussehen? Denkt dran, dass unsere Nachrichten intern immer eine feste Länge haben.

Och, wie niedlich .

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!