Jump to content

theobald

Members
  • Content Count

    15
  • Joined

  • Last visited

Everything posted by theobald

  1. also mir ist es bisher leider nicht gelungen, das Problem zu lösen. Kann mir vielleicht ein JS-Profi etwas behilflich sein? Ich habe jetzt: var device_promises = []; und... // Register Connected Callback ipcon.on(Tinkerforge.IPConnection.CALLBACK_CONNECTED, async function (connectReason) { await enumerateDevices(); } ); und später... ipcon.on(Tinkerforge.IPConnection.CALLBACK_ENUMERATE, // Print incoming enumeration function(uid, connectedUid, position, hardwareVersion, firmwareVersion, deviceIdentifier, enumerationType) { const dp = new Promise(resolve => {
  2. Moin rtrbt, danke! Ja genau! Man weiß nicht, wieviele Bricks/Bricklets sich zurückmelden... Ich werde mich mal in das Problem vertiefen... Wenn ich eine Lösung finde, dann schreibe ich nochmal... Grüße vom Theo
  3. Guten Morgen in die Runde! ich möchte die Daten aus dem Enumeration Callback (Javascript im Browser) in ein Array schreiben (was recht einfach ist). Allerdings kann ich das Array nicht weiter verwenden, da es asynchron erstellt wird. Während nun mein Hauptprogramm in Javascript (im Browser via WebSockets) weiter läuft und im nächsten Aufruf das Array (z.B. var devices = []) lesen will, so hat ipcon.enumerate() das Array aber noch nicht gefüllt, weil es nebenläufig ist. Das ist kniffliger, als ich dachte. Kann mir da jmd. einen Tipp geben? Was habe ich versucht - oder besser ange
  4. 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??
  5. 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...
  6. 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.)
  7. 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
  8. Danke für die Antwort. Kein Problem! Man muss es nur wissen...
  9. ...alles OK. Hat sich von selbst erledigt. Das Update dauert bis zu den Ruby-Bindings ca. 30sec. Danach benötigt es ca. 90min. Das war mir nicht bewußt. Jetzt ist alles up to date!
  10. Hallo in die Runde, ich habe ein Red Brick im Januar erworben und musste dann arbeitsbedingt das Projekt etwas liegen lassen. Nun habe ich den Red Brick wieder in Betrieb genommen und der Brickv 2.4.14 zeigt mir ein Update von 1.15 auf 1.15+. Leider lässt sich das automatische Update nicht ausführen. Es läuft problemlos bis zu den Ruby-Bindings und hängt sich dort auf. Dann kann man nichts mehr machen und muss den Brickv beenden. Ist dieser Effekt bekannt? Wie kann ich das Problem beheben? Viele Grüße. Theo
  11. Danke KlausGünther für die Antwort! Ich habe mittlerweile mit dem Hersteller des "Baumes" Kontakt aufgenommen. Es handelt sich nicht um solche Messgeräte wie den TX20 o.ä., der ja über ein serielles Protokoll alle 2s genaue Messerte leifert, sondern bei Wind und Windgeschwindigkeit um ein Widerstandsnetzwerk. Je nach Windrichtung und Windgeschwindikeit wird dann ein Widerstand wirksam. Ja Bodenfrost möchte ich schon messen. Werd ich auch machen Wie schon erwähnt, ich habe einen eigenen Prototyp einer Wetterstation mit dem ESP8266 gebaut. Der funktioniert prima. Dort verwende ich d
  12. Hallo in die Runde! Ich muss mein altes Thema nochmal aufwärmen! Ich möchte ein serielles binäres Signal mit 5V Pegel auf einer Zweidrahtleitung decodieren. Jedes Bit benötigt 1,2ms. Das Signal ist nicht standardisiert (also eine UART kann man nicht verwenden), dauert 42.9ms und wiederholt sich alle 2s. Mit den ESP32 habe ich das mit C++ via Interrupt-Handler realisiert. Ich würde das Programm nun gern auf einem RED Brick mit Hilfe des Digital In 2.0 Bricklets oder einem RASPI 4 mit HAT Brick implementieren wollen. 1.) Geht das mit einem Industrial Digital In 2.0? Ich habe mir den Quel
  13. Danke borg! diese Aussage habe ich schon in früheren Posts gelesen. Aber dennoch vielen Dank! Ich meine den hier hellblau als GPIO markierten Stecker: aber die Frage bleibt dennoch: Wenngleich ich bei Euch keinen Stecker bekäme, kann ich diese Schnittstelle an sich ansteuern? Wenn ja, wie? Wenn nein, ich möchte ein serielles binäres Signal mit 5V Pegel auf einer Zweidrahtleitung decodieren. Jedes Bit benötigt 1,2ms. Das Signal ist nicht standardisiert, dauert 42.9ms und wiederholt sich alle 2s. Mit den ESP32 habe ich das mit C++ via Interrupt-Handler realisiert. Ich würde das Pro
  14. Hallo in die Runde, ich bin neu hier und habe mal etwas gestöbert. Ich würde gern die GPIO auf dem RED Brick verwenden und habe nach längerem Stöbern nur ältere Postings gefunden, wo gesagt wird, dass die GPIO schwer zu steuern sind oder "noch" nicht funktionieren. Ist das noch so oder kann man die jetzt aktuell nutzen? Wenn man sie nutzen kann, gibt es Beispielcode? Wo? Tutorials? Einen Link auf die API? Kann man Interrupte auf die GPIO legen? Viele Grüße vom Theo
  15. Hallo in die Runde, die o.g. Fragen sind auch für mich sehr interessant und teilweise nicht beantwortet. Warum nicht? Auch vielen Dank @KlausGünther. Die Richtlinie des DWD kannte ich bisher nicht. Ich habe immer derartige Texte gesucht, aber leider nichts gefunden. Das mag natürlich auch an mir liegen . Erstaunlicher Weise schreibst Du @KlausGünther, dass eine Messung am Boden nicht lohnt. Die von Dir verlinkte Richtlinie sieht das aber anders. Dort wird die bodennahe Temperaturmessung in 5cm Höhe und auch die Messung von Bodenfrost in 10cm bis 100cm Tiefe ebefalls empfohlen. Um nun
×
×
  • Create New...