borg

Wenn mehrere Master Bricks ohne den Widerstand gleichzeitig im Stack starten, speisen sie kurzzeitig (für ein paar µs bis die main() aufgerufen wird) alle gleichzeitig die 3.3V ein. Das wird keinerlei Nebenwirkungen haben. Warum das Probleme machen kann wenn das Langfristig so läuft (also wenn gar kein Transistor und keine Diode da wären) muss Batti beantworten, da reicht mein Etechnik-Halbwissen nicht aus um das zu erklären .

Haben die beiden vielleicht die gleiche UID?

Ohje, das liegt am Master Brick 2.0 . Vermutlich hat OnurKayikci die gleichen Probleme. Wir haben im Master Brick 2.0 einen Transistor eingebaut, mit dem die Stack Spannung nach oben hin getrennt und hergestellt werden kann. Vorher lief das über eine Diode, durch das neue vorgehen haben wir bessere 3.3V im Stack. Das führt jetzt allerdings dazu, dass direkt beim Startup keine 3.3V anliegen. JTAG bringt nun den Microcontroller in den Reset-Zustand, wodurch dann die 3.3V nicht mehr anliegen. Ich debugge hier immer mit meinem alten Master Brick 1.1 daher war das noch nie aufgefallen. Es gibt da jetzt mehrere Möglichkeiten das zu fixen: Unter den Master Brick 2.0 einen Master Brick 1.1 oder einen der anderen Bricks (Servo, Stepper, DC, IMU) stecken. Die versorgen über eine Diode mit 3.3V. Oben am JTAG-Stecker zusätzlich 3.3V extern über ein Labornetzgerät o.ä. einspeisen (dabei dann natürlich auch GND verbinden). Einen Debugger verwenden dem man fest eine Spannung einstellen kann die er verwenden soll (geht mit SAM-ICE soweit ich weiß nicht ). Den Pulldown Widerstand vom Master 2.0 runterlöten, der dafür sorgt das beim Startup der Transistor nicht geschalten wird (siehe Anhang). Wenn ein Lötkolben vorhanden ist, ist letzteres vermutlich die einfachste Möglichkeit. Mit einer großen Spitze den kompletten Widerstand warm machen und nach oben rechts rausziehen. An dieser Stelle erstmal Entschuldigung für die verschwendete Zeit und Danke für den Hinweis mit den Spannungen, dadurch bin ich erst darauf gekommen dass es dieses Problem geben könnte.

*kopfkratz* Sieht korrekt aus. Muss ich mir morgen früh angucken, vielleicht ist da wirklich ein Bug in der Firmware.

Ups. Das wurde bestimmt von der IO-4 Dokumentation kopiert und nicht korrekt angepasst . 8 Bit ist korrekt.

Solange du eines der großen Betriebssysteme nutzt (Windows, Linux, Mac) und die Kommunikation über USB passiert, gibt es leider keinerlei Garantie für Paketlaufzeiten . Die Verzögerung ist also nicht immer gleich. Edit: Um das ein wenig zu relativieren: Wenn du Stepper Bricks an einem PC hast an dem sonst keine Daten über USB überträgt werden und du zwei Setter hintereinander aufrufst, kannst du davon ausgehen das sie mit ziemlich genau 1ms Abstand beim Brick ankommen. Eine Garantie, dass es nicht auch mal 2ms sind gibt es aber definitiv nicht.

Your ap/router has an DHCP server integrated that receives the hostname from the WIFI Extension when it gives out the IP address. You don't have to set up a DNS or do something with your etc/hosts. Just use setWifiHostname and use this name instead of the ip when connecting to the stack.

Passiert nichts heißt du bekommst einen Fehler? Oder wird einfach nichts angezeigt? Hat du denn deine Bricks auch auf 2.0.X aktualisiert? Die Bricklets können dann automatisch aktualisiert werden, die Bricklets müssen aber einmal händisch auf 2.0.X gebracht werden.

Das ist ein bekannter Bug. Das tritt im Moment bei allen analogen Bricklets auf wenn man thresholds benutzt . Ist im Git schon gefixt, wird dann beim nächsten Firmware Release wieder richtig funktionieren .

Mhh, das funktioniert bei mir. Meine vorgehensweise: Stack mit Master und WIFI Extension starten, Brick Viewer öffnen: Power Mode = Full Speed Dann dieses Programm starten: import com.tinkerforge.BrickMaster; import com.tinkerforge.IPConnection; public class ExampleStackStatus { private static final String host = "localhost"; private static final int port = 4223; private static final String UID = "6qZ3tS"; public static void main(String args[]) throws Exception { IPConnection ipcon = new IPConnection(); BrickMaster master = new BrickMaster(UID, ipcon); ipcon.connect(host, port); master.setWifiPowerMode(BrickMaster.WIFI_POWER_MODE_LOW_POWER); System.out.println(master.getWifiPowerMode()); } } Ausgabe: olaf@pc:~/build20/java$ java -cp . ExampleStackStatus 1 Im Brick Viewer einmal auf Disconnect und wieder auf Connect drücken (damit die Daten neu geladen werden): Power Mode = Low Power. Brick Viewer 2.0.3 Java Bindings 2.0.5 Master Brick Firmware 2.0.5

ig4dev32.dll ist laut google ein Treiber für Intel Grafikkarten. Hast du vor kurzem irgendwas diesbezüglich aktualisiert? Wir benutzen ja OpenGL für die 3D Darstellung des Bricks. Ich glaube nicht das wir etwas am Brick Viewer IMU Plugin geändert haben in den letzten Monaten.

The claimed resolution is conservatively described as 0.1°C, what you are seeing is a resolution of 0.06°C. Depending on the Brick/Bricklet there is a lot of integrating and averaging going on. So the value jumps you are getting may not always be intuitive.

