[geloest] [TCP] Master Brick "Resolve UID" behindert Bricklet "Resolve UID".

[Loetkolben]

Loesung unten

 

 

 

Hallo zusammen,

 

Nach der Enumeration habe ich versucht einen "Resolve UID to Stack ID" fuer alle gefundenen Devices zu machen (Um z.B Firmwareversion auszulesen). Das Problem ist, wenn man zuerst die Abfrage beim MasterBrick macht, kommt bei der Abfrage der Bricklets nichts mehr zurueck.

 

Stellt man das MasterBrick bei den Abfragen ans Ende der Abfragen, dann funktioniert es. (Aber nur einmalig). Denn wenn man nun die Abfrage in der gleichen Reihenfolge sofort wieder wiederholt (Bricklet und dann MasterBrick) macht es auch Probleme, da ja sozusagen vor den Bricklets das MasterBrick kam.

 

Was keine Probleme macht:

Endlosschleife NUR das Masterbrick abfragen.

Endlosschleise alle Bricklets abfragen.

 

Sobald also die Bricklets NACH der Abfrage des MasterBricks abgefragt werden kommt (erstmals) nichts zurueck. Das Problem ist hier reproduzierbar.

Das bedeutet erstmal, dass man vielleicht 1 Minute warten muss, aber auch dann ist beim naechsten Durchgang nicht garantiert, dass sich ein oder alle Bricklets zurueckmelden. Zum Teil habe ich dann doppelte Antworten, als haette sich beim Durchlauf vorher eine Antwort "versteckt".

 

Meine Frage: Ist das Problem bekannt und hat jemand schnon eine Loesung dafuer?

 

Auf Wunsch kann ich genaue Files/Scripte posten.

 

Der Loetkolben

[borg]

Poste mal genaueres. Wann du wo oder wie die Stack IDs holst sollte vollkommen egal sein. Der Brick Viewer z.B. hält ja auch nicht irgendeine Reihenfolge ein.

[Loetkolben]

Hallo borg,

anbei meine Info. Die "while" Schleife ist nur als Demontration. Das Verarbeiten mit "nc" mache ich wirklich so. 

 

Debian 6.0 Squeeze.  Der Brickviewer laeuft dort problemlos.

nc ist netcat

Das 12Byte Paket in Hex: [00 FF 0C 00  20 39 30 31  34 30 33 31]

Das  6Byte Paket in Hex: [00 FF 06 00  62 57] (bzw. andere UID)

 

Folgendes kann man von der Shell ausprobieren:

 

#Das geht in die Hose, wenn der Master vorne ist.
while true ; do cat data.12byteMaster.bin | nc -w1 deaemon.ip 4223 ; echo "" ; cat data.6byteTemp.bin | nc -w1 daemon.ip ; echo "" ; cat data.6byteLight.bin | nc -w1 daemon.ip 4223 ; echo "" ; done
---Output--------------------
?8 9014031Master Brick 1.0


?8 9014031Master Brick 1.0


?8 9014031Master Brick 1.0


?8 9014031Master Brick 1.0
---------------------------

 

#Nur 2 Bricklets. Geht hier auch mit 3 Bricklets genauso.
while true ; do cat data.6byteTemp.bin | nc -w1 daemon.ip ; echo "" ; cat data.6byteLight.bin | nc -w1 daemon.ip 4223 ; echo "" ; done
---Output--------------------
?8bWTemperature Bricklet 1.0
?8<UAmbient Light Bricklet 1.0
?8bWTemperature Bricklet 1.0
?8<UAmbient Light Bricklet 1.0
?8bWTemperature Bricklet 1.0
?8<UAmbient Light Bricklet 1.0
?8bWTemperature Bricklet 1.0
---------------------------

 

#"Rueckwaerts". Erst Bricklets, dann Masterbrick.
while true ; do cat data.6byteLight.bin | nc -w1 deaemon.ip 4223 ; echo "" ; cat data.6byteTemp.bin | nc -w1 daemon.ip ; echo "" ; cat data.12byteMaster.bin | nc -w1 daemon.ip 4223 ; echo "" ; done
---Output--------------------
?8<UAmbient Light Bricklet 1.0
?8bWTemperature Bricklet 1.0
?8 9014031Master Brick 1.0


?8 9014031Master Brick 1.0


?8 9014031Master Brick 1.0


?8 9014031Master Brick 1.0
---------------------------

 

Wie du siehst, scheint wohl hier die Abfrage des Masterbricks selbst irgendwas zu verzoegern oder ein Timeout auszuloesen. Fuer Hilfe waere ich dankbar.

 

Brauchst du noch die HW/FW Versionen?

 

Der Loetkolben

[photron]

Das 12Byte Paket in Hex: [00 FF 0C 00  20 39 30 31  34 30 33 31]

Das  6Byte Paket in Hex: [00 FF 06 00  62 57] (bzw. andere UID)

 

