borg

They will be on the next panel. There will also be at least one new Industrial Bricklet

Currently in production are (among re-production of existing Bricks/Bricklets): * Humidity 2.0 Bricklet (Much better sensor) * RGB LED Button Bricklet * RGB LED Matrix Bricklet * Motorized Linear Poti Bricklet * Thermal Imaging Bricklet We just finished planning the next production panel and it contains: * NFC Bricklet (completely new version with support for P2P and card emulation and other stuff) * Analog In 3.0 Bricklet * Motion Detector 2.0 Bricklet (Our own design, not based on a module anymore, very fancy!) * Outdoor Weather Bricklet * Remote Switch 2.0 Bricklet (Can now also receive and not only send) * Rotary Encoder 2.0 Bricklet * Solid State Relay 2.0 Bricklet * Temperature IR 2.0 Bricklet

Den haben wir in der Tat bereits auf dem Schirm. Was mir daran gefällt ist das wir damit Humidity/Barometer/Temperature für das Wetterstations Kit auf ein Bricklet zusammenlegen können. Dann haben wir noch Platz für ein weiteres Bricklet in der Wetterstation. Ist allerdings noch nicht auf dem nächsten Produktionspanel welches wir gerade zuende geplant haben, kommt also frühestens im nächsten Jahr .

Es gibt RS232 Barcode-Scanner Module, die könntest du an ein RS232 Bricklet anschließen. Ansonsten eventuell einen USB Barcode-Scanner am RED Brick?

Wir haben denke ich nicht so viele Produkte wo sich Staffelpreise lohnen, wir verkaufen ja (bis auf die Stecker) kaum Bauteile wie Mouser. Bei sowas wie den Steckern fallen die Kosten an weil wir uns eine ganze Rolle aufs Lager legen müssen. Wenn ein Stück bestellt wird müssen wir die Rolle abrollen und ein Stück vom Tape abschneiden und eintüten etc. Eine größere Stückzahl ist es wenn diese "Verpackungskosten" nicht mehr so ins Gewicht fallen. Also vielleicht 50 Stück?

Die Verbinder sind von Acesconn. Die minimale Abnahmemenge liegt da allerdings bei mehreren Rollen. Wenn du eine größere Stückzahl benötigst melde dich bei uns, da können wir bestimmt etwas am Preis schrauben.

Puh, das klingt als hätte Apple mal wieder eine nicht-rückwärtskompatible Änderung eingeführt . Da müssen wir erst unseren MacBook aktualisieren um das reproduzieren.

Versuchst du das über den RED Brick zu flashen? Die RED Brick image Version bei Verwendung eines der neuen Co-Prozessor Bricklets (die mit dem neuen Stecker) muss mindestens 1.9 betragen. Alternativ kannst du auf einem alten Image auch den Brick Daemon updaten.

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