borg

I did some real fast preliminary tests: The SPI clock on the RPi4 seems to be derived from the main cpu clock (on the RPi3 it is derived from the VPU, which is even crazier...). This means that if the CPU governor scales down the CPU, it also scales down the SPI speed. One solution is to put the governor in performance mode: Another, very unintuitive, solution is to have something running on the RPi that uses a lot of CPU. Just running a while(true)-loop on 2 cores does the trick in my tests, i then get the full speed too... . I have written on my TODO-list to install the newest version of Raspian on a RPi2, RPi3 and RPi4 and compare the exact performance and document the steps necessary to configure the PIs for the best performance. I will add this to the HAT and HAT Zero documentation.

In der Tat! Aktuell bleiben IIR_BYPASS und LPRO immer auf Default. Ich füge das als Konfiguration der API hinzu. Komme ich vermutlich frühestens Mittwoch zu. Edit: Nur ein kurzer Hinweis: Ich habs nicht vergessen, komme aber erst nächste Woche dazu.

It should be possible to transfer about the same amount of data through the HATs (maybe a little bit less) as with a Master Brick. From the perspective of the Linux kernel there is a lot of context switching going on (between kernel and user land as well as between IO and CRC calculation etc). There is unfortunately some time lost compared to the Master Brick, since the Master Brick does not do anything else in-between. Also, the processor of the RPi3 does not support SPI CPHA (which we need) on spidev1.x. Because of that we have to manage 8 chip selects with one hardware SPI unit. The SPI unit does not have 8 hardware chip selects, so we have to do them from the user land via GPIO. This also costs additional time. That being said: I did all my tests with the RPi3. During the development of the HAT the RPi4 was not yet released. I will do some measurements with the RPi4 to see where the time is lost and if there maybe is a kernel configuration somewhere that we can do to increase the throughput. I think i will be able to do this on Wednesday, give me a few days for this. I will post the results in this thread.

Das ist komisch. Wenn die LED am RPi wieder anfängt zu leuchten, bekommt das RPi ja offensichtlich auch wieder Strom. Ich wüsste nicht warum es dann nicht booten sollte. Hast du die Möglichkeit einen Monitor am RPi anzuschließen? Wenn die LED leuchtet, hängt der RPi dann irgendwo im Bootprozess?

Das Isolator Bricklet kann so wie es ist mit den HATs verwendet werden! Dazu benötigt man jetzt natürlich beidseitig 7p-7p Kabel.

Ist aktuell nicht geplant, wenn es da genug Nachfrage gibt könnte man sowas aber natürlich machen.

Ein RED Brick 2.0 ist geplant. Wird allerdings noch ein wenig dauern, da wir jetzt zuerst noch die anderen Bricks umstellen wollen nachdem wir mit den Bricklets durch sind.

Das geht über den 3G USB Stick: https://www.tinkerforge.com/de/shop/3g-usb-adapter.html https://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#mobile-internet

Es kommt jetzt noch ein Panel mit neuen Bricklets (befindet sich bereits in der Produktion). Danach sind dann alle alten 10-Pol Bricklets umgestellt auf 7-Pol. Dann gehen wir die Bricks an .

Ist getestet, läuft wunderbar .

Ich nehme an du meinst das power_off_delay? Wenn du den RPi geordnet runterfahren möchtest dauert das sicher > 5 Sekunden. Aber eventuell reicht es dir ja auch zu sagen du schließt alle Dateien die du geöffnet hast und stellst sicher das niemand mehr auf die SD-Karte schreibt und machst den RPi dann einfach aus.

The SPI communication (that is used between Bricks and Bricklets) in brickd is currently only implemented for Linux, so it will unfortunately not work out-of-the-box with Windows 10 IoT Core.

Actually, a Compass Bricklet will be part of the next panel of new Bricklets that we will produce . It uses what we think is currently the highest resolution/accuracy MEMS magnetometer. If there is no external magnetic field it is very accurate and repeatable in our tests.

Wenn ich folgende Formel verwende: Beschleunigung = Rohwert*625/1024 und die Beschleunigung als Integer betrachte werfe ich ~1 Bit an Auflösung weg. Dies ist egal wenn ich die Beschleunigung selbst betrachte, da bei den hohen Frequenzen sowieso sehr viel Rauschen auf den Daten ist mit denen ich nichts anfangen kann wenn ich als Mensch die Daten betrachte. Wenn ich einen FFT auf den Daten anwende, können sich im "Rauschen" aber auf einmal doch noch Informationen zu irgendwelchen Frequenzen verstecken die eventuell interessant sind.

