borg

Die Wetterstation vergibt sich selbst eine zufällige ID bei Einlage der Batterie. Wenn die ID bereits vergeben ist musst du die Batterie rausnehmen und wieder reinlegen. Die ID wird spätestens nach 45 Sekunden "gelöscht" (wenn der Sender versucht Daten zu senden). Wir haben für das Outdoor Weather Bricklet extra ein Empfägermodul genommen welches auf die exakte Frequenz der Wetterstation ausgelegt ist, sollte also eigentlich guten Empfang haben. Eine einfache Möglichkeit die Wetterstation zuzuweisen ist es, ein Programm zu schreiben welches auf Knopfdruck o.ä. die IDs abfragt bis eine neue hinzu kommt. Diese ID ist dann eure Wetterstation. Dann könnt ihr den Knopf drücken und danach in Ruhe die Batterie einlegen. In eher "ländlichen" Gegenden wo die Wahrscheinlichkeit gering ist das es eine zweite Wetterstation gibt kann man natürlich auch einfach immer die eine ID nehmen die gefunden wird .

Tja, wir nutzen ja den RFM69 auf dem Remote Switch Bricklet. Der kann direkt die Daten digitalisieren und wir lesen sie per SPI aus. Dafür gebe ich die Frequenz an (433MHz) und eine Bitrate damit er es digitalisieren kann. Das Problem was wir hier gerade sehen ist denke ich, das die Bitraten ganz schön Unterschiedlich sind von Fernbedienung zu Fernbedienung (die Frequenz passt immer). Das passiert auf jeden Fall bei der Bricklet zu Bricklet Kommunikation hier. Wir nutzen für Typ C z.B. 319us pro Taktzyklus zum Senden (hab ich so per Trial-and-Error als besten Wert bestimmt) während ich (auch per Trial-and-Error) zum Empfangen 356us pro Taktzyklus bestimmt hatte. Das ist bereits soweit auseinander, dass der RFM69 da nicht mehr mit klar kommt nach ein paar Repeats. Die einzige Möglichkeit die ich da aktuell sehe ist das extrem überabzutasten. D.h. ich lese mit einem Taktzyklus von 30us (anstatt der ~300us die es wirklich sind) und kann das dann "analog" interpretieren und z.B. eine Bitrate zwischen 270us und 330us erlauben. Auf die Schnelle konnte ich im Datenblatt keine Spezifikation dazu finden ob ich der RFM69 so hohe Bitraten auch wirklich digitalisieren kann, muss ich dann testen. Ist auf jeden Fall keine 5-Minuten-Aufgabe, ich melde mich wieder wenn ich da mehr Infos habe.

Ich würde erwarten das 15m eigentlich funktionieren sollte. Du könntest schauen das die Antenne in Richtung Sensor zeigt (also nicht mit der Spitze, sondern mit der Seite der Antenne). Funk ist da ja manchmal ganz verrückt und eine kleine Änderung hat da eine große Wirkung.

Das kann ich nicht reproduzieren, bei mir funktioniert das. Bei Typ A kriege ich jedes Repeat mit, ohne Ausnahme. Bei Typ B sehe ich aus irgendwelchen Gründen nur so ~3/4 der Repeats die ich Sende. Bei Typ C noch weniger als bei Typ B. Ich gucke mir da mal an wo das Timing auseinander Läuft, das kann ich ja schonmal fixen. insidERR hat uns jetzt seine Fernbedienung zugeschickt, die bringe ich dann auch zum laufen. Ich hab hier eine Kiste mit gut 15 unterschiedlichen Steckdosen/Fernbedienungen liegen die ich getestet hab. Da gibt es anscheinend immer noch mehr Varianten... Da wirste echt bekloppt bei .

Der Sensor sollte ca alle 45 Sekunden Daten schicken. Wenn du den Getter nutzt gibt es den "last_change" Parameter der dir sagt wann das letzte mal Daten empfangen wurde. Kannst du den vielleicht mit plotten um zu sehen ob du in der Zeit wo sich der Wert nicht ändert keine Daten empfängst?

Mh, ich dachte ich hätte so eine Fernbedienung auch getestet, wahrscheinlich gibt es da einfach noch mehr Varianten als wir da haben. Das Bricklet versucht ja schon das Protokoll wirklich zu verstehen und vergleicht nicht einfach mit Aufzeichnungen.

Das ist eine gute Frage, das hab ich noch gar nicht ausprobiert . Ich kann gerade nicht sehen warum das nicht funktionieren sollte. An und für sich nutzen wir ja die gleichen Timings für das Senden und das Empfangen, daher wundert mich das gerade schon. Gucke ich mir auf jeden Fall an, vielleicht können wir ja das insidERR Problem damit auch fixen .

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.