borg

Mh, bei mir gehts. Edit: Ah, mit Python3 kann ich das reproduzieren. Komisch, dann müssen die Python bindings mit der IO16/IO4 noch nie richtig funktioniert haben . Gucke ich mir gleich an, ist vermutlich mal wieder so ein byte vs char gefummel.

Das ist leider gewachsen, im alten Protokoll konnten wir an der Stelle nur die 50 Byte Nutzdaten übertragen. Das WIFI Modul könnte Passwörter bis Länge 64. Im neuen Protokoll haben wir allerdings 64Byte für den Payload, was genau für ein 64 Byte Passwort passen würde. Allerdings übergeben wir bei set_wifi_encryption key index, eap options und andere Dinge, wodurch der Payload wieder nicht reicht . Das einzige was mir dazu einfällt: Wir könnte die API um ein set_long_wifi_password erweitern. Dann müsste man natürlich immer erst set_wifi_encryption mit einem "Dummy-Passwort" aufrufen, um die Art der Verschlüsselung vorher zu setzen. Hat irgendwer eine bessere Idee? Sonst würde ich das denke ich implementieren. Bin sowieso gerade dabei am WIFI Code rumzufummeln.

Welches Beispiel führst du aus? Gibt es keine Timeout oder sowas? Hast du die korrekte UID benutzt (im Beispiel ausgetauscht)?

But you can connect to the IP of the WIFI Extension and do the Bricks/Bricklets that are connected to the Master Brick show up, right? If that is the case, i highly suspect that it is a problem with the timing of the status refresh. Since the refresh makes the WIFI module unresponsive for a small amount of time. I took a look at the WIFI module datasheet. We could try to get the RSSI from another command that does not have so much overhead and do the rx/tx count ourself. All of the other information must only be obtained on connects/disconnects and not every time the getStatus is called. We will try to make a firmware that works this way, that you can test.

No worries, if it is broken we will of course replace it. It is just so unlikely that the 5V rail isn't working. Can you measure the voltage of pins in the green connector? And are you using the black connector for input (Black is input, Green is output) ?

Hattest du jetzt 2.0.1 auch schon getestet?

Ui, ich hab mit Hilfe deines Codes einen potentiellen Buffer Overflow im WIFI Extension Code gefunden. Ich konnte das zwar nicht so gut reproduzieren, allerdings wird dies trotzdem mit hoher Wahrscheinlichkeit dein Problem gewesen sein. Vielen Dank für die Hilfe !

Firmwares: Master Brick 2.0.1 Fix Buffer Overflow in WIFI Extension Code Download Firmwares: Master Brick

Firmwares: Master Brick 2.0.1 Fix buffer overflow in WIFI Extension code Download Firmwares: Master Brick

Mhh, läuft bei mir erstmal soweit durch. Wie hast du das genau zusammengesteckt (welches Bricklet wo, welche Bricks wie aufeinander)? Tritt das Problem auch auf, wenn du keinen Servo am Servo Brick angeschlossen hast?

Gucke ich mir direkt morgen früh an!

You interpreted the function of the Step-Down Power Supply correctly. The way you are describing it, it sounds like the 5V rail isn't working (which is used to power the Bricks). Can you check if the Board-To-Board connectors are connected correctly? We do test the 5V rail of each Step-Down Power Supply, so i don't understand why it wouldn't be working.

But the WIFI Extension works otherwise? To read the status of the WIFI module, the Master Brick has to change the module from data mode to command mode and back. This unfortunately takes quite a long time. If the connection to the module is not good either, it may happen that the getStatus call times out. I will change the update rate to something smaller for the next Brick Viewer version, that should fix this.

It is the port number that the client connects to (default 4223).

Connecting over two different interfaces is officially not supported. The following will happen: Setter and getter will work and callbacks will always be routed to the last interface that was used. Using two Brickv instances is no problem. I don't know how the Mac OS X application launcher works, but i can start two Brickv instances from the console.

Also die Kamera ist extern über 5V versorgt und du willst diese trennen und verbinden können? Das geht am besten über das Dual Relay oder das Industrial Quad Relay. Wenn du einen passenden Transistor da hast, kannst du den natürlich auch über die IO4 schalten .

Firmwares: Joystick Bricklet 2.0.1 Fix timeout in threshold callback functions Download Firmwares: Joystick Bricklet

Firmwares: Joystick Bricklet 2.0.1 Fix Timeout in threshold Callback Funktionen Download Firmwares: Joystick Bricklet

Mhhh, schwer zu sagen. Der Master sollte eigentlich nur dann neustarten, wenn er über "reset()" getriggert wird. Kannst du das irgendwie in ein Programm packen was ich hier ausführen kann? Würde das gerne reproduzieren. Probleme mit dem Threading halte ich für sehr unwahrscheinlich. Spätestens die "send" Aufrufe auf dem Socket sind normalerweise atomar. D.h. da sollte wenn nur etwas auf PC Seite durcheinander geraten können.

Wie du selber schon sagst: Da RS485 für gewöhnlich über lange Strecken betrieben wird, macht es eigentlich keinen Sinn 5V direkt über die RS485 Strecke einzuspeisen (wegen Spannungsverlust auf der Strecke). D.h. man müsste wieder einen Spannungsregler mit draufpacken, dafür gibt es ja die Step-Down Power Supply schon.

Du benötigst eine externe Stromversorgung (über den schwarzen Stecker am Servo Brick) um Servos zu steuern. Das würde über USB auch nicht funktionieren, kurzzeitig beim anfahren zieht auch so ein kleiner Servo mehr als 500mA (Maximum über USB).

Ich weiß nicht, so ein Adapter würde auf jeden Fall mehr kosten als ein USB Kabel. Siehe z.B. hier: https://www.sparkfun.com/products/10031

Hö? Ist doch alles gut! Den Master Brick flasht du über den Brick Reiter, wenn er im Bootloader ist (Erase gedrückt). Die Bricklets flasht du über den Bricklet Reiter, wenn der Master Brick _nicht_ im Bootloader ist . Das Windows dort eine "GPS Camera" erkennt ist OK, Hauptsache es erkennt den Master als serielle Schnittstelle (was es damit tut). Also bitte nochmal zurück auf V2, dann den Brick flashen (über den Brick Reiter). Dann den Brick neustarten (jetzt taucht er im Brickv auf) und dann über den Bricklet Reiter oder per Auto-Update die Bricklets flashen.

Öh, versuch mal alles zu aktualisieren, also zuerst brickd, dann brickv, dann den Master Brick. Dann sollte der Master Brick im Brickv erscheinen. Tut er das, ist auch der Bricklet Reiter nicht mehr ausgegraut . Dann solltest du auch direkt per "Auto-Update" die Bricklets aktualisieren können.

Alles klar, vielen Dank für die Hilfe! Ich hab Ruby Bindings 2.0.2 veröffentlicht, die sollten mit Ruby 1.9.3 "out of the box" funktionieren. Naja, das "<" bei "C<" bei einem unpack Aufruf ist überflüssig. In Ruby 1.9.1 wird das "<" einfach ignoriert, Ruby 1.9.3 schmeißt eine Exception. Vermutlich hat keiner der Ruby Entwickler daran gedacht, dass diese Änderung existieren Code brechen kann.