borg

The other data does not have to change when the coordinates change. For examples the coordinates may change, but the fix and speed stays the same. So to get all of the data at the exact point where it changes, you would indeed need to use callbacks for all. But i think it should be good enough to use the callback for the coordinates and get the rest of the data with a getter. Either in the callback or perhaps just every second or similar in a loop.

Firmware: GPS 2.0 2.0.2 Millisekunden date/time Bug gefixt (wir nutzten us statt ms) API zum ein/ausschalten von SBAS hinzugefügt (mit 5Hz/10Hz Aktualisierungsrate) Download: GPS 2.0

Firmware: GPS 2.0 2.0.2 Fix millisecond date/time bug (did use us instead of ms) Add API to enable/disable SBAS (with 5Hz/10Hz update rate) Download: GPS 2.0

Die einzige Möglichkeit die ich da sehe ist die Rohdaten auszulesen und selbst zu verarbeiten. Der eigene Fusion-Algorithmus kann dann natürlich die zusätzlichen Daten die Anfallen mit einbeziehen, z.B. die Gas/Brems-Pedalstellung.

To get the data immediately you can indeed use the callbacks. Just use a callback rate that is well below the 100ms. You will then automatically get a callback with every change that happens to the data. That is something you can't do with getters, since you don't know if the data is 10ms or 80ms if you call a getter (it is somewhere between 0-99ms). Regarding the SBAS accuracy improvement: I don't know. I can only link you to the wikipedia site: https://en.wikipedia.org/wiki/GNSS_augmentation#Satellite-based_augmentation_system. The various region specific SBAS implementations are described there. As far as i can tell we also don't know if a SBAS satellite is currently in sight or not. There is no NMEA message for that unfortunately.

Ich hab eine gute und eine schlechte Nachricht: Die schlechte: Mit der aktuellen Hardware ist das leider nicht möglich. Die 1kHz "Tick-Rate" mit der wir Bricklets ansteuern reicht leider nicht aus um die Empfangsdaten auszulesen. Die gute: Wir arbeiten aktuell an einer V2 des Bricklets (mit Co-Prozessor), diese wird auch empfangen können . Wird allerdings noch ein bisschen dauern bis die veröffentlicht ist.

I finally figured out what is going on, took me the whole day! We use SPI to communicate with the GPS IC, but it also supports UART. If you use UART, to get high update rates you have to change a configuration that increases the UART baudraute of the IC. Turns out, if you use SPI you also have to increase the UART baudrate to get a higher update rate, even if you don't use UART at all... Now we get 5Hz update rate with SBAS enabled and 10Hz update rate with SBAS disable, exactly as it is specified in the datasheet . I added API for enabling/disabling SBAS (by default we will keep SBAS enabled, since it increases the position accuracy): https://github.com/Tinkerforge/gps-v2-bricklet/commit/fbe9bb461db9fb8ae876f1e6561fc0f39f813a4d Attached you can find v2.0.2 as well as a version that has SBAS disabled by default. It would be nice if you can test the update rate with these firmwares. I will have a test/log run over the weekend to make sure that everything is still stable etc, if everything works as expected i will release the firmware next Monday. gps-v2-bricklet-firmware-v2.0.2-beta1.zbin gps-v2-bricklet-firmware-v2.0.2-beta1-sbas-disabled.zbin

There is indeed something funny going on with the update rate. It seems like the full 10Hz update rate can't be achieved if SBAS is enabled (https://en.wikipedia.org/wiki/GNSS_augmentation) . The GPS Bricklet V1.0 did not support SBAS so this was not a problem, but with the new V2.0 we have it enabled by default. I will have to ask the manufacturer how exactly that is meant to work and how we can turn SBAS off to get the higher update rate. We will then have to add API to the Bindings so you can decide for yourself if you want 10Hz update rate or SBAS.

Mh, the period settings etc that you can set for the callback do not change the internal update rate of the Bricklet. Internally we will always update with the maximum available rate. The rate should be 10hz. Let me try this out, i will come back to you tomorrow.

Go steht definitiv recht hoch auf der "sollten-wir-bindings-für-machen" Liste. Einen genauen Termin oder ähnliches hab ich leider noch nicht. Hängt auch davon ab wen wir für die aktuell offenen Stellen bei uns finden (und wann).

Das ist genau richtig, eine Steinigung ist nicht nowendig.

Cool! A 1-wire Bricklet is also already on our list for future Bricklets .

