borg

Steht da nur "Fehler beim erstellen"? Oder auch irgendein Grund für den Fehler? "Dieses Projekt ist veraltet": Das heißt, dass das Erstellen des Projekts nicht geklappt hat und er nur eine alte früher kompilierte Version starten kann.

Alternativ auf "Auto update all Bricklets" klicken im Update Tab .

Hast du die Firmware schon aktualisiert? Ich vermute das es noch mit einer v1 Firmware ausgeliefert wurde.

Wenn du in dem Testprogramm die UID durch die des Bricklets ausgetauscht hast und der Brick Daemon läuft (was er tut wenn der Brick Viewer funktioniert), dann musst du nur das Programm auf dem PC starten .

Es geht nicht darum zu gucken ob das eine Alternative wäre, es geht darum zu gucken ob es sich anders verhält. Wenn es sich genauso verhält wie die WIFI Extension werden wir da an der WIFI Extension keine Konfigurationen finden um die Aussetzer zu beheben.

Naja, für den Fall müsstest du dann den Getter aufrufen. Alternativ kannst du in regler auch eine globale variable oder eine Klassenvariable setzen: class X: value = 0 def regler(self, x): self.value = x

Ah, die gibts auf github: https://github.com/Tinkerforge/dc-brick/tags

bricklib/utility/init.c:24:24: fatal error: pio/pio_it.h: No such file or directory Mmmmmh, in Zeile 24 steht aber eigentlich #include "bricklib/drivers/pio/pio_it.h" und nicht #include "pio/pio_it.h" Ich denke er versucht einfach den Ordner "pio/" direkt im Hauptverzeichnis zu finden, er müsste aber in "briclib/drivers/pio" suchen. Welche IDE verwendest du denn? Kann man da irgendwas bzgl. Include-Pfaden einstellen? Edit: Im Zusammenhang mit dem anderen Thread vermute ich, dass du v1.x.y Branches mit v2 Branches mischt (also bricklib v1 und master v2 oder umgekehrt). Du musst bei beiden die v1.x.y Branches nehmen: https://github.com/Tinkerforge/master-brick/tree/v1.x.y https://github.com/Tinkerforge/bricklib/tree/v1.x.y Ich würde allerdings empfehlen auf v2 umzusteigen, v1 wird nicht mehr mit neuen Features erweitert werden!

Was du probieren könntest ist der Aufbau: PC -> WLAN -> PC -> USB -> Bricks Also sprich: Der Brick Daemon läuft auf einem PC wo der Brick direkt per USB angeschlossen ist und die Kommunikation läuft über Wi-Fi von einem anderen PC aus. Verhält es sich in dem Fall anders? Bzgl. eines Checks wegen der Geschwindigkeit steht zumindest nichts im Datenblatt des Moduls. Ich könnte dir aber eine Firmware machen in dem ich die "Transmit Rate" auf einen festen Wert setze.

Echt interessant, du scheinst da ja wirklich eine störungsreiche Umgebung zu haben . Ich gucke mal ob wir das nicht schaltbar in die Firmware eingebaut bekommen.

Ich denke die beste Lösung für so ein Projekt ist es, ein kleines Embedded Board (Raspberry PI, BeagleBoard o.ä.) mit auf die Seilkamera zu bringen und die eigentliche Regelung machen zu lassen. D.h. du schickst eine "High-Level Anweisung" per Wi-Fi an das Embedded Board (fahre 10m nach links mit 20km/h) und das Embedded Board macht die eigentliche Regelung. Eine Regelung über Wi-Fi wird nie Echtzeitanforderungen genügen, also nie eine definierte minimale Paketlaufzeit haben. Welche Verbindungsart theoretisch am stabilsten sein könnte kommt sicherlich auf das verwendete Equipment an. Wenn ein AP mit sehr hoher Sendeleistung verwendet wird, kann es denke ich durchaus sein dass eine Verbindung stabiler ist als direkt AdHoc.

