borg

Hab es gerade ausprobiert, grundsätzlich funktioniert das Feature. Laut Log lehnt der Mailserver hinter "turboprinz.de" die Mails allerdings ab. Sieht so aus als wäre das GMX? Das scheint eine Fehlkonfiguration auf tinkerunity.org zu sein, ich hab es mir auf die TODO-Liste geschrieben mir das anzusehen.

Yes, please do! Will be interesting to see if we can't flash it here either and why this happens.

I doubt that the OSX version is relevant. The API that we use to flash the WIFI Extension 2.0 is a normal API that is available in the Bindings, so if you can use your Bricks/Bricklets you should always also be able to flash the WIFI Extension 2.0. With which Master did you try to flash the WIFI Extension? With the one where the Barometer Bricklet doesn't work? Have you tried the other one?

Ich wüsste nicht warum das Probleme machen sollte, muss ich morgen ausprobieren. Edit: In der Tat! Ich kann das reproduzieren. Da bin ich ja mal gespannt welcher Bug dieses Problem erzeugen kann. Edit 2: Oh, das war sehr einfach. Der Brick Daemon auf dem RED Brick Image 1.8 ist nicht aktuell genug für die neuen Co-Prozessor Bricklets. Du müsstest also entweder das RED Brick Image auf 1.9 aktualisieren (veröffentlichen wir vermutlich morgen) oder den Brick Daemon auf dem RED Brick aktualisieren. Neueste Version gibt es hier: http://download.tinkerforge.com/tools/brickd/linux/brickd-2.3.0+redbrick_armhf.deb Wir wollten das 1.9 Release eigentlich zeitgleich mit der Veröffentlichung vom GPS 2.0 machen...

Do both Master Bricks have the same firmware version? I don't see how they could act differently if they have the same firmware . Regarding WIFI 2.0. Can you try to flash an older WIFI 2.0 firmware version from, like 2.0.1? Just for testing if it makes a difference. http://download.tinkerforge.com/firmwares/extensions/wifi_v2/

Das Firefly X1 GPS/GLONASS Modul welches wir auf dem GPS Bricklet V2 verwenden gibt leider kein EPE aus.

Unfortunately i can't immediately reproduce either of the problems. Problem 1: I've got a weather station here with everything connected and every firmware up to date. This seems to work fine for me. Do you connect to the weather station through your Ethernet Extension or is the Ethernet Extension just in the stack and you are currently communicating through USB? If it does not work through Ethernet, does it work through USB? Problem 2: I downgraded a WIFI Extension to firmware version 2.0.0 and then upgraded it to 2.1.3 from there. Worked well. I did have to restart the Master Brick once after the flashing, which the Brick Viewer could actually do by itself. Otherwise i couldn't see any problems. When you try to upgrade it, is there any status information before the error occurs? Like "Writing flash section X of Y" or "Connecting to Bootloader"?

The problem might be the time it takes for a signal to travel from the sensor on a Bricklet to the Brick over USB to the PC. You You may reckon that that this can take about 1ms. For calculating the speed of a bullet a 1ms delay may already be too much?

The hardware version 1.0 is still supported, you can flash the newest firmware version on it. The new Master Brick hardware versions have improvements with regards to EMI and ESD immunity, but otherwise they are still pretty much identical.

Strange! What version has the WIFI Extension 2.0 firmware? Please update the Master Brick and WIFI Extension 2.0, just in case it is not current enough.

Ich würde sagen die LED ist auf der Oberseite, nur die Antenne ist beim GPS V2 auf der Unterseite . Die LED als einziges Bauteil auf die Unterseite zu setzen kommt leider nicht in Frage, wir bestücken Bricklets im Allgemeinen nicht beidseitig. Man könnte eventuell darüber nachdenken ein kleines Loch in die Leiterplatte zu machen und die LED "falsch herum" aufzulöten (Es gibt extra SMD LEDs die dafür gedacht sind). Was meinst du mit "Wo ist eigentlich das hier hin"?

We do not recommend to go above 2m length for the Bricklet cables. For long cable runs you can use the RS485 Extension. For cables longer than 2m we can't guarantee signal integrity, we also do EMI tests only with the standard 6-200cm cables. That being said, you can of course cut one of our cables in the middle and extend it with other wires. The connectors and crimp contacts are also available in our shop.

To be honest, i am not sure . I will ask our supplier.

