borg

3D CAD Dateien haben wir leider nicht. Die Abbildungen auf der Startseite wurden mit einem 3D Modelling Programm nach Augenmaß gemacht. Die wurden schon erstellt bevor wir die ersten Prototypen hatten . KiCAD (das Programm mit dem wir das Leiterplattendesign machen) kann zwar 3D Darstellungen, die Informationen über die Höhe der Bauteile ist allerdings nirgends hinterlegt, das bringt also nichts.

Huch? Welchen Link klickt ihr denn? Den oben rechts bei uns auf der Homepage? Der sollte eigentlich auf de.blog oder en.blog verzweigen, jenachdem was an Sprache eingestellt ist. Kann mal einer von euch versuchen zuerst auf eine der Flaggen zu klicken? Vielleicht funktioniert die Erkennung der Default Sprache bei den mobilen Geräten nicht. Wundert mich allerdings.

Kannst du mal gucken ob bei den Bricklet Steckern irgendwo in Pin Krum ist und vielleicht einen Kurzschluss macht?

Verstehst du richtig. Ein Master, Eine WIFI Extension und eine Temperature Bricklet (+ Stromversorgung) reichen z.B. aus um per Handy Schnurlos die Temperatur zu lesen (kein Brick Daemon benötigt!)

Ich schreibe heute Abend im Blog nochmal etwas genaueres zu den Gründen etc. @Paul: Die WLAN Extension wird ad hoc Modus unterstützen. D.h. du kannst z.B. direkt vom Android/Iphone/Windows Phone Handy auf die Bricks zugreifen ohne AP und ohne Brick Daemon um etwas in den Alpen zu steuern. Das ist IMO besser geeignet um mit wenig Equipment etwas zu betreiben als die Chibi Lösung!

Oh, also wieder ein Problem mit induktiven Lasten. Ich glaube das letzte mal sind wir zu dem Schluss gekommen das zwischen Relay und Last ein "Snubber" benötigt wird: http://de.wikipedia.org/wiki/Snubber Wir hatten uns auch schon überlegt ob wir das nicht direkt aufs Relay Bricklet setzen, aber dadurch würden wir natürlich die Schaltgeschwindigkeiten auch für nicht-induktive Lasten verändern. Mhhh.

Counting the stepper motor steps will definitely have a better accuracy. The problem is that the timing of the sending of the USB package depends on the scheduler of your operating system. So instead of a message every ms you might get a message in 0.8ms and the next one in 1.3ms and the next one in 0.9ms and so on. There is nothing we can do about that as long as the programming is done on one of the modern operating systems (linux/macos/windows). If you want to calculate your postion with the IMU data, these timing differences will destroy your accuracy. The calculations would have to be _very_ precise. In theory we could do the position calculations on the Brick itself. I already looked at that and tried some things. The problem is: If you use the IMU Brick together with two demanding bricklets (e.g. IO 16), we are already at the absolute limit of calculations we can do with the 64Mhz.

Neue Distance IR Firmware ist online: http://download.tinkerforge.com/firmwares/bricklets/distance_ir/ Ich habs nur ganz kurz getestet, war aber sehr zufrieden mit dem Ergebnis. Beachte: Es ist weiterhin so das nur dann ein Callback kommt wenn sich der Wert seit dem letzten Callback verändert hat. Es ist jetzt aber so das er 1x pro ms kommt wenn sich der (gleitende Mittel-)Wert auch wirklich in der letzten ms verändert hat.

Da der Joystick analog ausgelesen wird sollte das keine Probleme machen können. Kannst du mal versuchen das Problem nur mit Temeprature und LCD Bricklet nachzustellen? Und welche Firmware Versionen haben die Bricklets? Ist da alles aktuell? Klingt für mich nach einem fixbaren Software Problem.

Es gibt welche von Phoenix Contact die kompatibel sind zu unseren (sind nicht genau die gleichen, aber passen): http://de.farnell.com/phoenix-contact/fmc-1-5-4-st-3-5/stecker-frei-feder-3-5mm-4polig/dp/1792971 Conrad hat zwar reichlich Phoenix Contact Stecker im Angebot aber die kann ich auf die schnelle nicht finden im Katalog, musst du mal gucken.

