welches Bricklet für digital in mit 1kHz?

[theobald]

Hallo allseits,

kann mir jmd. noch einen Tipp geben, mit welchem Bricklet ich ein digitales Signal mit einer Pulsbreite von ca. 1ms dekodieren könnte? In den Beispielen z.B. vom Industrial Digital IN 4 steht was von 10ms oder 100ms. Ich möchte gern ein Rechtecksignal mit 1ms dekodieren. Ein Red Brick solls dann berechnen...

Ich bin auch für andere Empfehlungen dankbar.

Viele Grüße.
Theo

bearbeitet September 16, 2020 at 12:40 von theobald

[rtrbt]

Moin,

Wenn du mit dekodieren meinst Duty-Cycle, Frequenz usw. zu bestimmen und die Flanken zu zählen, kannst du das Industrial Counter Bricklet verwenden.

Gruß,
Erik

[theobald]

Moin,

na ich möchte ein serielles Signal dekodieren. Es besteht aus 42 Bits, die nacheinander reinkommen (nicht konform, also kein RS232C etc). Sie müssen aber noch verrechnet werden (Prüfsumme, Addieren, Invertieren etc.)

[rtrbt]

Hm, da wirst du ohne größere Hacks kein Bricklet finden, das das kann. Du müsstest ja nach Nyquist-Shannon mit 2 kHz abtasten.

Das höchste was du mit einem Bricklet hinbekommen würdest (und das ist aber eher ineffizient) wäre ein IO4 2.0, damit kannst du theoretisch mit 1 kHz sampeln also 500 Hz messen, aber da bin ich mir nicht sicher, ob das im Bricklet so implementiert ist, das man das tatsächlich schafft.

Ich fürchte da bleibt dir nur, einen Mikrocontroller o.Ä. zu nehmen, damit das Signal auszuwerten und das dann irgendwie anders zu kommunizieren. Wenn du Lust auf Firmware-Programmierung hast und im Tinkerforge-Universum bleiben willst, kannst du ein XMC-Breakout Bricklet nehmen.

Alternativ: (Da ich gerade deinen Post aus dem Oktober gesehen habe) Wenn du das ganze auf einem ESP32 zum Laufen gebracht hast könntest du auch von da die Informationen per WiFi an den RED-Brick oder Raspberry Pi kommunizieren.

[theobald]

Hallo rtrbt,

danke für Deine Tipps! (ja das Sampling-Theorem :O) Ich dachte immer der ARM auf dem Red Brick wäre (prinzipiell) schneller als der ESP8266 ? Auf dem ESP geht das dekodieren ganz leicht über einen Interrupt-Handler. Der Red Brick hat doch auch Interrupts oder? Sollte man da vielleicht direkt auf die GPIO gehen? (ja das habe ich schonmal gefragt im Januar 2020 oder so :O) Vielleicht könnte man dan einen Interrupt-Handler in C++ schreiben. Ich habe das auf dem ESP8266 gemacht. Da geht das recht gut...

bearbeitet September 16, 2020 at 13:50 von theobald

[rtrbt]

10 minutes ago, theobald said:

Ich dachte immer der ARM auf dem Red Brick wäre (prinzipiell) schneller als der ESP8266

Ist er, du hast aber zwei Probleme.

1. Die Signale zum RED-Brick zu bekommen, aber wenn du mit den GPIOs schon mal was gemacht hast sollte das gehen (Hast du dann Drähte angelötet oder wie kommst du da ran?)

2. Ist die Frage wie du Interrupts bekommst, da musst du vermutlich einen Kernel-Treiber schreiben o.Ä. Das Linux auf dem RED-Brick ist allgemein eher langsam, im User-Space bist du da von "Echtzeit-Fähigkeit" weit weg.

Damit du nicht unnütz viel Zeit investierst: Es wird in den nächsten Monaten einen ESP32-basierten Brick geben, an dem neben den Bricklet-Ports noch ein paar GPIOs rausgeführt werden. Wenn dein Anwendungsfall einfach ist dieses Signal zu lesen und noch ein paar Bricklets daneben zu verwenden, kannst du auf den ESP32-Brick warten, dann kannst du deine Implementierung weiterverwenden.

[theobald]

Na das ist doch prima! Da warte ich auf den ESP32. Der Code vom 8266 läuft im Wesentlichen auf dem ESP32 - vielleicht sogar noch etwas robuster, denn der 8266 hat ja manchmal Probleme mit den Interrupts, wenn sie im falschen RAM liegen...

Mir genügen zwei freie GPIO, um den Interrupt anzubinden. Da könnte ich gleich meinen Sensor weiter betreiben und den ESP dekodieren lassen...

Danke!

PS: Ist schon raus, wann der ESP-Brick ungefähr verfügbar sein wird??

[rtrbt]

17 hours ago, theobald said:

Ist schon raus, wann der ESP-Brick ungefähr verfügbar sein wird??

Man soll ja nichts versprechen, aber ich bin mal optimistisch und behaupte dieses Jahr noch.