borg

OK, dann ist ja ziemlich klar woran es liegt (Browsersprache wird nicht richtig erkannt).

Naja, wenn wir eine Auflösung von 1/10 Lux haben macht es einfach sehr viel Sinn die Werte auch in 1/10 Lux zu übertragen, bringt doch sonst nur nachteile (Präzisionsverlust etc). Anders ist das z.B. bei den Quaternionen beim IMU Brick, die übertragen wir entsprechend aber auch in float.

Ich hab die Maximal Dateianhanggröße mal auf 10MB gestellt. Warum ist das denn selbst ohne das compilierte so fürchterlich groß? Kann man die LabVIEW Bindings auf dauer überhaupt autogenerieren?

Ich würde mir erstmal eine Programmiersprache aussuchen, dafür eine Entwicklungsumgebung aufsetzen und ein erstes "Hallo Welt" Programm schreiben. Danach kannst du dann ja mit einem unserer Beispiele Anfangen und das erweitern.

Sollte jetzt gehen, das war mir noch gar nicht aufgefallen und war eine Standardeinstellung hier im Forum.

Dieses Thema wurde verschoben nach Allgemeine Diskussionen. [iurl]http://www.tinkerunity.org/forum/index.php?topic=479.0[/iurl]

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.