In der Tat, warum bin ich da noch nicht selber drauf gekommen? Ich hab insgesamt 250 Byte pro Bricklet Plugin zur Verfügung, ich denke das Distance IR benutzt momentan sowas wie 150, da sollte also etwas machbar sein. Danke für den Tipp!

Ah, ich sehe was das Problem ist. Ich rechne bei dem Distance IR Bricklet mit Durchschnittswerten über 50 Messungen. dadurch wird der Callback nur alle 20ms aufgerufen, weil sich nur alle 20ms der Wert ändert. Die Sharp IR Sensoren haben ein starkes rauschen, deswegen die lange Durchschnittsbildung. Ich könnte allerdings ohne Probleme API hinzufügen um die Länge über die der Durchschnitt berechnet wird zu setzen. Ich baue das am Wochenende mal ein, ich meld mich dann hier nochmal wenn die neue Version hochgeladen ist.

@treaki Vielleicht haben wir aneinander vorbei geredet. Über USB geht ein Paket pro ms (da können wir nichts dran ändern). Wenn du jetzt immer Getter aufrufst (z.B. get_distance), dann geht pro Aufruf eine Nachricht hin und eine Nachricht zurück. Macht also maximal 500 Aufrufe pro Sekunde (oder 500hz = 2ms pro Nachricht). Wie ThomasKI schon sagt, mit Callbacks gibt es keine Nachricht in beide Richtungen, daher sind damit die vollen 1000 Nachrichten pro Sekunde möglich (oder 1000hz = 1khz = 1ms pro Nachricht). Du schreibst jetzt von 10khz = 10000hz = 100us pro Nachricht, das ist nicht möglich. Wenn du eigentlich meintest alle 10ms eine Nachricht (100hz) ist das natürlich Problemlos möglich! Da kannst du dann auch nebenbei noch 3 weitere Bricklets mit der gleichen Abtastrate benutzen, sogar ohne Callbacks.

Das ist leider technisch nicht möglich, über USB gehen maximal die besagten 1000 Pakete pro Sekunde.

So ein Heise oder Golem Artikel führt durchaus dazu das eine Person ganztägig verpacken kann. Dazu kommt dann noch eine Schwemme an Emails von Leute die Fragen haben. Wenn man viel verkauft muss man natürlich auch viel nachbestellen. Da möchte man dann natürlich auch mehrere Distributoren anfragen um einen guten Preis zu bekommen etc. Dazu kommt dann das ganze Testen, Flashen und Eintüten. Optimierungspotential liegt da entweder in mehr Personal oder evtl. ein auslagern des kompletten Bauteil/Leiterplatteneinkaufs und Testen/Flashen/Eintütens zum Bestücker. Sowas ist aber natürlich ein langwieriger Prozess. Das kann man nicht kurzzeitig einrichten und lässt sich dann auch nicht mehr so einfach rückgängig machen, wenn einem dann doch die Kontrolle fehlt. Die ganze Geschichte muss einfach noch ein paar Monate weiterlaufen bevor wir einschätzen könne wieviel Personal wir einstellen können und was wir outsourcen sollten oder vielleicht doch lieber selber machen sollten etc.

Der Vorteil ist das kein Stecker vorne rausguckt der im Weg sein könnte.

Bevor wir die WLAN Erweiterung in großer Stückzahl produzieren lassen sollten wir vielleicht einmal kurz vorstellen wie wir uns die Hardware vorgestellt haben: Da bei der Chibi Extension bemängelt wurde das man sie nur schwer in ein Gehäuse einbauen kann haben wir uns nun folgendes Konzept ausgedacht: Die Platine verfügt über einen fest aufgelöteten U.FL Stecker (das ist so ein Miniatur Stecker der für WLAN verwendet wird). Für diese Stecker gibt es günstige Kabel die auf SMA umsetzen. Damit ist es dann möglich den SMA Stecker in ein Gehäuse zu schrauben. Zusätzlich soll es aber natürlich auch möglich sein SMA Antennen anzuschließen ohne das ein Gehäuse benötigt wird. Dafür würden wir dann eine kleine Halterung mit einem Mini U.FL Kabel anbieten welches den SMA Stecker so nach draußen legt wie es bei der Chibi Extension der Fall ist. Was haltet ihr davon? PS: Ob wir das so machen ist auch abhängig davon ob wir so eine Halterung hinreichend günstig hergestellt bekommen, es kann also sein das wir hier über Sachen diskutieren die sich als unökonomisch herausstellen.

