borg

Wow

Die Änderung ist schon im git: https://github.com/Tinkerforge/temperature-bricklet/commit/297302349d14c347b9f85e7f6013227a3d1f255e Ist nur noch nicht veröffentlicht weil die neuen Binding Versionen noch nicht raus sind (gibt ja neue API dafür). Bei den Bindings fügen wir gerade noch Funktionalität hinzu um schneller WIFI disconnects zu erkennen, da fehlen aber nur noch zwei sprachen. Ich denke das ist aber dann am Dienstag soweit.

Wir haben noch keine Antwort, die Mühlen mahlen da bei sowas leider langsam . Wir sind noch dran, es gibt zumindest die Möglichkeit das wir händisch eine leere Nachricht rausschicken, wenn nach kurzer Zeit einer Anfrage keine Antwort rausgeht. Also immer wenn eine Nachricht reinkommt wird ein 10ms Timer gestartet. Wenn eine Nachricht rausgeht wird dieser Timer gestoppt (mit der rausgehenden Nachricht wird ja auch ein ACK geschickt). Falls der Timer bei 0 ankommt schicken wir eine Dummy-Nachricht raus, um ein das ACK zu erzwingen. Damit wären dann in deinem Fall die 200ms Wartezeit auf 10ms verringert worden, dafür werden aber "unnötige" Daten geschickt (aber halt auch nur wenn sowieso keine Daten rausgehen). Das IC was wir für die Ethernet Extension verwenden ist sehr low-level verglichen mit dem WIFI Modul. Dadurch gibt es diese Probleme gar nicht (wir haben das sozusagen selbst in der Hand). Da können keine Buffer voll laufen, da dem PC die Größe des Buffers mit der TCP window size mitgeteilt wird, wie es gedacht ist. Das hat natürlich auch nachteile, ich musste z.B. für die Ethernet Extension selbst einen DHCP Client implementieren, das war ganz schön aufwendig. Bei dem WIFI Modul ist die API einfach beschissen. Es ist so, dass mit jedem Byte was wir rausschicken wir auch gleichzeitig eins empfangen. Da kann man nichts gegen machen. Wenn jetzt viele Nachrichten intern generiert werden (z.B. die Reached Callbacks vom Servo) und wir so viele Daten von extern bekommen, das in jeder ms neue Daten zum auslesen da sind, dann brauchen wir die Buffer. In dem Fall ist es nämlich so, das wir z.B. 20 ausgehende Bytes generieren, die eingehenden Paket haben aber nur die Größe 10. Nun können wir aber nur ein Paket gleichzeitig behandeln, d.h. wir müssen 10 Byte Buffern damit wir das 20 Byte Paket überhaupt rausschicken können. Wenn der Buffer voll läuft müssen wir anfangen die ausgehenden Pakete wegzuwerfen. Total bekloppt . Aber das hat nichts mit dem delayed ACK zu tun, wodurch du im Moment diese 5hz siehst.

I think we will add a watchdog feature for the next Master Brick Firmware release. We currently have not agreed internally if the watchdog should be on or off by default, we will have to discuss that again tomorrow.

Each Brick runs the code for his Bricklets. A Brick can be in SPI Master Mode (The bottom Master Brick) and in SPI Slave Mode. The SPI Master builds a routing table of UID<->Stack height/RS485 address/Chibi address. On the basis of this routing table the SPI Master can route messages to the correct Brick. This is the part of the firmware that changed in Protocol V2. In V1 the routing table was create once on startup, that worked fine with USB but had problems with RS485/WIFI. Now the routing table is created dynamically, if the Master doesn't know a UID the packet is just broadcasted. This can mean that the system is a little bit slower for the first few seconds, but that is well worth the other advantages.

Das ist leider nicht ganz so einfach. Wenn es nur eine "Kaufzusage" ist, ohne das wirklich Geld fließt, ist die Chance zu hoch das ein Großteil der "Käufer" dann am Ende doch abspringen. Bei der Kaufzusage Geld nehmen und erstmal behalten und das Geld wieder zurück überweisen falls eine gewisse Anzahl nicht erreicht wird ist in Deutschland nicht so einfach legal zu machen. Was vermutlich auch der Grund ist warum es Kickstarter noch nicht für Deutschland gibt. Vorbestellungen mit einem festen Termin für Produkte die bereits in Produktion sind oder einen festen Produktionstermin haben, haben wir ja schon ein paar mal gemacht und machen wir auch grundsätzlich für ausverkaufte Produkte .

