Jump to content

Nic

Members
  • Gesamte Inhalte

    1.425
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von Nic

  1. Nehmen wir an du kannst das Nadelöhr USB irgendwie umgehen und der HostPC bzw. RED empfängt und verarbeitet die Interrupts und Bricklets ohne Umweg dann kommst du mit den TF-Teilen niemals schneller als 1ms:

    http://www.tinkerunity.org/forum/index.php/topic,2525.msg16509.html#msg16509 und

    http://www.tinkerunity.org/forum/index.php/topic,2127.msg14118.html#msg14118

     

    Ich würde mal sagen, dass die TF Firmware und Protokoll quasi wie im Zeitscheibenprinzip konzipiert ist.

  2. Alternativer Ansatz serverseitig und ev. mit angenehmeren Sprachdialekt als Phython (Geschmackssache ;) ) mit Node.js bzw. Javascript und ev. in Kombination mit den Websockets. Node.js ist im RED enthalten und mit http.createServer erzeugt man einen kleinen Webserver der auf Requests vom Browser lauscht. Beispiel unter http://www.sitepoint.com/creating-a-http-server-in-node-js/.

     

    Websockets werden z.B. in der Beispielanwendung von TF IOT http://www.iot-remote.com/ ganz gut gezeigt.

  3. nach Sockets in der Tinkerforge API.

    Sockets werden zum Zweck der Kommunikationsschicht in der Tinkerforge API intern verwendet. Remotecontrol meinte eher an ein eigenes, selbstgeschriebens Protokoll von dir, das ebenso Sockets verwendet.

    am besten eine Kommunikation zwischen RED-Brick und einer Android App um

    Ev. würden Websockets besser passen als ein Komm.Protokoll neu aufzurollen. Mittels der Websockets die dann spätestens im Image 1.4 vom RED unterstützt werden, sollten sich sich Web-Anwendungen schreiben lassen, die im Android z.B. nur den Browser erfordern.

  4. Ich meine irgendwo gelesen zu haben, dass für den Red Brick die Kommunikation zwischen den Bricks und Bricklets geändert werden musste.

    Mit dem RED wurde quasi der HostPC näher zu den Bricks/Bricklets gebracht, d.h. die Kommunikation über USB ist dann nicht mehr gegeben. Der RED kommuniziert intern mit den Bricks über das SPI Interface.

    Allerdings bedingt durch die USB Anbindung von Anfang an, ist auch das interne SW-Design ausgelegt auf höchstens 1ms Auflösung egal ob nun via USB oder SPI.

     

    Was noch noch gar nicht erwähnt wurde, ist die IO Schnittstelle am RED die bisher sw-und hw-seitig noch nicht unterstützt wird. Aber ich bezweifel ob damit wesentlich schnellere Verarb. als mit den Brick-Teilen möglich ist, dann wird das zum Tragen kommen was borg schon bzgl. der Betriebssystem-Limits erwähnte.

     

    Mich würde interessieren warum der Verlust von 10-20ms dir zu lang ist ?

  5. Also ich ziehe einfach den USB Stecker und dann ist der Stack nicht mehr unter Strom. Das hatte bei den deployten Programmen bisher keine negativen Auswirkungen. Allerdings wurden auch keine Schreibvorgänge gemacht.

     

    Für solche Anwendungen reicht es den Strom per Schalter zu unterbrechen, idealerweise bei der Eingangsspannung ins PowerSupply.

     

    So habe es gerade als root auf der Console ausprobiert, geht prima:

    shutdown -h now

    . Damit fährt man den RED runter. LEDs glühen ein wenig nach und dann nach etwa 2-3sec. geht alles aus.

    Restart mit Knopfdruck am RED.

    shutdown -r 1

    Löst z.B. ein Restart in 1 Minute aus. Hab es getestet.

     

    Keine Ahnung ob man sowas ev. von außen auslösen könnte etwa über die Shell-Bindings und das Event Knopfdruck auf Lcd, Button Bricket etc programmatisch abfangen.

  6. Kann es sein dass ihr beiden einfach nur die tatsächliche Luftfeuchtigkeit der Umgebung erfasst, und noch etwas Meßungenauigkeit den Wert auf die volle 100% schiebt ?

     

    Hier auf der Karte sieht man deutlich wie es in Deutschland bzgl. Feuchte aussieht: http://www.neuwetter.de/vorhersage/luftfeuchtigkeit.html

     

    Norddeutschland zw.97-100% !

     

    Zum Testen den Sensor in der Wohnung "trocknen" lassen und prüfen wie sich der Messwert verhält.

  7. Erst mal eine Gegenfrage, warum geht der RFID Bricklet nicht ?

    http://www.tinkerforge.com/de/doc/Hardware/Bricklets/NFC_RFID.html

     

    Überschätze Linux nicht zu hoch ;) Meine Linux Kenntnisse waren auch bei NULL, zwar bin ich mit VC20, c64, DOS/Win3.x aufgewachsen, aber erst durch den RED habe ich angefangen mich mit Linux richtig zu beschäftigen. Ich möchte nicht behaupten, daß ich da schon fit bin. Aber es ist meistens eine Gewöhnungssache, bzw. mir ist es schon gelungen, Hardware und neue Software per Console zu installieren. Und was das Programmieren, Hochladen und Deployen von eigenen Programmen angeht, so war das beim RED in etwa 10 Min. erledigt und lauffähig ;D.

  8. Habe die aktuelle Version von Iceweasel v31.4 (=Firefox) auf den RED installiert. Unter https://html5test.com bekomme ich einen Score von 426, Websockets werden komplett unterstützt. Aber beim EnumExample bekomme ich weiterhin eine Error 13.

     

    Vermutl.identisch mit http://www.tinkerunity.org/forum/index.php/topic,2788.msg17706.html. Der Workaround/Bugfix löst aber nichts, der BrickD kann nicht wieder gestartet werden.

  9. Habe am DesktopPC die Websockets freigeschaltet mit Port 4280, listen Address bleibt bei 0.0.0.0. Lade das Beispiel unter http://www.tinkerforge.com/de/doc/Software/Examples/JavaScript/IPConnection_JavaScript_ExampleEnumerate.html.

    Enum gibt alle am PC angeschl. Bricks zurück.

     

    Schalte die Websockets am RED ebenso auf die 4280, dabei verwende ich den BrickV am DesktopPC

    Per RemoteDesktop verbinde ich mich zum RED-Desktop. Starte den Midori Browser und lade die o.g. Beispielseite. Am RED ist nur ein Master angesteckt. Enum gibt aber nur Error 13 zurück. Habe ich etwas übersehen ?

     

    Image Full 1.3

    Clipboard01.png.ef0f182537ddd9d87d5aeb8e960a5c8b.png

  10. Da hat sich m.W. noch nichts geändert !

    Der RemoteSwitch kann - so wie er aktuell ausgeliefert wird - nur senden.

    Der RemoteSwitch agiert quasi wie die Fernbedienung für Funksteckdosen:

    Kompatibilität gem.:

    http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Remote_Switch.html#liste-unterstutzter-gerate

     

    Augenblicklich lassen sich Stacks per Funk nur über die WiFi-Extension plus Master bzw. RED plus Wlan-Stick plus Master (falls zusätzl. Bricklet Ports gebraucht werden) steuern.

  11. Es wäre sicher toll eine Liste von möglichen Motoren (Schritt-, Drehmotoren) verschiedenster Art die mit TF zusammenarbeiten zu haben

    I.d.R. wenn die Motoren den gängigen Industrie-Standards entsprechen, sollten viele Modelle an den Bricks funktionieren. D.h. diese Liste würde irgendwann den Rahmen des Portals sprengen. Aktueller wäre hier ins Forum zurückzukommen und die User um Rat zu fragen.

    Was Schrittmotoren mit Getriebe angeht, so bin ich mit diesen hier sehr zufrieden:http://www.omc-stepperonline.com/. Import aus CH und erfordert etwas Wartezeit  ;D

     

×
×
  • Neu erstellen...