borg

The backtrace starts in line 1166 with the function "mqtt_on_disconnect". This function is called if mqtt is disconnected. Then the code tries to disconnect the connection to the brickd which gives this "NOT_CONNECTED" exception. Perhaps the mqtt server disconnects the proxy immediately, before the connection to the brickd is established. But why does the mqtt server disconnect immediately? Does it expect some kind of encryption that is not enabled?

Oh, da hat sich in der Tat ein Fehler in der neuen Streaming API bei Python3 eingeschlichen (Python2 ist da weniger strikt und es funktioniert einfach). Vielen Dank für den Hinweis! Wir fixen das mit dem nächsten Bindings-Release, so dass man auch ein bytes-Objekt übergeben kann. In der Zwischenzeit kannst du als Workaround das hier verwenden: rs485.write(list(map(chr, send_array)))

So the brickd and mqtt broker are running on the RPi? Is the port of the mqtt broker correct? I mean the host and port that you can configure at the top of this file: https://raw.githubusercontent.com/Tinkerforge/brick-mqtt-proxy/master/brick-mqtt-proxy.py

Wir haben in der Zwischenzeit einige Sensoren hier ausprobiert und getestet, es hat sich also was getan. Bisher konnten wir uns allerdings noch nicht dazu durchringen einen der Sensoren auch wirklich zu nutzen. Meistens sind diese entweder zu ungenau (reagieren z.B. auch auf ganz viele andere Gase) oder zu teuer. Mal eine Rückfrage: Wie teuer dürfte denn ein NOX Bricklet sein (welches NOX in normalen Umgebungsluft-Konzentrationen messen kann)?

You can use the VoltageReachedCallback and set the threshold to something that always triggers (via setVoltageCallbackThreshold). The period can then be configured with setDebouncePeriod.

Das kannst du mit "set_configuration" wählen: https://www.tinkerforge.com/de/doc/Software/Bricklets/AmbientLightV2_Bricklet_Python.html#fortgeschrittene-funktionen Muss aber nach jedem aus- und wieder einschalten neu aufgerufen werden.

I can't promise anything, but it is definitely possible that there will be something like that in the future . It will unfortunately not happen in the very short term.

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)?