Ohje, wir haben sowieso noch ein langes Backlog von noch nicht verschickten Bestellungen. Wir haben vor alles noch nicht verschickte am Freitag Mittag rauszuschicken, dann kommt es am Samstag an. Ich denke das wird das erste mal sein wo der DHL Wagen öfter als 1x kommen muss weil nicht alle Pakete reinpassen . Wir sind dabei, Bastian ist gerade beim Bestücker und testet frisch produzierte IMUs . Ich befürchte allerdings das ein weiterer Ansturm mal wieder neue Features nach hinten schiebt.

Wenn von einer Batterie hohe Ströme gezogen werden sinkt die Spannung, wenn die Spannung der Batterie so hoch ist das sie über ~6V bleibt bei den Peakströmen sollte es nicht zu "Zuckungen" kommen. Allerdings sinkt die Spannung bei Batterien natürlich auch wenn sie leer werden, da kann man dann auf einmal in Probleme rennen obwohl die Batterie noch halb voll ist. Optimalerweise hält die (wie auch immer geartete) Stromversorgung natürlich die Peakströme aus.

Was soll das denn bedeuten? Möchtest du unsere Sachen mit Lego Mindstorms steuern oder soll es möglich sein mit einem Brick Lego Mindstorms Sachen zu steuern? Klingt auf jedenfall beides schwierig bis unmöglich .

Ich hab noch eine Idee, wie wäre es wenn wir die Löcher für eine Stiftleiste reinmachen? Da könnte man dann sowohl direkt etwas anlöten als auch schnell eine Stiftleiste anlöten (die können wir dabei legen). Dann haben die Leute die keine externen Knöpfe haben wollen keine Störende Stiftleiste auf dem Bricklet, aber es gibt die Möglichkeit eine hinzuzufügen .

Wir hatten festgelegt das es standalone auf Linux und Windows sowie mit Apache funktionieren sollte. pcntl_fork funktioniert nicht auf Windows oder mit Apache und andere Lösungen funktionieren nur mit Windows und unter Apache sieht man ganz alt aus. Daher haben wir uns für die Lösung ohne Threads entschieden. Mal davon abgesehen: Wenn ich einen zweiten Prozess hab (wie einen System_Daemon oder mit pcntl_fork) muss man immernoch pollen um die Daten die beim geforkten Prozess aufgelaufen sind abzuholen! Dadurch würde man nicht viel gewinnen.

Das muss einmal pro IP Connection passieren. Das hatte ich doch glatt in der Zwischenzeit vergessen, mir ist erst nach dem Thread hier wieder eingefallen was da Sache ist . Werden wir gleich morgen früh mit in die Dokumentation aufnehmen. Was da passiert ist folgendes: der Brick Daemon müsste rein theoretisch zu jeder Socket Verbindung Callbacks von jedem auch nur irgendwie angeschlossenen Brick/Bricklet schicken (da er grundsätzlich erstmal nicht weiß welche Socket Verbindung sich für welches Brick/Bricklet interessiert). Um das zu verhindern guckt er sich die Pakete an und schickt Callbacks nur dann raus wenn eine Socket Verbindung zu dem Brick/Bricklet schon einmal eine Stack ID abgefragt hat (das ist bei den Bindings natürlich immer der Fall). Wenn man direkt TCP/IP verwendet kann das natürlich auf einmal zu einem Fallstrick werden. Also: Wenn ein Brick/Bricklet verwendet werden soll, immer vorher die Stack ID zu der UID holen!

Zweiteres meinte ich mit gewinkelten Pfostenstecker. Gibt es denn Knöpfe die man da direkt draufstecken kann oder muss man da auch löten? Würden dann nicht auch Lötpunkte reichen?

An und für sich eine gute Idee, würden dir da nicht auch einfach Pads reichen wo man was anlöten kann? Die Pfostenstecker müssten gewinkelt sein und vorne rausgucken (wegen der Höhe), das ist für 99% der Leute die ein LCD Bricklet benutzen wollen blöd. Bzgl. kosten: Relevante Kosten entstehen da durch die zusätzliche THT Bestückung, der Preis für die Stiftleiste ist vernachlässigbar.