Die Ethernet Extension wird absolut stabil sein. Dort wird es keinerlei Verbindungsprobleme geben, versprochen . Wir testen da jetzt schon seit Monaten dran rum um das sicherzustellen. Das hier angesprochene delayed ACK "Problem" gibt es bei der Ethernet Extension auch nicht, dort kann man delayed ACKs nämlich ausstellen .

Kickstarter Projekte erstellen können nur Amis und Briten:

You did add a 4m long antenna (the LCD20x4 Bricklet). It is possible that the long cable increased the inductive load problems. But you could easily try that out by disconnecting the long cable (at the stack, not at the LCD). Do the problems disappear then? Edit: A watchdog could indeed have helped in your scenario.

There is: http://www.tinkerforge.com/en/doc/Software/IPConnection_Java.html#IPConnection::setTimeout__i

Schwer zu sagen, ich kenne mich mit SEGGER JLINK nicht aus. Hast du schonmal am Command Set und Protocol Version rumgespielt?

Dann kann ich ja mal gleich die nächste Frage stellen. Wir haben uns unter anderem einen neuen Controller für den Laser Cutter gekauft, da dieser schneiden und gravieren gleichzeitig kann. Würdet ihr die Wetterstation lieber komplett "blank" haben von außen oder etwas draufgraviert? Innen hatten wir vor die einzelnen Löcher mit einer Beschriftung zu versehen.

1hz should not be enough to overload anything, what do you mean with aggressively polling?