http://download.tinkerforge.com/firmwares/

Also geplant ist sowas, das wird aber noch lange dauern. Ist relativ weit hinten in der Neue-Hardware-Liste. Im Moment tendieren wir aber dazu ein NFC-Bricklet zu machen, das scheint sich ja jetzt in Mobiltelefonen durchzusetzen usw. Vielleicht wäre NFC für ein Zugangssystem auch besser geeignet. Das ist auf Sicherheit ausgelegt und man könnte dann auch Zugang über Handys erlauben: http://www.fakir.it/aktuelles/detail/items/unterschied-rfid-und-nfc-eine-kurze-erklaerung.html

Unser Standardport ist 4223, nicht 4222 .

Do you have a screenshot of the behavior?

Da gibt es mehrere Möglichkeiten, ich würde es einfach mit einem großen Blob Lötzinn versuchen, den ich immer hin und her schwenke. Das kommt ein bisschen drauf an was du an der anderen Seite dranmachen willst. Wenn dein Taster auch einfach Pinne hat könntest du z.B. Jumper Kabel nehmen: http://nodna.de/Jumper-Kabel-F-F-gecrimpt-mit-Pingehaeuse-10-Stk Ansonsten gibt es auch passende Stecker dafür: http://webshop.schneider-consulting.it/25-Stueck-Pinheader-Buchsenstecker-Raster-254mm-zweireihig-6-polig (muss man aber selbst crimpen). Oder wenn du einfach nur ein Kabel anlöten willst, was du wieder an- und abstecken kannst, würde ich einfach eine 2x3 Buchsenleiste nehmen und dort Käbelchen anlöten: http://www.elmotex.de/steckverbinder/stiftleisten-und--buchsen/bl-2x3-g8-rm254.php (Sorry für die unterschiedlichen Shops, sind die ersten Google Treffer)

Die haben 3,5mm Abstand, füge ich hinzu. Das ist nicht mehr aktuell - oder? Ab Version 1.2 hat das LCD doch kleine Taster + Lötpunkte. Hö? Die Lötpunkte sind dafür da um eine Stiftleiste einzulöten: https://www.tinkerforge.com/de/shop/right-angle-pin-header-2x3.html Das soll die Doku an der Stelle beschreiben .

In gewisser Weise hängt es damit natürlich zusammen. Ein System welches nur dafür da wäre IO16 Werte über eine RS485 Verbindung auszulesen könnte sicherlich schneller sein. Ich müsste mal zwei Stack mit unserem Logic Analyzer verkabeln um herauszufinden wo genau wieviel Zeit verloren geht.

Das sollte nicht passieren. Welche Version hat die Master Brick Firmware?

An increase of 1mbar is equal to a decrease of ~10m. You can see that in both screenshots.

Again, we use the same algorithm. The link you posted is even in our documentation: http://www.tinkerforge.com/en/doc/Hardware/Bricks/IMU_Brick.html#how-it-works .

I don't know anything about Bluethooth, but i would expect that it has a lower latency then Wi-Fi. It is used in mice and such, which likely wouldn't work very well over Wi-Fi.

I would expect that it stabilizes a bit more if you run it for a longer time period. A change in air pressure of 0.12mbar is really not that much i am afraid. The altitude calculation is directly correlated to the air pressure. There is nothing we can do about that. If you want the altitude to be correct in the cm range, you will need to combine it with the IMU Brick data (with a Kalman filter).

Oh, but over Wi-Fi you will always have the added latency. I don't think there is anything you can do about that. If you connect the IMU to a PC over USB and then connect with to the IMU with another PC over Wi-Fi, you will get the same latency.

Yes, i agree. We had this discussion already quite often. It would be possible to generate something like this. It was once even planned during the protocol V1 to protocol V2 transition. But we decided to not invest time in this for the moment, since must of our users configure their Extensions in the Brick Viewer and don't need the API anyway. There is a huge list of TODOs and new products and so on, we have to pick our battles wisely .