Loetkolben

Interessant mitzulesen.

Aus Hardwaresicht finde ich "jumperbare" Moeglichkeiten klasse.

Ggf. die paar Cent mitbestuecken und dann per Jumper "zuschaltbar" machen.

Der Loetkolben

Hallo Olaf,

fuer erste Test setze die Zeiten mal auf 1 und 10 Sec (also faktor 10) rauf. Aus meiner Sicht ist das ein IP bombing.

Baust du jedesmal die IP Verbindung neu auf?

Der Loetkolben.

Meine gefuehlte Meinung:

Lieber einen Tag laenger mit dem Versand Zeit lassen, als hinter Reklamationen hinterherlaufen die durch andere Verursacht wurden.

Viel Erfolg.

Der Loetkolben

Garnicht. Das macht man einmal selbst. Entweder per API oder beim flashen der Firmware. Die Dinger haben doch meistens dieses 4-bit Interface. Irgendwo sind alle mal vom Hitachi Chip abgeleitet worden.

Ich gebe Dir recht, dass die Bricklets fertig aufgebaut und Anfaengersicher sein sollten, aber vielleicht gibt es auch ein paar "offene" Bricklet fuer (Hardware-)Fortgeschrittene.

Weitere Vorschlag: Ein I2C Bricklet waere auch schoen. Dann muesste man sich nicht um die I2C Kommunikation kuemmern, koennte aber trotzdem viele Chips anschliessen.

Der Loetkolben

Hallo zusammen.

Acuh wenn viele hier das GPS Brick gutfinden moechte ich mich dagegen aussprechen. Zum ersten wird es teuer sein muessen und zum zweiten gibt es jede Menge GPS Empfaenger fuer ein paar Euro. Diese sind typischerweise per USB/Bluetooth/Seriel anzuschliessen und liefern ein passendes Signal.

Ich wuerde ein GPSConnect-Bricklet bevorzugen. Damit kann ich dann kostenguenstig meine vorhandene Hardware anschliessen.

Weiterhin plaediere ich fuer ein ExterneFunktemperaturSensoren-Connect-Bricklet an dass man die gaengigen kaeuflichen Funktermometer anmelden kann.

Man sollte das Brick/Daemon System weiter ausbauen zu einem Connect System an das man viele Sache anschliessen kann. Die Hareware muss aber nicht neu erfunden werden.

Weiterer Vorschlag: LCD Connect Bricklet. Diese einfachen LCD Displays habe ich hier rumliegen. Ein guenstiges (parametrierbares) Bricklet und schon kann man die Dinger anschliessen.

Der Loetkolben

@USer: Dann aber schnell bestellen, bevor eine Wartezeit kommt.

@Tinkerforge: Dann aber schnell die Neuproduktion anschubsen.

Weiterhin wuensche ich VIEL ERFOLG!

Der Loetkolben

Pfade wurden als ASCII String betrachtet. Dies betrifft das Distance IR Bricklet Plugin und Advanced Functions. Wir reparieren das gerade.

Oh ha, darum merke: Programmieren und Umlauten passen NIE zusammen!

Bitte vorsichtig reparieren. 

Der Loetkolben.

Hallo,

wenn es konkret wird schraube ich dir ein Shellscript um den Wert auszulesen.

Zur Zeit leider nur fuer das Temperaturbricket "verfuegbar". (Bald) 

Der Loetkolben.

Allerdings nur, wenn man zuerst mit der UID per Funktion get_stack_id die Stack-ID erfragt. Versucht man, mit bekannter Stack-ID den Callback zu triggern, ohne vorher get_stack_id aufzurufen, kommt kein Callback Paket vom brickd.

Muss das immer vor einen Callback Paket passieren oder reicht es einmal nach anstecken des Bricks an den USB Port?

Der Loetkolben