If you reset a stack by hand (power on/off or reset button) or if you call the reset function, it will reassociate. If your stack resets because of EMI problems caused by the long cable, anything might happen (it possibly doesn't restart correctly and the WIFI module is in a broken state). You may need to power it off in that case, so the WIFI module can completely reset itself. How many Bricklet ports do you have for how many Bricklets? From an EMI perspective it would make sense to use a single Master Brick for the LCD20x4 Bricklet, since all Bricklets on a Master use the same I2C bus.

Den Aufbau hab ich hier quasi auch: PC -> Gigabit Cisco Switch -> FritzBox -> Stack. Ich denke der Switch und der Router sind für die Probleme hier nicht relevant. So wie ich das sehe passiert folgendes: Das WIFI Modul auf der WIFI Extension arbeitet mit delayed ACKs (http://en.wikipedia.org/wiki/TCP_delayed_acknowledgment). Ist in dem Screenshot auch zu sehen, dort gibt es ganz viele Nachrichten vom PC (77 Byte) und dann werden die alle mit einem ACK beantwortet. Nun scheint es aber so zu sein, dass der PC nach einer Zeit aufhört zu senden wenn er kein ACK bekommen hat. Das WIFI Modul sendet aber erst das delayed ACK wenn der Buffer voll ist (1500 Byte). Da gibt es ein Timeout von 200ms (d.h. wenn der Buffer nach 200ms nicht voll ist, sendet das WIFI Modul trotzdem das delayed ACK). Da lagst du mit deinem "5hz ruckeln" schon sehr gut . Interessant ist jetzt: Wenn der Stack Nachrichten zum zurücksenden hat (damals die Reached Nachrichten vom Servo), dann wird das ACK auch schon frühzeitig zusammen mit diesen Nachrichten rausgeschickt. Daher gab es das 5hz ruckeln dort nicht. Ich denke damit ist die Problematik ziemlich gut verstanden, es ist eine Mischung aus dem 200ms Timeout und der Anzahl der Nachrichten die das Betriebssystem schickt bevor es erstmal aufgibt wenn kein ACK kommt. Das Verhalten wird hier vermutlich von OS zu OS unterschiedlich sein. Falls hier jemand weiß wie man sowas für gewöhnlich löst oder umgeht: Immer raus damit . Ich bin mir nicht sicher ob wir die 200ms Timeout auf dem WIFI Modul verringern können. Dokumentiert ist da nichts, werde aber am Montag den Hersteller fragen.

Also es ist definitiv so, dass die Daten zum Teil gebündelt bei der WIFI Extension ankommen, hier meine Debug Ausgabe: poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll poll [31, 9, 77, e4, b, 4, 50, 0, 0, fd, 2, poll 31, 9, 77, e4, b, 4, 60, 0, 5, 3, fd, poll 31, 9, 77, e4, b, 4, 70, 0, 1, 2a, 3, poll 31, 9, 77, e4, b, 4, 80, 0, 4, d6, fc, poll 31, 9, 77, e4, b, 4, 90, 0, 0, 2a, 3, poll 31, 9, 77, e4, b, 4, a0, 0, 5, d6, fc, poll 31, 9, 77, e4, b, 4, b0, 0, 1, 57, 3, poll 31, 9, 77, e4, b, 4, c0, 0, 4, a9, fc, poll 31, 9, 77, e4, b, 4, d0, 0, 0, 57, 3, poll 31, 9, 77, e4, b, 4, e0, 0, 5, a9, fc, poll 31, 9, 77, e4, b, 4, f0, 0, 1, 84, 3, poll 31, 9, 77, e4, b, 4, 10, 0, 4, 7c, fc, poll 31, 9, 77, e4, b, 4, 20, 0, 0, 84, 3, poll 31, 9, 77, e4, b, 4, 30, 0, 5, 7c, fc, ] poll Die "polls" sind im 1ms takt und wenn Daten da sind, werden sie mit ausgegeben. "[" und "]" geben ein einzelnes TCP/IP Paket an. Da ist also eine ganz Zeit nichts und dann auf einmal kommt 14x setPosition. Im Anhang das ganze nochmal in Wireshark. Dort sieht man die ganzen setPosition (die 77 Byte großen Pakete). Die gehen also eine ganz Zeit lang einzeln durch und dann auf einmal kommt ein Paket der Größe 209 wo die besagte Vielzahl an setPositions drin ist (siehst du auch unten im Payload, dort ist mehrfach 31 09 77.. drin). D.h. die Pakete werden wirklich so vom Betriebssytem losgeschickt. Jetzt muss ich dir allerdings recht geben: Wenn ich die Wi-Fi Strecke extern aufbaue von PC nach PC und dann über USB kommuniziere hab ich diesen Effekt nicht. Die Frage ist also: Was macht die WIFI Extension, das dazu führt, dass das PC Betriebssystem mehrer Nachrichten in ein Paket zusammen schnürt?

Also ich kompiliere in Eclipse auch einfach über das Makefile. Ich hab mal ein paar Screenshots von der Konfiguration angehängt. Ansonsten könnte auch dieser Thread interessant sein: http://www.tinkerunity.org/forum/index.php?topic=1171.0

Ich denke du rufst da einfach so viele Setter auf, dass das Betriebssystem die in ein großes Paket bündelt. Dadurch kommen die Daten dann immer so schubweise an. Du musst also eigentlich sicherstellen, dass das setzen einer Position schon ausgeführt wurde wenn du die neue rausschickst. Das geht z.B. in dem du ReponseExpected aktivierst für setPosition: ((BrickServo)device).setResponseExpected(BrickServo.FUNCTION_SET_POSITION, true); In Zeile 91 in DeviceItem.java. Da gibt es vermutlich eine bessere Stelle für . Dann siehst du auch, dass die Queue vollläuft und du eigentlich zuviele Nachrichten schickst. Ich glaube ich würde versuchen die setPosition Aufrufe auf ein 10ms Intervall zu minimieren. Ich versuche nochmal herauszufinden ab wo genau die Messages schubweise durchgehen, aber ich bezweifle das es etwas ist was wir beeinflussen können .

Das muss es nicht, sieht aber hübscher aus so . Ah ja, da haben wir auch lange dran rumprobiert. Die Raspberry Pi Ausbaustufe ist das Problem. Das ist auf den Fotos jetzt nicht zu sehen, aber du kannst neben dem Master ein DC Jack Adapter anbringen, unter dem Master eine Step-Down Power Supply. dann den Master per USB mit dem Raspberry PI verbinden, die Wetterstation von außen über den DC Jack mit Strom versorgen und das Rapsberry Pi über den grünen Stecker der Step-Down mit Strom versorgen. Der RPi sitzt dabei unter dem LCD20x4. Für alles das sind Bohrungen usw vorgesehen. Das ist eine der schönsten Ausbaustufen, da die Wetterstation dort autonom ist man sie von außen einfach mit einem Notebook Netzteil oder so versorgen kann, was man vermutlich rumliegen hat. Allerdings ist in dieser Ausbaustufe die komplette rechte Seite mit Leiterplatten belegt. Die einzige freie stelle ist da, wo das Aufhängeloch ist. Dafür mussten die Abstandshalter dann außerhalb gesetzt werden .

Soooo, ich konnte das reproduzieren. Konnte den schuldigen auch ausfindig machen: Das Servo Brick. Oder spezifischer: Die VelocityReached und PositionReached Callbacks des Servo Bricks. Du hattest in dem Testprogramm die Velocity aufs Maximum gesetzt und dann mehrere Servos in sehr kurzen Abständen mit kleinen Positionsveränderungen gesteuert. Dadurch war bei jedem setzen eines Stellwerts immer sofort die neue Position und die volle Velocity erreicht. D.h. es gab für jedes Servo quasi immer zwei Nachrichten die zu senden waren. Dadurch haben sich Stück für Stück Nachrichten im Ringbuffer aufgestaut, bis er voll war. Danach haben sie sich dann im Buffer der WIFI Extension aufgestaut, bis er voll war. Und dann passiert etwas böses: Das WIFI Modul nimmt die TCP/IP Pakete an, schreibt soviel in den Buffer wie er kann und schmeißt den Rest weg. An der Stelle hab ich dann verloren, sobald ich diese Daten abarbeite lese ich Schrott und dann tritt das Verhalten auf was du beschrieben hast. Lösung für dein spezifisches Problem: VelocityReached und PositionReached Callbacks an/abschaltbar machen. Ich hab mal eine Servo Brick Firmware angehägt bei der die Callbacks anschaltbar sind, Default ist aus. Damit kann ich mit deinem Testprogramm keine Probleme mehr erzeugen. Wenn das bei dir funktioniert würde ich das auch noch für die *Reached Callbacks von DC und Stepper Brick implementieren. Das stand übrigens sowieso schon auf der TODO Liste . Edit: Veraltete Firmware entfernt.

Oh, auf dem Bild fehlt in der Tat entweder die Batterie oder ein erklärender Text. du musst die Batterie an VIN und GND anschließen. Der positive Pol der Batterie (+) geht an VIN und der negative Pol (-) geht an GND.

Das ist ja ulkig, warum sollte er denn "localhost" nicht resolven können? Hast du schonmal probiert "127.0.0.1" anstatt "localhost" zu nehmen?

In der Grundausbaustufe wird der Temperatursensor vom Barometer genommen. Wir haben aber Platz in der Wetterstation für 3 Master Bricks (oder 2 Master + 1 WIFI oder 2 Master + 1 Ethernet, etc). D.h. da gibt es sehr viele mögliche Ausbaustufen, von denen wir auch einige mit entsprechenden Schritt-für-Schritt Anleitungen darstellen werden. PMMA lässt sich ungefähr so behandeln wie Holz, dadurch ist es sehr einfach neue Löcher o.ä. hinzuzufügen. Zum Beispiel um schöne große Knöpfe auf die Linke Seite der Wetterstation anzubringen, zum durchschalten der Modi (macht mehr Spass als die kleinen Knöpfe am LCD20x4 ). Und so weiter, es wird da sehr viele mögliche Ausbaustufen geben! @Lötkolben: Master um 90° drehen damit das USB Kabel unten rausgeht sollte gehen. So wie er im Foto angebracht ist kann man eine WIFI Extension drauf setzen und die Antenne geht exakt rechts raus und nach oben weg, das sieht dann schick aus .

Ich würde folgenden Hardwareaufbau machen: Aufbau Steuerung: 1x Laptop + Master + 2x Joystick Bricklet über USB Aufbau Regelung: 1x Raspberry PI + USB WLAN Stick + Step-Down Power Supply + Master + Servo Brick + 2x Analog In Und folgenden Aufbau für die Software: Programm Steuerung: Läuft auf Laptop. Es nimmt die Befehle der Joysticks entgegen und wandelt sie in High Level Anweisungen um (z.B.: Fahre mit 10km/h nach rechts). Diese Anweisung wird über einen Socket über WLAN an Programm Regelung welches auf Aufbau Regelung läuft geschickt. Programm Regelung: Läuft auf dem Raspberry Pi. Hier übersetzt du die High Level Anweisungen die vom Programm Steuerung kommen. Des weiteren kannst du dich hier jetzt austoben bzgl. der Regelung und Notausmaßnahmen. Wenn du Ein Arduino verwenden willst würde der Aufbau prinzipiell gleich aussehen, du müsstest dann irgendwie das Arduino mit dem RPI verbinden und auf am Laptop ein weiteres Arduino mit dem Laptop.

Du musst ws2_32.lib noch zu den Abhängigkeiten hinzufügen, dritter Absatz hier: http://www.tinkerforge.com/de/doc/Software/API_Bindings_C.html#visual-studio