Den Bug hatten wir schon gefunden und er ist im git schon gefixt. Beim nächsten Brickv Release ist das dann wieder heile .

We don't recommend using longer Bricklet cables than 2m. You will very likely have problems controlling the LCD over that range (the voltage drop will be too big).

Do you get some kind of error message? Did you configure the correct microcontroller (atsam3s4c vs atsam3s2b)?

Must be an error in the compiler, the comparision is probably removed as an optimization. The compiler didn't recognize the interrupt routine that sets the state and thought that the while condition is always true. What gcc version are you using? Have you tried making send_status volatile?

Die Step-Down Power Supply kannst du vermutlich nur so richtig testen indem du die Spannungen misst. Wir haben es uns gerade genauer angeguckt, bei deiner Fehlerbeschreibung kann es eigentlich nur sein, dass eine der Ferritperlen auf dem Master Brick durchgebrannt ist. Dann würde die Stromversorgung über die Step-Down nicht mehr funktionieren und die Strom/Spannungsmessung auch nicht, da kein Massebezug mehr da ist. Eigentlich sollte so ein defekt aber nicht spontan auftreten, da muss eine zu hohe Spannung angelegen haben oder sowas . Bzgl. eines Austausches melde dich bei info@tinkerforge.com (mit zugehöriger Bestellnummer am besten).

Ohje, da hat der Master Brick dann seinen Magic Smoke freigelassen . Weißt du denn was passiert ist? Hast du + und - verpolt oder die Spannung im grünen Stecker eingespeist? Die kaputte Spannung/Strommessung kann bedeuten, dass die Messwiderstände auf der Step-Down Power Supply kaputt sind, aber auch dass der Microcontroller auf dem Master Brick defekt ist. Da der Master selbst das Servo Brick und die WIFI Extension nicht mehr mit Strom versorgen kann, muss auf jeden Fall zusätzlich noch die Stromversorgung vom Master Brick in irgendeiner Weise defekt sein.

Ich würde mal vorsichtshalber konservativ von 800 Nachrichten pro Sekunde ausgehen (Slots gehen verloren da das Betriebssystem scheduled und sowas). Dann sollten wir noch Nyquist anwenden (http://de.wikipedia.org/wiki/Nyquist-Frequenz). Dann komme ich auf 800*60/2 = 24000 Umdrehungen/Minute unter der Annahme dass Callbacks verwendet werden und sonst im System keine Nachrichten unterwegs sind .

Es gibt jetzt set_wifi_hostname und get_wifi_hostname in Master Brick Firmware Version 2.0.5. Den Default Hostnamen kann man mit einem setzen eines leeren Strings wieder herstellen .

Der Low Power Mode sollte jetzt zurückgesetzt werden bei einem Disassociate (in 2.0.5).

Am einfachsten ist es wahrscheinlich wenn ihr eine weitere VM aufsetzt die einen Mutex implementiert (einfach über Sockets oder so). Das über einen Setter/Getter bei uns im System zu machen ist definitiv nicht sicher. Es könnte ja folgende Abrufreihenfolge passieren VM A: Get -> Ergebnis: Unlocked VM B: Get -> Ergebnis: Unlocked VM A: Set -> Lock VM B: Set -> Lock (kein Fehler) Um schon greifen beide VMs gleichzeitig drauf zu. D.h. ihr braucht eine TryLock Funktionalität, die einen Fehler zurückgibt wenn das Lock schon gesetzt ist. Es ist möglich das auf dem Master Brick zu implementieren, es gibt aber aktuell keinen Setter oder Getter bei uns im System der sowas leisten könnte.

Firmwares: Master Brick 2.0.5 Low-Power-Mode wieder anschalten nach Disassociation API hinzugefügt für: SetWifiHostname GetWifiHostname SetCurrentCallbackPeriod GetCurrentCallbackPeriod SetVoltageCallbackPeriod GetVoltageCallbackPeriod SetUSBVoltageCallbackPeriod GetUSBVoltageCallbackPeriod SetCurrentCallbackThreshold GetCurrentCallbackThreshold SetVoltageCallbackThreshold GetVoltageCallbackThreshold SetUSBVoltageCallbackThreshold GetUSBVoltageCallbackThreshold SetDebouncePeriod GetDebouncePeriod Current (Callback) Voltage (Callback) USBVoltage (Callback) CurrentReached (Callback) VoltageReached (Callback) USBVoltageReached (Callback) Download Firmwares: Master Brick

Firmwares: Master Brick 2.0.5 Reissue Low-Power-Mode after disassociate Add API for: SetWifiHostname GetWifiHostname SetCurrentCallbackPeriod GetCurrentCallbackPeriod SetVoltageCallbackPeriod GetVoltageCallbackPeriod SetUSBVoltageCallbackPeriod GetUSBVoltageCallbackPeriod SetCurrentCallbackThreshold GetCurrentCallbackThreshold SetVoltageCallbackThreshold GetVoltageCallbackThreshold SetUSBVoltageCallbackThreshold GetUSBVoltageCallbackThreshold SetDebouncePeriod GetDebouncePeriod Current (Callback) Voltage (Callback) USBVoltage (Callback) CurrentReached (Callback) VoltageReached (Callback) USBVoltageReached (Callback) Download Firmwares: Master Brick

So you are using stock debian? We currently don't have armel builds, our .deb is for armhf. The difference is described here: http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/ You can either switch to Raspbian or you can build brickd yourself from source (https://github.com/Tinkerforge/brickd): sudo apt-get install libusb-1.0-0-dev libudev-dev build-essential cd src/brickd make