Jump to content

Nic

Members
  • Content Count

    1425
  • Joined

  • Last visited

Posts posted by Nic

  1. Very interesting issue, never thought about to calculate estimated time of arrival, but would be fine to have it.

    My first clue would be to use the callback AllDataCallback

    Ref.:https://www.tinkerforge.com/en/doc/Software/Bricks/SilentStepper_Brick_CSharp.html#callbacks

    It returns also remaining steps and current velocity [steps/s] that gives y a rough base to calculate the time?!

     

    By callback NewStateCallback y could differenciate more precisly between (de)acceleration- and run state.

  2. Hi Erik,

    prima, dass ihr weiterhin das Mqtt Protokoll unterstützt.

    Am alten Proxy habe ich immer geschätzt, dass man ohne eine Codezeile schreiben zu müssen, in einem Mqtt Client die Brick Daten adhoc sofort sehen konnte.

     

    Verhält sich die neue Variante genauso, sprich auf Kommandozeile starten und anschließend mit Clients verbinden und subscriben?

     

    Ev. habe ich das in den Doku übersehen: wie oder wo lässt sich der Mqtt-Broker Host/IP und Port angeben?

     

    Gruß,

    Nic

  3. Bei den PI-RTC war meist ein zusätzlicher Treiber zu installieren wenn ich mich nicht irre  :o ?! Wenn ein integrierter RTC nicht zuviel Platz (Zero?) von der HAT-Platine akquiriert und zwangsläufig nicht auf interessantere Features verzichtet werden muss, unnötig Pins belegt werden, die wir brauchen, ist mir das egal.

  4. Die ersten Entwürfe sehen schonmal sehr gut aus :)

     

    Ich bekomme aber ziemliche Kopfschmerzen bei dem Gedanken, dass die Bricklet Buchsen um 90° Grad von der Platine abstehen. Das wird Platz beim Einbau später kosten und insbesondere beim Pi Zero seine Kompaktheit einbüßen. Bei diesem USB Hub HAT sind die Buchsen z.B. liegend und am Rand angeordnet: http://www.uugear.com/product/zero4u/

     

    Eine Maxi-Variante für Pi 2/3 und eine Light-Variante für den Zero mit 2-3 Bricklet-Buchsen liegend, wäre u.U. ein Kompromiß. Eine RTC muss nicht sein, wir haben im Sortiment ein hervorragendes RTC-Bricklet.

     

    Viel besser fände ich einen vernünftigen On/Off Switch fürs Gesamtsystem (ähnlich wie z.B. https://thepihut.com/products/onoff-shim)

     

    Wo ist auf der Abbildung der Anschluss für die LiPo/Ion Zelle?

    Bitte wenn möglich den quasi Standard JST 2.0 als Buchse (wie z.b. beim Lipo-Rider http://wiki.seeedstudio.com/Lipo_Rider_Pro/).

    Soll der Akku das Gesamtsystem oder nur den HAT versorgen?

     

    Werden vom HAT dann nur die SPI Pins vom GPIO Header belegt oder auch weitere Pins?

  5. Hammer! Damit habt ihr den Bricks nochmal einen richtigen Quantenschub gegeben :o;D

     

    Konnte das Projekt nach Upgrade auf Android Studio v3, downloads des NDK und einigen Zusatzlibs prima bauen und per ADB Remote Connection auf ein (Ur-)altes WikoBloom mit Android 4.4.2 deployen und starten.

    Im Gradle ist MinSdk API 15 also Support bis runter auf Android 4.0.3.

     

    Allerdings muss der Brick-Stack vor dem App-Start am USB-Port angeschlossen werden. Ein Enumerate durch Hotplug geht nicht. Auf einem Win10 und BrickViewer kann ich mich mit dem Stack verbinden und die Bricks/Bricklets werden gelistet. Super!

     

    Also wenn man jetzt noch in der Main-Activity UI die Log-Ausgaben zeigt und in der Android API z.B. das USB-Connect Event abgreifen könnte, um ein Enumerate auszulösen, wäre für mich schon Weihnachten :)

  6. Der main Thread braucht aber nunmal irgendwas zu futtern um den Prog. Process aufrechtzuhalten. Ein Daemon soll eig. ein endloss laufender Hintergrund Process sein, der das OS und CPU soweit wie möglich nicht belasten soll.

     

    Die Callbacks alleine reichen nicht, da sie irgendwann und asynchron auftreten, da wäre der main Thread schon lange durch und dein Prog. beendet.

     

    while True kannst du auch ersetzen z.b: durch while still_alive (boolean var) die z.B. bei Exceptions oder in einem deiner Callback gesetzt werden könnte um das Progr. controlliert zu beenden.

  7. Hört sich gut an, insbesondere Wisch-Gesten.

     

    Wenn alle Bricklets auf Copo umgestellt sind, wäre dann eine Direktverbindung mittels USB Adapter in der Pipeline, oder gar als Hat/Shield auf einem PI?

    USB würde mir aber erstmal reichen :)

     

    Danke und Gruß,

    Nic

  8. Ich vermute dieses Topic ist die Fortsetzung von

    https://www.tinkerunity.org/forum/index.php/topic,4017.msg23910.html#msg23910 ;)

     

    Es wäre schön wenn du schon dort auf die Antwort eingegangen wärest, dann wird es ev. nicht nur für dich konkreter und klar was/ob am Ende dabei produktives rauskommt.

     

    Ich vermute deine Frage oder Anliegen ist einfach zu allgemein formuliert, als dass man dazu eine passende Antwort in der Doku oder im Forum bekommt. Wie schon Doc angedeutet hat, es ist abhängig vom Betriebssystem, Infrastruktur, Programmiersprache, Anbindung der Teilnehmer, Benutzerverwaltung usw...

     

    Ein Szenario wäre z.B. den MQTT-Proxy und Mosquitto (https://www.tinkerforge.com/de/doc/Software/Brick_MQTT_Proxy.html) auf dem RED zu installieren, an einen Brick Bricklets (Spannungsmessung etc.) anzuschliessen und mit einem Android Tablet und einer MQTT APK (Stichwort MQTT Dashboard im Google Play Store) die Daten empfangen. Ethernet-Ext muss am Router verbunden sein, Teilnehmer verbinden sich z.B. über WLAN des Routers.

     

    Aber egal ob nun MQTT, Websockets, Rest-Service... das erfordert sich in die Materie einzuarbeiten, Recherchieren, Erfahrungen sammeln und hier im Forum teilen. Aber dann bitte etwas konkreter als nur "hey draußen scheint die Sonne, was soll ich damit anfangen?!" :)

  9. Basierend auf dem Python Example Callback habe ich für Schulungszwecke einen einfachen Batterietester erstellt. In einer Halterung wird eine beliebige Batterie gesteckt und die aktuelle Spannung per Callback und MQTT Pub dargestellt.

    Ohne Batterie wird 0V, mit Batterie nahezu der gleiche Wert wie mit Multimeter zurückgegeben, nimmt man aber die Batterie raus, fällt der Wert nicht wieder auf 0V zurück, sondern fällt über längere Zeit, fast linear und langsam ab.

     

    Liegt das am speziellen Bricklet (v1.0)?

  10. Das ist kein Typo, dass du da vom TP-Link WDN4200 und TP-Link WDN3200 schreibst? Der 3200 der vorher nicht ging, funktioniert jetzt, aber der 4200 funktioniert weiterhin nicht?

    Nein, kein Typo, der 3200 geht jetzt prima unter der Alpha2, der 4200 geht unter Alpha 1+2 wie beschreiben noch nicht.

     

    Funktioniert der TP-Link WDN4200 denn unter Ubuntu?

    Unter Lubuntu 16.04.3 geht der WDN-4200 problemlos.

     

    Die 5 Sekunden Verzögerung können wir nachstellen und arbeiten daran, dass zu verbessern.

    Die 5sec Wartezeit sind für mich nicht tragisch und sind ganz klar eine Verbesserung zum alten RED Image.

  11. Unter Lubuntu 16.04.3 wird der WDN3200 sofort erkannt.

    Verbindung zum AP ist jetzt wesentlich schneller :), WPA Key wird allerdings nicht gespeichert, ich muss den jedesmal neu eingeben.

    Nach Dialog "Configuration saved" dauert es 4-5 sec bis zur Verbindung, dann sollte da zwischenzeitlich aber statt "Disconnected" besser "Connecting...." im Status zu lesen sein.

     

    TP-Link WDN4200 funktioniert nicht. Stick wird im Interface zwar gezeigt, listed aber nur die stärksten APs in umittelbarer Nähe, kann sich nicht mit gewähltem AP verbinden, Status zeigt keinen Fehler nur Disconnected.

     

    Aber der Asus USB-N53 lässt sich wie der WDN3200 auf 2 bzw 5Ghz problemlos verbinden.

  12. Callbacks sind m.W. noch nicht im Mqtt Proxy von TF integriert, siehe auch hier:

    https://www.tinkerunity.org/forum/index.php/topic,3353.msg20600.html#msg20600

     

    Alternativ könntest du einen Daemon/Proxy in Java oder Node.js selbst schreiben, der das LCD direkt referenziert und z.B. über die Paho Klassen https://eclipse.org/paho/clients/java/ bzw. https://www.npmjs.com/package/mqtt die CB-Events published.

     

    PS: Prima Einführung zu MQTT: https://jaxenter.de/iot-allrounder-27208

×
×
  • Create New...