Das ist leider nicht geplant und auch technisch sehr schwer umzusetzen. Das verwendete Modul auf der WIFI Extension kennt keinerlei "RAW-WLAN" Modus o.ä. sondern spricht direkt TCP/IP. D.h. wenn die WIFI Extension im Linux als normale ethX Schnittstelle auftauchen sollte, müsste man einen Treiber schreiben der den Linux TCP/IP Stack umgeht und direkt den Stack auf der WIFI Extension nutzt. Ganz zu schweigen von der ganzen Konfiguration etc. Wenn man das machen würde, hätte die WIFI Extension immernoch viel weniger Durchsatz als der kleine (und günstigere) USB WIFI Stick.

Firmwares: Silent Stepper Brick 2.0.2 Bug in Stromverbrauchsberechnung behoben Download: Silent Stepper Brick

Firmwares: Silent Stepper Brick 2.0.2 Fix bug in calculation of current consumption Download: Silent Stepper Brick

Das ist durchaus üblich. Ich weiß gar nicht so 100%ig was dein Problem ist, deswegen bekommst du vermutlich auch nicht die Antwort die du dir wünscht. Es ist aktuell nicht geplant die Python Bindings groß zu verändern. Dir scheint ja Performance sehr wichtig zu sein, unser System kann bis zu 1000 Nachrichten pro Sekunde pro Stapel generieren, diese kann man mit den Bindings so wie sie sind problemlos behandeln. Auch auf einem RPi oder dem RED Brick. Da würde eine Umstellung auf asyncio nicht viel ändern. Unsere Bindings bieten einen Realzeit-Zugriff auf die aktuellen Daten des System, wenn du von rethink-db sprichst nehme ich an du möchtest Daten archivieren und später auf diese zugreifen können. Das ist nicht die Aufgabe der Bindings im generellen und hat auch nichts mit den Python Bindings oder asyncio zu tun. Die Vorgehensweise dafür wäre mit Hilfe der Bindings die Daten auszulesen und mit einem Zeitstempel in der Datenbank deiner Wahl, z.B. rethink-db, zu speichern. Ab da kannst du dann das rethink-db JSON-Interface nutzen.

Ist umgestellt.

In den neuesten Releases vom Master Brick, WIFI Extension 2.0 und Brick Viewer werden jetzt nur noch leere Strings von den Password-Gettern zurückgegeben und die GUIs wurden entsprechend angepasst .

Die Unterstützung für Python 2 können wir natürlich erst entfernen wenn Python 2 nicht mehr so weiträumig verwendet wird.

Firmwares: DC Brick 2.3.3, IMU Brick 2.3.3, IMU 2.0 Brick 2.0.8, Master Brick 2.4.4, Servo Brick 2.3.2, Silent Stepper Brick 2.0.1, Stepper Brick 2.3.4 Unterstützung für Bricklets mit Co-Prozessor hinzugefügt Unterstützung für WIFI Extension 1.0 und WIFI Extension 2.0 Password-Getter Funktion entfernt (nur Master Brick) Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick Firmware: WIFI Extension 2.0 2.1.3 Unterstützung für Password-Getter Funktion entfernt Download: WIFI Extension 2.0

Firmwares: DC Brick 2.3.3, IMU Brick 2.3.3, IMU 2.0 Brick 2.0.8, Master Brick 2.4.4, Servo Brick 2.3.2, Silent Stepper Brick 2.0.1, Stepper Brick 2.3.4 Add support for co-mcu Bricklets (all Bricks) Remove support for WIFI Extension 1.0 and WIFI Extension 2.0 password getters (only Master Brick) Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick Firmware: WIFI Extension 2.0 2.1.3 Remove support for WIFI password getters Download: WIFI Extension 2.0

We are currently in the process of releasing it, so it will happen either today or tomorrow. Edit: It is now available: https://www.tinkerforge.com/en/shop/gps-v2-bricklet.html

Mh, also wenn ich den Code so nehme wie er im Beispiel ist und die UID anpasse sowie threshold Konfiguration durch "ai.set_voltage_callback_threshold("i", 5*1000, 20*1000)" ersetze funktioniert das bei mir genau so wie du es Beschrieben hast. Hattest du die UID bei dir angepasst? Brick Viewer nutzt übrigens Getter, daher ist die Anzeige im Brick Viewer von den Callback-Konfigurationen unabhängig.

Du meinst intern für die TCP/IP Kommunikation? Womöglich könnte der Code dadurch einfacher/verständlicher werden, allerdings ist das Handling so wie es aktuell geschieht ja jetzt viele Jahre getestet. Das umzureißen würde erstmal zu neuen Problem führen. Davon abgesehen würden wir ganz viel Python 2 vs 3 if/else haben, da wir ja weiterhin Kompatibilität mit Python 2 haben wollen. Ich könnte mir das frühestens vorstellen wenn Python 2 tot ist.