borg

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 .

Depending on the sensor we are using 100KHz or 400KHz (we generally use the max speed of the sensor). You mean for SPI? It is 8MHz. 64MHz

x-IMU does use Madgwick’s AHRS and IMU algorithms, which we use too! So they either 1. made the video with a very well calibrated and tweaked IMU, 2. have a better parameterization of the algorithm or 3, just use much more expensive sensors. I would bet that it is a combination of 1. and 3. I probably could make a very similar video if i tweaked one IMU long enough. When say that "its way more faster", what do you mean? Do you mean the 3D rendering lags behind? And about the accuracy: Have you tried to recalibrate the magnetometers in your environment?

@Jan: Du würdest bessere Performance aus dem Raspberry PI bekommen wenn du das offizielle "Raspbian" verwenden würdest: http://www.raspberrypi.org/downloads Da funktioniert dann auch unsere brickd.deb. Unser .deb ist für arm Architekturen mit einer Floating Point Einheit (FPU). Du verwendest ein Linux für arm ohne FPU, der RPI hat aber eine FPU. Das ist der Unterschied zwischen armhf und armel

Das ist nicht möglich, die Step-Down Power Supply ist ja rein analog, da ist nichts drauf was das schalten könnte.

Naja das kann schon hin kommen. Du musst halt gucken was alles passiert. Deine Daten gehen von deinem Programm per TCP/IP an den Brick Daemon, der schickt es über USB an den Eingangsbuffer von Master1, der schiebt es in den RS485 Ausgangsbuffer, von da geht es in den Eingangsbuffer von Master2, der gibt es an das Bricklet weiter. Dort wird dann per I2C der Port abgefragt und das ganze geht den weg wieder zurück. An allen Buffern kann ein Delay von 1ms auftreten, dazu kommt dann noch die Zeit die das eigentliche ausführen benötigt und schon kommst du auf 8ms. Beide Ports gleichzeitig abfragen ist technisch natürlich möglich, ob das noch auf das IO16 EEPROM passt weiß ich aber nicht. Ich schreibe es mir mal auf die TODO Liste mir das anzugucken. Ich werd auch mal ein paar Tests bzgl der Roundtrip Time machen, dann können wir das entsprechend dokumentieren. Das wird aber nichts in den nächsten paar Tagen.

So the h1_val throws an exception if you comment it in, but it doesnt if you comment out te tX_val lines? That doesn't make sense . Can you make a minimal Program (including the initialization and so) that causes the exception?

Der eigentliche Bootloader ist read only und sobald du den Erase Knopf drückst während du USB rein steckst kommst du auf jeden Fall in den Bootloader. Sollte also nichts passieren können .

Alle klar, gucke ich mir an. Komme aber wahrscheinlich erst am Montag dazu.

Mh, also wer sich daran schonmal versuchen will bevor wir dazu gekommen sind: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/samba.py Was gemacht werden müsste: * Alles was mit Qt zu tun hat rausschmeißen * Aus flash(self, firmware, imu_calibration, lock_imu_calibration_pages, progress) alles entfernen was mit "progress" zu tun hat (ist GUI kram). * Flash aufrufen mit firmware=geladene Firmware, imu_calibration=None und lock_imu_calibration_pages=None

Vielleicht wird es auch ein SD Card Bricklet, ich habe da so eine ganz bestimmte "auto-logging Funktionsweise" im Kopf. Dafür wäre die SD Karte ein Interface, genauso wie USB, WIFI oder RS485. Das ist aber noch nicht zuende gedacht, liegt ja auch noch in ferner Zukunft. Erstmal brauchen wir überhaupt On Device Programming .

Zum Glueck nicht wirklich. Dann bliebe ja noch die manuelle Wiederbelebung per USB, oder? Jo, über USB kannst du immer flashen. Naja in Theorie geht sowas sicherlich. Es würde sich vermutlich anbieten die SD Card Extension die wir fürs On-Device-Logging machen wollen dafür zu nehmen. Aber du musst halt überlegen wie viel Aufwand das ist und welchen nutzen es hat. Ich denke es haben ca. 5% unserer Kunden eine WIFI Extension, wenn wir großzügig sind und sagen, dass 20% davon nochmal Geld ausgeben würden für ein "Zwischenspeicher-Bricklet" mit dem man dann über WIFI flashen kann. Dazu kommt der ganz schön große Aufwand das umzusetzen. Es ist halt schwierig das zu rechtfertigen, wenn noch so viele TODOs offen sind die fast alle TF Nutzer betreffen . Das ist mit dem Microcontroller den wir verwenden nicht möglich.

Ah, dann hab ich das falsch verstanden. Ich denke mit 64MHz sam3s den wir auf dem Master verwenden schon an der oberen Leistungsgrenze von Microcontrollern. Bist du sicher, dass du mehr Leistung brauchst?

Zum einen bin ich mir nicht sicher ob der komplette WIFI Code + der ganze Code den ich zum flashen brauche überhaupt in den RAM passt. Zum anderen wäre das extremst anfällig. In diesem Modus müsste ich auf jedenfall alle globalen Variablen und Buffer usw im RAM überschreiben, d.h. es gibt kein zurück aus dem Modus! Ein Verbindungsabbruch o.ä. würde sofortig zu einem gebricktem Brick führen . Eine Firmware über Funk updaten kann man eigentlich nur ohne Risiko machen wenn man die komplette Firmware einmal irgendwo zwischenspeichern kann. Ansonsten macht das mehr Probleme als es löst.