Vielleicht könnte man die schon bestehenden Volumenrabatte ersetzen/ergänzen durch einen gestaffelten Rabatt auf den Gesamtbestellwert.

Z.B. So: Ab 65.-- Euro Bestellwert gibt es 6,3% Rabatt (= 4,10 Euro). 

Viele Gruesse

Der Loetkolben.

Hallo zusammen.

Kann es sein, dass der Shop z. Zt. nur noch in englisch verfuegbar ist? Auch ein Umschalten mit der Flagge geht nicht. Habe es von 2 Rechnern probiert.

BTW: Ich wollte bestellen und finde auch die Versandfreigrenze nicht. War das nicht 60.-- Euro?

Der 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

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.

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

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

Nein, Wenn du einen Stack per USB anschließt werden die neuen Bricks und Bricklets an diesem Stack per Enumerate bekannt gemacht (mit is_new=true) und wenn du den USB Stecker rausziehst wird für die Bricks und Bricklets in dem Stack wieder Enumerate aufgerufen (mit is_new=false).

D.h., wenn ich an einem betriebsbereiten Stack, wo alle Bricklets "is_new=true" sind, ein weiteres Bricklet anstecke ist diese Bricket auf "is_new=false"? (Was ich aber nicht abfragen kann). Sobald ich ein "Enumarate" aufrufe wird das Bricklet auf "is_new=true" gesetzt und mir dann mit der entsprechenden Stack ID angezeigt?!

Anders gesagt: Wenn ich Enumerate aufrufe wird immer "is_new=true" angezeigt, weil gerade durch diesen "Enumerate" Aufruf das TRUE gesetzt wird, oder gibt es einen Fall wo "is_new=false" zurueckgeliefert wird?

Der Loetkolben.

Ich sehe das so:

Ich gehe davon aus, dass die Extension "nur" 10/100MBit kann, also die Leitungen 1,2,3,6 nutzt. Wenn du einen Gigabitswitch hast der nach Norm PoE macht, dass liefert er Ethernet ueber 1,2,3,6 und Power ueber 4,5,7,8. Den Datenfluss wird er ueber 4,5,7,8 abschalten.

Gern mal hier schauen:

Wikipedia.de Power over Ethernet

Wikipedia.en Power over Ethernet

Bei dem von mir angesprochenem "5 Volt Vorschlag" muss man sehr vorsichtig sein. Da wird keine Spannung ausgehandelt und durch die niedrige Spannung ist der Stromfluss auf den CAT5 Kabel recht hoch. Diese 5 Volt PoE Anschaltung sollte (so schaetze ich) nur ca. ein 1 bis 3 Meter lang sein.

Ein dringender Warnhinweis sollte angebracht werden! 

Der Loetkolben.

Hallo borg,

das bedeutet, dass man fuer die TCP Programmierung die Funktion "Resolve UID to Stack ID" nicht benoetigt, da man bei der TCP Programmierung sowieso kein "add device" macht?

wenn is_new "true" ist wurde das Device hinzugefügt, wenn es "false" ist wurde es entfernt.

Von wo wurde es hinzugefuegt, bzw. entfernt? Ich dachte das binden eines Bicklets ist eine Sache innerhalb der HighLevel APIs?

Klar! Dann erstellt der brickd eine passende Routing Tabelle und setzt die IDs um.

Da es keine Physichen und Logischen Stack IDs gibt gehen ich davon aus, dass ich nicht sehen kann an welchem physischen Stack mein Bricklet haengt. Anders ausgedrueckt: Wenn ich ein Bricklet von einem physischen Stack an den anderen Physischen Stack umstecke andert sich meine Software nicht. Stimmt das?

Der Loetkolben

Genauso ist es mir ergangen. Ich konnte die Benachrichtigung im Briefkasten zu einem Einschreiben nicht zuordnen und war erleichtert, dass es die Tinkerforge Hardware war. 