Ohne das jetzt zu testen oder mir über netcat Gedanken zu machen sehe ich hier schon ein Problem.

 

Ein IPConnection.get_stack_id Request Packet hat immer 12 Byte, da die UID fest 8 Byte gross ist. Das heisst

 

[00 FF 06 00  62 57]

 

muss

 

[00 FF 0C 00  62 57 00 00  00 00 00 00]

 

sein.

[Loetkolben]

Hallo borg,

 

das koennte/scheint es gewesen zu sein. 

 

Laut Doku:

"The payload contains the UID" # Da steht nichts von auffuellen oder fester Groesse.

und

"The UID is shown as integer here to emphasis that the TCP/IP protocol represents UIDs as uint64 values."

 

und die ermittelte UID meines Bricklets war halt kleiner als die eines MasterBricks. Das man dann das Feld mit "00" auffuellen muss hat sich mir leider nicht erschlossen.

Warum bin ich nicht auf die Idee gekommen? Genau deshalb, weil beim umrechnen der MASTERBrick UID VORNE ein hex "20" als Fueller automatisch hinzugefuegt worden ist, siehe oben. Dementsprechend bin ich davon ausgegangen, dass nicht nach hinten mit 00 aufgefuellt werden muss!

 

Was hat das denn mit der hex "20" auf sich.

 

Ansonsten wieder einmal: Herzlichen Dank!

 

Der Loetkolben.

[photron]

Dass das so halb funktioniert wenn du nur Bricklets mit dem zu kurzen Request anfragst hat mit einem Implementierungsdetail der Firmware zu tun und ist im Prinzip zufällig.

 

Es hätte nur für den Master funktionieren sollen und für die Bricklets nie, wegen des zu kurzen Requests. Auch dass das mit den Bricklets nicht mehr geht sobald du einmal den Master angefragt hast beruht auf dem selben Zufall.

 

Laut Doku:

"The payload contains the UID" # Da steht nichts von auffuellen oder fester Groesse.

und

"The UID is shown as integer here to emphasis that the TCP/IP protocol represents UIDs as uint64 values."

 

uint64 -> immer 8 Byte

 

Ich werds etwas deutlich ins Beispiel schreiben im Sinne von

 

"UID 3904673860505581361 as uint64 (0x31 0x37 0x30 0x33 0x30 0x30 0x30 0x36)."

 

Und noch ein Beispiel für ein Bricklet machen.

 

Allgemein gilt: Im TCP/IP Protokoll hat alles feste Größen.

 

und die ermittelte UID meines Bricklets war halt kleiner als die eines MasterBricks. Das man dann das Feld mit "00" auffuellen muss hat sich mir leider nicht erschlossen.

Warum bin ich nicht auf die Idee gekommen? Genau deshalb, weil beim umrechnen der MASTERBrick UID VORNE ein hex "20" als Fueller automatisch hinzugefuegt worden ist, siehe oben. Dementsprechend bin ich davon ausgegangen, dass nicht nach hinten mit 00 aufgefuellt werden muss!

 

Was hat das denn mit der hex "20" auf sich.

 

Nichts besonderes sollte es mit hex "20" auf sich haben. Auch ist das kein Füller denke ich. Für die Bricks kommt die UID aus dem Mikrocontroller selbst und wir benutzen die einfach, Typischerweise sind dass immer Zahlen bei denen alle 8 Byte der uint64 ungleich 0 sind. Für die Bricklets zählen wir selber eine eindeutige Nummer hoch die dann im EEPROM gespeichert wird. Die erste Bricklet UID war dabei so gewählt das sie in Base58 3-stellig ist und es auch noch eine Weile bleiben wird.

[Loetkolben]

Die Aufloesung hier zum Schluss.

Bei der TCP Funktion "IPConnection.get_stack_id" muss das Feld Payload/UID immer 8 Bytes lang sein, auch wenn die (umgerechnete) UID kleiner ist. Der Rest ist mit "00" aufzufuellen. Angenommen die UID ist "6257"

 

Falsch:  [00 FF 06 00  62 57]

Richtig: [00 FF 0C 00  62 57 00 00 00 00 00 00]

 

Warum dieser Seiteneffekt eingetreten ist, die Abfrage im Prinzip auch mit einem kleinen Paket funktioniert hat und warum jede Abfrage einzeln funktioniert, aber nicht in engem zeitlichen Zusammenhang mit einer MasterBrickabfrage, wird wohl ein Geheimnis bleiben.

 

Danke nochmals an borg und die Admins. Vielleicht kann man ja einen Hinweis, wie "Feste Feldgroesse und mit "00" aufzufuellen" an entsprechenden Stellen plazieren. 

 

Der Loetkolben

[photron]

Ich habe jetzt die Beispiele in der TCP/IP Dokumentation noch etwas mehr mit den Typen der Bestandteile eines Packets versehen und ein weiters Beispiel für die kurze UID eines Bricklets hinzugefügt.