borg

RED Brick Image 1.11 ist jetzt veröffentlicht und bringt die alte Performance wieder zurück (+ ein bisschen mehr ): https://www.tinkerforge.com/de/blog/red-brick-image-111-big-performance-boost/

RED Brick 1.11 image is now released with big performance boost again! https://www.tinkerforge.com/en/blog/red-brick-image-111-big-performance-boost/

Beim senden gibst du die Anzahl der Repeats an (also quasi wie lange du den Knopf drückst) und beim Empfangen gibst du an wie viele Repeats du sehen musst bis der Empfänger reagiert (also die minimale Zeit wie lange jemand den Knopf drückt). Du könntest also höchstens die Repeats auf 1 stellen.

Ich hab das gerade nochmal getestet, bei mir funktioniert das einwandfrei mit einer Elro Typ A Fernbedienung. Folgender Vorschlag: Wir haben reichlich Fernbedienungen hier übrig, können wir dir davon eine zuschicken? Falls die funktioniert, kannst du uns dann vielleicht deine zurück schicken? Ich vermute dass das Timing bei deiner Fernbedienung etwas anders ist und wir damit nicht klarkommen. Alternativ, falls unsere Fernbedienung bei dir auch nicht funktioniert, sind bei dir in der Umgebung mehr "Daten" auf dem 433MHz-Band und wir sind da nicht robust genug. Könntest du einmal eine Lieferadresse für die Fernbedienung an olaf@tinkerforge.com schicken?

It is a "push-in connector". So you can just push the wire in with force and it will hold it. To release the wire you can use a screwdriver to press down the orange thing that sticks out. If your wire is not stiff enough to be pushed in, you have to press down the orange thing during inserting too.

Wenn du mit der Fernbedienung näher an das Bricklet rangehst funktioniert es besser? Also ist es ein Empfangsproblem oder ist es ein generelles Problem? Falls es ein Empfangsproblem ist: Ist die Antenne fest reingeschraubt? Kannst du mit der Bricklet die Steckdose schalten oder klappt das auch nicht?

Welche Version hat das RED Brick image? Das RED Brick hat Support für die neuen Co-Prozessor Bricklets (die mit dem 7-Pol Stecker) erst seit Image-Version 1.9.

Schwer zu sagen, hast du getestet ob die Jumper mechanisch richtig sitzen? 2/3-Leiter ist korrekt eingestellt?

There is no detailed calibration curve from sharp, the differences between the sensors are in the range of +-2cm full-scale depending on the distance in our tests. We took one sensor per type and made a distance/voltage lookup table. You can find the table here (for the 2Y0A21 for example): https://raw.githubusercontent.com/Tinkerforge/distance-ir-bricklet/master/software/calibration/2Y0A21.txt The Bricklet does a simple linear approximation with this table and does some averaging over the analog values to remove as much noise as possible. You can upload a new table to the Bricklet if you want to calibrate for your specific sensor: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Distance_IR.html#verfugbare-spannung-distanz-abbildung As far as i know there are no noise figures from sharp (which is a good indication that there is lots of noise).

Beside resolution you also have to look at precision and accuracy We indeed have plenty resolution with the 12 bit ADC for 1mm steps, but the sharp sensors unfortunately does neither have enough precision nor accuracy to make any smaller steps useful.

Sounds like a good idea to me. We have to update the kit anyway, to make it compatible to the new 2.0 version of the Remote Switch Bricklet.

Das geht, ja .

Sollte kein Problem sein. Einfach - an "-" anschließen und + an "M" anschließen und alle anderen Anschlüsse offen lassen.

Außensensor für Wetterstationen, neues NFC Bricklet, Produktupdates Blogeintrag

Outdoor Weather Station, new NFC Bricklet and product updates Blog Entry

Genau dafür ist das Bricklet gedacht. Hat der Füllstandssensor ein Datenblatt? Ohne irgendwelche Details zu kennen, ist schwer Aussagen darüber zu machen wie man etwas anschließen muss. Die Allgemeine Beschreibung dazu findest du hier: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Industrial_Dual_020mA.html#anschlussmoglichkeit

