borg

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.

Dann kannst du den Wert nur entweder pollen oder den normalen Callback nutzen (der wird ja nur aufgerufen wenn sich der Wert auch geändert hat). Eine minimale Spannungsänderung zum triggern eines Callbacks gibt es leider nicht.

We have some applications on our homepage: https://www.tinkerforge.com/en/home/applications/ Some of them are similar to the "case study" that you linked, but the descriptions are not as detailed. There is also the "From idea to finished product"-story. It shows how EnBW did go from prototype to small batch production to mass market product with Tinkerforge: https://www.tinkerforge.com/en/home/smight/

Step-Down Power Supply mit mehr Schutz Blogeintrag

Step-Down Power Supply with more protection Blog Entry

Den Wert von get_humidity, aber skaliert auf %RH (und Temperatur skaliert auf °C). Also: temperature = t.get_temperature()/100.0 humidity = h.get_humidity()/10.0 temperature_compensated_humidity = humidity/(1.0546 - 0.00216*temperature)