Laut der Fehlermeldung fehlt das usbfs. kannst du mal dmesg | grep usbfs ausführen? Es sollte sowas wie ausgegeben werden.

Also jede 80ste LED mit 5 LED Offset? Das klingt ja seltsam. Welche Firmware Version haben LED Strip Bricklet und Master Brick? Hast du noch andere Bricklets am den LED Strip Bricklet?

We now have a page with job offers: https://www.tinkerforge.com/en/home/jobs/

Wir haben jetzt eine Seite mit Stellenangeboten: https://www.tinkerforge.com/de/home/jobs/

Aber es hat vorher schonmal funktioniert, richtig? Das klingt in der Tat nach einem Defekt. Hast du schon überprüft ob vielleicht ein Pin im Bricklet Stecker (vom Bricklet oder verbundenem Brick) krumm ist? So wie hier: https://www.tinkerforge.com/de/doc/FAQ.html#mein-brick-wird-heisz

Oh, ich wusste gar nicht das es direkt von Conrad Support für Tinkerforge und Conrad Connect gibt. Cool! Ich hab keine Ahnung wie Conrad Connect funktioniert, aber kannst du vielleicht die Range so eingrenzen, dass nur ein Bit beachtet wird? Also angenommen du willst Pin 4 auswerten, kannst du vielleicht die Range auf "von 16 bis 16" setzen (nur 4. bit high = 16)?

We stopped to lay out big roadmaps with specific dates, since we had bad experiences with this. People will wait on specific items of the roadmap and they may take much longer then planned or perhaps even never finish because they were too challenging or we changed plans. Generally, we are working on lots of new Bricklets and on improving all of the old non-co-processor Bricklets. You can take a look at our github account to see what exactly we are working on, we do the development in the open. Regarding your other points: A "Hat" to connect Bricklets directly to a RPi or similar will come after we converted most of the Bricklets to co-processor Bricklets. We are currently working on a new RED Brick image release with lots of improvements. I think this may include openHAB 2. The RED Brick hardware will likely also be updated in the future.

Du kannst das Type 2 Beispiel hier nehmen: https://www.tinkerforge.com/de/doc/Software/Bricklets/NFCRFID_Bricklet_JavaScript.html Du musst nur im State STATE_REQUEST_TAG_ID_READY erst authenticateMifareClassicPage aufrufen und kannst dann wenn der State auf STATE_AUTHENTICATING_MIFARE_CLASSIC_PAGE_READY wechselt lesen oder schreiben. edit: Oh, ich hab das "NDEF" übersehen. Die NDEF Message steht bei Mifare in den normalen pages (was wir "pages" nennen, nennt NXP im Datenblatt "blocks"). Seite 37 hier gibt einen Überblick: http://www.nxp.com/docs/en/application-note/AN1305.pdf

Du könntest sowas machen wie def cb_temperature(temperature, device): .... und dann registrieren mit enumerate_cb(uid, ...): device = BrickletTemperature(uid, ipcon) device.register_callback(BrickletTemperature.CALLBACK_TEMPERATURE, lambda x: cb_temperature(x, device)) Das NFC/RFID Bricklet "Scan For Tags"-Beispiel nutzt das so: https://www.tinkerforge.com/de/doc/Software/Bricklets/NFCRFID_Bricklet_Python.html#scan-for-tags

Both versions are too old, please update! You can find the minimum firmware version in the API documentation and the minimum Bindings version in the changelog. The minimum versions for the get_sensor_fusion_mode are 2.0.6 and 2.1.11 respectively.

What version do the python bindings have? What version does the IMU firmware have? Since the function does not seem to be available, the bindings version is probably too old.

Also du kannst 3,3V messen und wenn du den Schalter auf 5V stellst (ohne irgendwas anderes zu ändern) misst du 0V? Das klingt so als wäre der Schalter defekt. Misst du die Spannung mit einem Multimeter? Falls ja, kannst du das Bricklet einmal vom Brick trennen und den Durchgang vom Schalter messen in den zwei Positionen? Und sind die Beinchen vom Schalter richtig angelötet? Wenn der Schalter defekt ist tauschen wir das IO16 natürlich aus, dafür meldest du dich am besten mit der Bestellnummer bei info@tinkerforge.com.

Das wäre natürlich möglich. Bei 8x 1A müsste aber die zu schaltende Spannung extern eingespeist werden, soviel Strom haben wir ja nicht im System.