Sehr mysteriös. Ich konnte es bisher nicht reproduzieren. Wir können das Temperature IR Bricklet noch nichtmal testweise austauschen, da wir keine mehr auf Lager haben (hab nur noch eins zum testen hier). Folgender Vorschlag: Nächste Woche komme das neue Temperature IR Bricklet 2.0 raus (gleicher Sensor), wir schicken dir davon dann einfach welche zu. Wenn das Problem dann immernoch auftritt müssen wir weiter schauen.

Das ist ja interessant, ich baue das mal mit 200cm Kabeln hier nach. D.h. wir haben vielleicht bei dem TempIR sowas wie einen Bitflip und das bringt dann den ganzen I2C Bus in die Knie aus irgendwelchen Gründen? Ein Bitflip sollte eigentlich gerade beim TempIR gar nicht schlimm sein, das sendet nämlich mit jeder Abfrage eine CRC mit.

Wir haben aktuell keine offenen Probleme die wir reproduzieren können. Das letzte Problem was wir reproduzieren konnten war das USB/EMV Problem welches zu neustarts führen konnte. Das wurde in 2.4.6 gefixt, da hatten wir aber auch etwas an I2C geändert. Deswegen dachte ich du könntest einmal mit der älteren Version testen. Aber wenn du das Problem schon so lange hast kann es daran ja gar nicht liegen.

Kannst du mal einmal mit Master Brick Firmware Version 2.4.5 testen? http://download.tinkerforge.com/firmwares/bricks/master/ Das ist die letzte Version bei der wir die I2C-Kommunikation noch nicht auf DMA umgestellt haben (Temperature und Temperature IR Bricklet nutzen beide I2C).

Welche Firmware-Versionen haben die Bricks/Bricklets?

Ich befürchte das ist nicht möglich. Der Prozessor den wir verwenden läuft mit 32MHz, wir sprechen mit dem Lepton mit 8MHz. D.h wir haben 4 Prozessortakte pro Bit an Daten zur Verfügung. Damit müssen wir das Protokoll mit dem Lepton sprechen, die Daten Zwischenspeichern, API-Aufrufe abarbeiten, das Protokoll mit dem Brick sprechen und I2C mit dem Lepton zur Konfiguration, etc.

Bezüglich der CPU Last: Wir haben das gerade nochmal diskutiert und uns die Tests angeguckt die wir gemacht haben etc. Wir sehen da zwei Dinge: 1. Der RED Brick mit 1.10 Image nutzt jetzt den Linux CPU frequency scaling governor. D.h. per Default wird die Frequenz runtergetaktet und nur erhöht bei hoher Last. Dadurch zieht der RED Brick weniger Strom und bleibt kälter. Allerdings sieht die CPU Last dadurch höher aus (höhere Auslastung bei niedrigerer Frequenz). 2. Wir haben mit 1.10 auf den aktuellen neuesten Linux Mainline Kernel gewechselt. Für unsere Anwendungszwecke ist der SPI Treiber dort leider erheblich ineffizienter geworden. Das liegt soweit wir das verstehen hauptsächlich daran das die Treiber in der Zwischenzeit mehr auf Multiprozessor-Systeme ausgelegt sind, welches wir bei dem RED Brick leider nicht haben. Wir haben dort schon angesetzt und das für unseren Use Case verbessert. Hier sind die ganzen Änderungen die wir im Linux SPI Treiber gemacht haben: https://github.com/Tinkerforge/red-brick-linux/commit/2082ee9458d1bd553fb2c1b933162b3beabc8332 Nichtsdestotrotz, wenn wir das 1.9er Image mit dem 1.10er Image per Stress-Test vergleichen können wir sehen dass das 1.9er Image in der Tat immernoch performanter ist. Wir arbeiten aber noch daran, man kann mit bei sowas leider sehr viel Zeit versenken .

Welche Firmware Version hat das NFC/RFID Bricklet? In Version 2.0.1 gab es folgenden Fix:

Du solltest den brickd eigentlich nie neustarten müssen, da ist irgendetwas faul. Funktioniert es wenn du nur einen Master Brick verwendest (oder den anderen)? Funktioniert es ohne die Bricklets? Also die Frage ist: Was ist der kleinste Aufbau mit dem du das Problem noch erzeugen kannst?