Nic

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.

Jup, diese Version scheint zu funktionieren.

v2.3.3.log

Das Problem ist noch nicht vom Tisch

v2.3.2 macht bei meinem Win10 1809 (64bit) die gleichen Probleme wie oben beschrieben.

v2.3.1 geht prima. In beiden Fällen habe ich aber keinen Brick angeschlossen.

v231.log

v232.log

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

Bei den PI-RTC war meist ein zusätzlicher Treiber zu installieren wenn ich mich nicht irre  ?! 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.

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?

Wenn mit der aktuellen Android Version die Orientierung des Gerätes verändert wird (Hoch- zu Querformat), erzeugt die App die Main Activity neu und vermutlich auch den Service des Brickd. Es scheint die App/Service hängt sich auf und lässt sich nur mittels eines Task-Managers vernünftig killen.

Hammer! Damit habt ihr den Bricks nochmal einen richtigen Quantenschub gegeben

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

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.

Ev. hilft das ein wenig weiter:

https://www.childs.be/blog/post/how-to-run-a-python-script-as-a-service-in-background-as-a-daemon

Man müsste dann vorher überlegen zu welchem Zeitpunkt das TF Zeugs initialisiert bzw abgeräumt (disconnect etc.) wird.

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

Ihr habt hier https://github.com/Tinkerforge/lcd-128x64-bricklet anscheinend ein kommendes Bricklet gelistet. Wenn ichs richtig deute mit Touch, ich könnte mir gut vorstellen damit einen reaktivierten Router aufzupeppen.

Könnt ihr schon ein wenig zu Größe und Verfügbarkeit sagen?

Gruß,

Nic

Interessant, dieses Board kannte ich noch nicht. Ist dieses mit einem x86 Prozessor? Wenn ja, hast du für genügend Strom gesorgt?

Teste doch einmal nur mit dem Master Brick plus 1-2 Bricklets, also ohne Webcam und WLAN Adapter.

Mach mal lieber den Typo da raus, ansonsten könnte das für Missverständnisse sorgen 

1X Masder v2.0    28€

1X Masder v2.1    20€

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?!"

Mit 1k wird die Spannung schneller abgebaut als mit 10k, aber das passt so, prima und danke.

Also zw. + und - Pol, das produziert aber keinen Kurzschluß?

Ja, danke und korrekt. Nur der Batterie-Halter ist am IN verschraubt. Bevor ich hier was zum "Grillen" bringe, wie wird der Widerstand angeschlossen?

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)?

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.

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.

Die Alpha 2 hätte ich doch fast übersehen nach so langer Abstinenz

Packt doch solche Ankündigungen in den Blog oder ins Topic "Veröffentlichungen".

Den WDN3200 teste ich heute abend und ev. noch ein paar andere Sticks.

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

In der aktuellen ct Heft 16 von Heise wurde ein Test über ein ähnliches Gerät veröffentlicht:

https://www.heise.de/ct/ausgabe/2017-16-Mini-Router-mit-viel-Speicher-3775265.html

Den WDN3200 hatte ich in der Vergangenheit nur auf dem Image 1.7 getestet.