Gerne wuerde ich auch an meine Packstation schicken lassen. Das sollte bei einem DHL Paket ja auch moeglich sein oder gibt es da von eurer Seite Einschraenkungen?

Wenn ihr Probleme mit den Packstationen habet, koenntet ihr das erste Mal per Einschreiben schicken und dann die Packstationen zulassen.

Danke aber auf jeden Fall.

Der Loetkolben.

Hallo zusammen,

ich weiss nicht wie weit die Arbeiten an dem Brick gediehen sind, aber koenntet ihr die bitte so bauen (Jumper), dass man die auch mit 5 Volt ueber das Ethernetkabel versogen kann. Quasi die freien Pins einfach mechanisch aufschalten. Ich gehe ja nicht von Gigabit aus.

Es gibt sehr einfache Injectoren fuer Niederspannung und bei dem niedrigen Stromverbrauch koennte das durchaus eine Alternative sein. Man braeuchte sich den 2. Teil dann sogar schenken.

Beispiel: WLAN PoE Power over Ethernet Kabel Adapter Injector Set

Der Loetkolben

Warum brauche ich die Funktion "Resolve UID to Stack ID"? Ausser der Abfrage der Firmwareversion sehe ich darin keinen Vorteil gegenueber "Enumeration"? Auch dort bekomme ich die Stack ID um die Devices ansprechen zu koennen.

Wozu ist das Byte "is-new set to true (0x01)"? Wann ist es "new"?

Muss ich etwa ein "Enumerate" zuerst machen, damit alle Devices auf "true" gehen? Wenn ja wozu?

Zusatzfrage: Koennen eigentlich 2 oder mehr Stacks am einem brickd haengen und wenn ja wie wird dann gezaehlt?

Der Loetkolben

Diese Frage habe ich mir auch schon gestellt. Fuer einfache (kommunikations) Test waere es super die nutzen zu koennen.

Was haben die 4 LED jetzt fuer eine Bedeutung?

Was haben die 2 anderen LED (Status/Error) fuer eine Bedeutung, bzw. wann geben sie welche Art der Signalisierung ab?

Der Loetkolben.

Wie waere es mit einem Brick(let) um die Funktermometer von den verschiedenen Herstellern (Conrad, etc.) anzubinden? Da gibt es wohl 2 oder 3 Frequenzen. Damit koennte man auch da messen wo man ein Brick nicht hinbekommt, z.B. im Vogelhaeuschen oder man koennte mit einem Brick den ganzen Keller ueberwachen.

Ich denke das ist nicht so ganz trivial, da die Herstellerspezifikationen nicht ganz offen sind, aber mit guten Willen sollte es gehen. Das meiste Zeug kommt doch von als OEM Krams aus der gleichen Chinaschmiede.

Der Loetkolben

Der Forenaufteilungsthread hat sich ja erledigt jetzt

Huch, bei der Ansicht habe ich mich heute Abend selbst erschrocken.

Gerngeschehen. 

Der Loetkolben.

Hallo Tinkerforge Team.

Im Shop bietet ihr die Stecker und Kontakte einzeln an. Das finde ich sehr loeblich. Ich selbst brauche 2 ca. 3cm lange Kabel bzw.ein Bricklet was ich direkt an den Brick stecken kann. Nun ja, aber wie mache ich es? Welche Crimpzange benoetigt man?

Waere es eine Moeglichkeit, dass ihr im Shop unter den Steckern einen Artikel zu 0,00 Euro einbindet mit der Beschreibung: "Info zu benoetiger Crimpzane". Wenn man den anclickt, bekommt man Infos oder ggf. Links zu Anbietern. Die sollten nun wirklich nicht zu euch in Konkurrenz stehen.

Sicher kann man die Info auch in irgendwelchen FAQ verstecken, aber dort wuerde sie am besten hinpassen. Den Artikel kann man dann auch ruhig in den Warenkorb legen. Die Info kostet nichts.

Der Loetkolben