Hot-connecting of the new Bricklets with 7p connector works in the majority of the cases. What definitely does not work is hot-unplugging. There is no reliable mechanism that could be used to find out if a Bricklet is not plugged in anymore. The biggest problem with the unplugging is the routing tables that the Brick Daemon and each Brick has*. However, if you replace a Bricklet with another Bricklet of the same kind and the same UID, there is no problem with the routing tables. The only problem is that the new Bricklet does not have the settings anymore that you set in the old Bricklet. So maybe you can have a loop that reads a configuration (that is set to some non-default value) every few seconds and assumes that a new Bricklet was put in if it changes back to default? * Example: You have a stack that is connected to another stack with RS485 and your Bricklet is connected to a slave in the stack. If you call a function in your program the data will be send to the Brick Daemon. The Brick Daemon sends it to the correct USB port to a Master Brick, the Master Brick sends it via RS485 to the other Master Brick which sends it to the slave in the stack which send it to the correct Bricklet port. Every Brick in the chain and the Brick Daemon has a "routing table" that it uses to determine where a packet has to go. If you now unplug this Bricklet and plug it in somewhere else, the routing tables will be permanently broken and messages to this Bricklet may or may not be routed correctly.

The protocol that is used between the Bricks and Bricklets is unfortunately not well documented. You can find some information here: https://github.com/Tinkerforge/brickletboot_xmc/blob/master/software/src/bootloader_spitfp.c#L24 The payload is the same as in the TCP/IP TFP specification: https://www.tinkerforge.com/en/doc/Low_Level_Protocols/TCPIP.html

Was kannst du bei "WLAN Modus" alles einstellen? Vielleicht einmal testweise 5GHz ganz ausmachen oder nur Modus "n" einstellen wenn das geht. Du könntest auch einmal schauen ob es etwas bringt wenn du einen festen Kanal einstellst?

Leider schwer zu sagen was da jetzt genau das Problem ist . Ich hab das gerade vorsichtshalber nochmal getestet hier, ich kann mich mit der aktuellen WIFI Extension 2.0 Firmware mit allen Routern per WPA2 verbinden die wir hier haben (Fritz Box, tp-link und linksys). Kannst du vielleicht vorsichtshalber nochmal einen Screenshot von der Router-Konfiguration und der WIFI Extension-Konfiguration hier posten? Vielleicht ist es ja doch noch irgendeine einfach Fehlkonfiguration.

Hat der AP denn irgendwelche Einstellungsmöglichkeiten für die Verschlüsselung? Oder nur Verschlüsselung an/aus?

Firmware: GPS V2 Bricklet 2.0.6 Berechnungs-Overflow bei Geschwidigkeiten >=214.74km/h gefixt Download: GPS Bricklet 2.0

Firmware: GPS V2 Bricklet 2.0.6 Fix speed overflow at speeds >=214.74km/h Download: GPS Bricklet 2.0

Indeed, i looked at the code and mathematically the calculation that we have in there for the speed overflows at values > 214.74 km/h! I just released version 2.0.6 that has this fixed. Thank you for bug report!

Sorry for the late answer, we had to ask around ourselvs to see what the current state is. The GPS module that we use on the Bricklet is a "FireFly X1". It was originally manufactured by GlobalTop and they told us that they will backport Galileo support. However, GlobalTop was bought by Sierra Wireless and they deprecated the series of FireFly GPS modules. The new Sierra modules are now called AirPrime XM. I think it is very likely that there will not be any more updates for the FireFly modules, so the Galileo support will only come with the next hardware update of the GPS Bricklet. We will change the documentation about that, since it is a bit misleading now.

Du kannst in deinem Fall die Werte mit der Folgenden Formel umrechnen: Beschleunigung = Rohwert*625/1024 Damit kommst du dann wieder auf die g/10000 Einheit die auch von get_acceleration() zurückgegeben wird. Das ist jetzt in der API Doku auch entsprechend erklärt und dokumentiert: https://www.tinkerforge.com/de/doc/Software/Bricklets/AccelerometerV2_Bricklet_Python.html#BrickletAccelerometerV2.set_continuous_acceleration_configuration Vielen Dank für den Hinweis, da hat jemand zwischen Programmierung und Dokumentation die Hälfte vergessen und dadurch nicht richtig dokumentiert.

Oh, ich hab mir gerade den Code angeschaut und du hast absolut recht. Die Continuous Callbacks geben den rohen ADC-Wert zurück der Abhängig von anderen Einstellungen ist, während der Getter (den der Brick Viewer nutzt) g/10000 zurück gibt. Unsere Dokumentation ist an der Stelle fehlerhaft. Ich fixe das in der Doku und melde mich dann nochmal wenn ich es fertig hab.