Loetkolben

Hallo zusammen. Nachdem ich folgenden Beitraege in den Mixer gesteckt habe ist obige Ueberschrift rausgekommen. Montage der Bricks und Reed Kontakte Neues Starterkit: Wetterstation (Hier geht es nur um die Bilder) Koennte man denn nicht 1 oder 2 verschiedene universelle Bodenplatten anbieten? Was fuer einen Gehaueseboden geht sollte doch wohl auch einzeln gehen. - Das war doch eines der Themen die sich hier schon lange durchs Forum ziehen. x mal y cm mit 2a+4b+6c+8Pi Loechern. @Alle: Ist da noch Bedarf? @Tinkerforge: Waeren da noch Moeglichkeiten? Muss ja nicht huebsch sein? Der Loetkolben

Hallo borg, super Sache! Danke. Da hat man lange drauf gewartet. Meine Frage: Die eigentlichen Bauteile selbst sind von den Abmessungen die gleichen wie bisher? Meine Anmerkung: Die Zusammenstellung der neuen Kits habe ich erst verstanden als ich sie mir im Shop angesehen habe. Die Beschreibung im Blog ist fuer mich zu verwirrend. Alle neuen Kits auf einen Blick: (Ich hoffe es gibt keine Umbrueche) Befestigungskit 9mm Befestigungskit 12mm Befestigungsschrauben(lang) Viele Gruesse Der Loetkolben

Hallo batti, es geht um dieses Bild: http://www.tinkerforge.com/de/doc/_images/weather_station_content_35016.jpg Aus Sicht eines Neulings/Interessenten: Was ist das auf dem Bild? Sicherlich koennte man jetzt den Text darueber lesen, aber ein Bild sagt mehr als tausend Worte. Also das *.jpg mit Text anreichchern oder auseinanderschneiden und mit Text in einer HTML Tabelle unterbringen: "Temperaturbricklet, Gehauseoberseite, 50mm Distanzbolzen, 15cm Kabel, usw. Sinngemaess wie dies: Zur 2. Aufgabe - (Mitte Artikel) -> Direktlink Viele Gruesse Der Loetkolben

Hinweis: Beitragstitel geaendert. Hallo photron. So, nun haben wir telefonisch auch die Bricks wieder geflasht und remote den brickd getauscht. Funktioniert wie es soll. Super! :huepf: Kleine Anekdote am Rande: Beim ersten Abruf mit dem den neuen Programmen (Protokollversion 2) kam jedem Menge Datenmuell. Ich habe keine Ahnung welcher Buffer da leer gemacht werden musste. Fuer Neugiriege ist die Datei im Anhang. Danke photron, danke Tinkerforge fuer die Unterstuetzung. Bitte weiterhin an den Compilterswitch "386" denken. Aus meiner Sicht ist das Thema damit geschlossen. Edit: Mit in den normalen Prozess uebernommen: Brick Daemon 2.0.5 Der Loetkolben i386_temp_airp_first_v2_output.txt

Hallo borg. Nun ist es also soweit. Top Produktphoto! Glueckwunsch. Dieser Satz ist 100% richtig, aber man versteht ihn nur wenn man Tinkerforge verstanden hat. Fuer Anfaenger solltet ihr 3 Saetze schreiben, eine Tabelle machen oder gleich eine Zeichnung anfertigen. Like this: ---------------------- In der Bildertabelle bitte noch den Namen vor das Bild setzen. Sonst sehen alle Platinen gleich aus. - Ups. Ist ja nur ein "big" Image. Vielleicht eine Tabelle mit Bildern und Mouseover texten machen. Ich faende es gut wenn am Anfang die einzelnen Teile klar und deutlich zu sehen sind. Das waren meine Anmerkungen bei der ersten fluechtigen Durchsicht. BTW: Immer noch der Hinweis: Klares Gehaeuse und NUR die Frontplatte in Klar oder Schwarz anbieten. Achso: Lasst doch mal die Seite von einem Bekannten durchlesen der daran Interesse hat und sich bisher nicht viel mit den Tinkerforgeprodukten beschaeftigt hat. Ich glaube der hat viele spontane Fragen. Vielleicht ist das auch alles zu technisch. Vielleicht sollte man auch den Verkauf (Angebot) und die Bastelei (Zusammenbau) auf 2 aufeinanderfolgenden Seiten darstellen. Das koennte sonst potentille Kaeufer "erschlagen". Wie reagiert ihr auf die Frage: "Gibt es das auch als Fertiggeraet?" Viele Erfolg damit! Der Loetkolben

Hallo photron. An der beschriebenen Stelle liegt das egg Verzeichnis, aber kein easy-install.pth Datei. /usr/local/lib/python2.6/dist-packages# ls -l insgesamt 4 drwxr-sr-x 4 root staff 4096 8. Mai 2012 tinkerforge.egg Mir ist aufgefallen, dass ich python 2.5 und 2.6 installiert haben. Ein Programm (obmenu) benoetigt v 2.5. Hat das damit was zu tun? Die Datei easy-install.pth scheint es auch nicht woanders zu geben. Habe danach gesucht: /# find . -name easy-install.pth -print # Sowohl "-" als auch "_" probiert Ich habe jetzt einfach den Ordner "/usr/local/lib/python2.6/dist-packages/tinkerforge.egg" in die Tonne getan und hoffe dass es das war. Vielleicht gibt es die Datei "easy-install.pth" deshalb nicht mehr, weil es keine anderen Eintraege dort gibt? Normalerweise haette ich in so einem Fall eine 0 Byte lange Datei erwartet. Seis drum. Der Loetkolben

Hallo AutonX, das hing hiermit zusammen: [brickd] Version v2 laesst sich nicht starten. Mit v1 Version kein Problem Hier wollte/musste ich dann beim Fallback die letzte alte 1.x.x Version benutzen und habe dann die 1.0.9 anstelle der "oben" versteckten 1.0.11 Version genommen. Das hatte fuer mich keine weiteren Auswirkungen, aber es hat mich veranlasst diesen Beitrag zu schreiben. Je mehr Versionen in Zukunft kommen und so besser sollte man sie verwalten/sortieren koennen. Sozusagen eine Investition in die Zukunft. Der Loetkolben

Hallo photron, so oder so aehnlich haette ich mir das auch gedacht. Hier der Output der immer kommt: # easy_install -m tinkerforge install_dir /usr/local/lib/python2.6/dist-packages/ Searching for tinkerforge Best match: tinkerforge 1.0 Processing tinkerforge.egg Using /usr/local/lib/python2.6/dist-packages/tinkerforge.egg Because this distribution was installed --multi-version, before you can import modules from this package in an application, you will need to 'import pkg_resources' and then use a 'require()' call similar to one of these examples, in order to select the desired version: pkg_resources.require("tinkerforge") # latest installed version pkg_resources.require("tinkerforge==1.0") # this exact version pkg_resources.require("tinkerforge>=1.0") # this version or higher Processing dependencies for tinkerforge Finished processing dependencies for tinkerforge # # find . -name *.egg -print ./usr/local/lib/python2.6/dist-packages/tinkerforge.egg Das "Removing" fehlt mir irgendwie. Auch wenn es sich hier um ein Linux / Python Problem handelt wuerde ich mich freuen wenn du, oder gerne jemand anders, weiterhelfen kann. Danke Der Loetkolben

Hallo AuronX, gibbet doch. Here complete list: brickd-1.0.0_all.deb 08-Dec-2011 10:19 58098 brickd-1.0.10_all.deb 16-Oct-2012 07:53 75450 brickd-1.0.11_all.deb 26-Oct-2012 14:54 76410 brickd-1.0.1_all.deb 02-Mar-2012 14:08 58208 brickd-1.0.2_all.deb 28-Mar-2012 19:03 60688 brickd-1.0.5_all.deb 17-Apr-2012 14:36 68576 brickd-1.0.6_all.deb 24-Apr-2012 16:39 68674 brickd-1.0.7_all.deb 05-Jun-2012 16:49 69990 brickd-1.0.8_all.deb 25-Jun-2012 13:40 70800 brickd-1.0.9_all.deb 30-Jul-2012 10:53 74184 brickd-2.0.0_amd64.deb 22-Jan-2013 16:51 31552 brickd-2.0.0_armhf.deb 22-Jan-2013 17:16 31892 brickd-2.0.0_i386.deb 22-Jan-2013 16:53 30450 brickd-2.0.1_amd64.deb 25-Jan-2013 18:04 32802 brickd-2.0.1_armhf.deb 25-Jan-2013 18:21 33038 brickd-2.0.1_i386.deb 25-Jan-2013 18:21 31674 brickd-2.0.2_amd64.deb 07-Feb-2013 14:56 33646 brickd-2.0.2_armhf.deb 07-Feb-2013 15:16 33776 brickd-2.0.2_i386.deb 07-Feb-2013 15:03 32340 brickd-2.0.3_amd64.deb 08-Feb-2013 11:45 33638 brickd-2.0.3_armhf.deb 08-Feb-2013 11:57 33776 brickd-2.0.3_i386.deb 08-Feb-2013 11:47 32338 brickd-2.0.4_amd64.deb 03-Apr-2013 09:03 33898 brickd-2.0.4_armhf.deb 03-Apr-2013 09:09 33958 brickd-2.0.4_i386.deb 03-Apr-2013 09:05 32546 brickd_linux_latest_amd64.deb 03-Apr-2013 09:43 33898 brickd_linux_latest_armhf.deb 03-Apr-2013 09:43 33958 brickd_linux_latest_i386.deb 03-Apr-2013 09:43 32546 Aendert aber nichts an der Tatsache, dass man bei der Suche nach letzen 1.x.x Version suchen muss. Auch auf meinem Filesystem erzeugt das Unordnung. Ich denke das ist ein Prio 5 Problemchen, aber in einer freien Minute kann man ja mal darueber nachdenken. Der Loetkolben

Hallo zusammen, ich habe mir letztens 2 mal selbst die Karten gelegt, als ich Files runtergeladen habe. :selbstaerger: Da die 3. Stelle auch 2 Ziffern enthalten kann sind die Files (im Filesystem) nicht sortiert. Die 1.0.9 ist also nicht die aktuelleste Version. Die versteckt sich irgendwo "mitten drin". Noch sieht es uebersichtlich aus, aber wenn man > 30 Files vorhanden sind, vestecken sich die 2.0.2, 2.0.3 und 2.0.4 irgendwo mittendrin. Fuer das Suchen einer speziellen Version ist das hinderlich. Hier ein Beispiel der 1.x.x. Reihe: brickd-1.0.0_all.deb 08-Dec-2011 10:19 58098 brickd-1.0.10_all.deb 16-Oct-2012 07:53 75450 brickd-1.0.11_all.deb 26-Oct-2012 14:54 76410 brickd-1.0.1_all.deb 02-Mar-2012 14:08 58208 brickd-1.0.2_all.deb 28-Mar-2012 19:03 60688 brickd-1.0.5_all.deb 17-Apr-2012 14:36 68576 brickd-1.0.6_all.deb 24-Apr-2012 16:39 68674 brickd-1.0.7_all.deb 05-Jun-2012 16:49 69990 brickd-1.0.8_all.deb 25-Jun-2012 13:40 70800 brickd-1.0.9_all.deb 30-Jul-2012 10:53 74184 Koenntet ihr die Versionsnummer als xx.xx.xx ausgeben oder von mir aus auch als x.x.xx oder x.xx.xx. Like this: brickd-1.0.00_all.deb 08-Dec-2011 10:19 58098 brickd-1.0.01_all.deb 02-Mar-2012 14:08 58208 brickd-1.0.02_all.deb 28-Mar-2012 19:03 60688 brickd-1.0.05_all.deb 17-Apr-2012 14:36 68576 brickd-1.0.06_all.deb 24-Apr-2012 16:39 68674 brickd-1.0.07_all.deb 05-Jun-2012 16:49 69990 brickd-1.0.08_all.deb 25-Jun-2012 13:40 70800 brickd-1.0.09_all.deb 30-Jul-2012 10:53 74184 brickd-1.0.10_all.deb 16-Oct-2012 07:53 75450 brickd-1.0.11_all.deb 26-Oct-2012 14:54 76410 Danke. Der Loetkolben

Dann muss der Brickd mal mit der BrickFW reden. Fuer mich waere das die beste Loesung, aber ich verstehe, dass man auch auf die anderen Belange Ruecksicht nehmen muss. Das ist schon ok. Die BrickFW kann es ja rauschicken, aber der brickd muss es doch nicht weiterschicken. Ja das verstehe ich, aber warum kann der brickd es nicht fuer sich behalten und muss es in Welt hinauspusten? Was ist der Sinn dass der brickd mir die Infos schickt? Ich brauch sie nicht. Der Loetkolben

Hallo photron, das sieht gut aus. # dpkg -i brickd-2.0.4_really_i386.deb Vormals abgewähltes Paket brickd wird gewählt. (Lese Datenbank ... 19339 Dateien und Verzeichnisse sind derzeit installiert.) Entpacken von brickd (aus brickd-2.0.4_really_i386.deb) ... brickd (2.0.4) wird eingerichtet ... update-rc.d: using dependency based boot sequencing Starting Brick Daemon: Starting /usr/bin/brickd... # /etc/init.d/brickd status Status of Brick Daemon: running (pid 10631) Diesen brickd habe ich auf dem Rechner installiert der KEINEN Stack dran hat. Wie du siehst startet er und BLEIBT gestartet. Der Livetest an dem anderen PC kommt warscheinlich heute abend, da ich dazu Telefonsupport (Brick flashen) benoetige. Achso: hier waere ein Remotebrickflashing super zu gebrauchen. Ich melde mich wieder, bin aber sehr zuversichtlich. VIELEN DANK! Der Loetkolben

Ich baue doch die Verbindung beim USB Stack jedes mal wieder ab, aber bekomme das Paket nicht immer wieder. Wer ist hier "der PC". Auch wenn nicht unterschieden wird, kommt was unterschiedliches raus. Der Loetkolben Edit: Macht es einstellbar und alle sind gluecklich.

Hallo borg. Und wieso bekomme ich dann mit dem identischen Programm unterschiedlich Antworten? :denknach: So identisch koennen sie dann nicht sein. Du beschreibst Sonderfaelle. Da mag das identisch sein. Wer verbindet sich schon zu einem USB Brickd und steckt dann den Stack an? Der Normalfall sollte doch so sein, dass man eine Verbindung aufbaut, Daten abholt und wieder abbaut. In diesem Fall gibt es eben die Unterschiede. Beim USB Stack wird ein "Enumerate Callback" gesendet wenn der Stack per USB angeschlossen wird. Beim WLAN Stack wird ein "Enumerate Callback" gesendet wenn der Brickd angesprochen wird. Was ist daran identisch? Ich verstehe es nicht. Der Loetkolben

Hallo AuronX. Hier spricht die Wetterstationsabteilung, die Stacks quer durchs Land verteilt hat. Dies ist kein Sonderfall, sondern der Normalfall. Alle 10 Minuten Verbindung aufbauen, Daten holen und abbauen. Fertig. Weiss der Geier was auf 1000 km und bei 20 Carriern alles sonst dazwischen kommen kann. Von mir aus kann man so ein Verhalten in den WiFi Setting aktivieren. Auf jeden Fall sollten sich die Stacks (USB oder WLAN) NICHT unterscheiden!!! Ob das mit dem "nc" Befehl geht weiss ich nicht. Der handelt den Auf- und Abbau automatisch. Das ist richtig praktisch. Eine alternative waere anstelle eines WLAN Stacks ein Raspberry PI mit WLAN zu nehmen. Kostet genauso viel, hat mehr Moeglichkeiten, aber sieht nicht so huebsch aus. Ich wuerde mich freuen wenn Tinkerforge sich nochmals hinhocken und ueber eine Loesung nachdenken wuerden die allen Gerecht wuerde. Der Loetkolben

Hmm, zum einen habe ich aber keine "Enumerate Callbacks" bestellt und zum anderen kommen die ungeordnet. Das erwartete Paket ist dann mitten im "Enumerate Callback" Salat Wo kann ich diese "Enumerate Callbacks" abstellen? Wie soll ich damit erkennen, dass der Stack neu gestartet hat. Irgendwie kommen diese "Enumerate Callbacks" immer! Ohhhhh, solche Aussagen wie "nicht darauf verlassen" finde ich in der IT Welt hoechst bedenklich. Dann schaltet doch diese Antworten aus. Mir reicht es, dass ich entweder eine Antwort bekomme oder nicht. Dann weiss ich wenigstens dass der Stack nicht erreichbar ist. Ob er rebootet hat oder neu gestartet ist kann ich doch auch per "Get" abfragen. Ich bin der Meinung, dass hier eine Loesung gefunden werden muss, damit der Stack nicht irgendwann irgenwas zurueckschickt womit keiner rechnet! Das ist dann mehr eine Daten-Lotterie als eine Programmierung. Der Loetkolben

Guten Morgen zusammen, danke fuer die Unterstuetzung. :-) Installiert habe ich mit "dpkg -i brickd-2.0.4_i386" und die Installation ist sauber durchgelaufen. Ja, deshalb habe ich ja auch das i386 Paket genommen. Kann es sein, dass es eine "586" compatible CPU ist die mit einem "486" Kernel laeuft. S.u. Ich habe den Rechner einfach ueber das original Bootimage aufgesetzt und die Installation lief problemlos durch. ~# dmesg|more [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.32-5-486 (Debian 2.6.32-46) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Sun Sep 23 09:17:35 UTC 2012 [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] NSC Geode by NSC [ 0.000000] Cyrix CyrixInstead [ 0.000000] Centaur CentaurHauls [ 0.000000] Transmeta GenuineTMx86 [ 0.000000] Transmeta TransmetaCPU [ 0.000000] UMC UMC UMC UMC [ 0.000000] CPU: vendor_id 'SiS SiS SiS ' unknown, using generic init. # cat /proc/cpuinfo processor : 0 vendor_id : SiS SiS SiS cpu family : 5 model : 0 model name : 05/00 stepping : 5 cpu MHz : 199.473 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu tsc cx8 mmx bogomips : 398.94 clflush size : 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: # uname -a Linux PC 2.6.32-5-486 #1 Sun Sep 23 09:17:35 UTC 2012 i586 GNU/Linux # gcc -Q -v -bash: gcc: Kommando nicht gefunden. Aus diesem Grund haben wohl auch sehr viele Debian Programme speziell fuer die 386/486 Hardware compilierte Binaries. Koennt Ihr das bitte fixen. Danke. Der Loetkolben

Hier die Installation vom brickd auf einem 2. Baugleichen PC leider ohne Brickstack. # dpkg -i brickd-2.0.4_i386.deb Vormals abgewähltes Paket brickd wird gewählt. (Lese Datenbank ... 18765 Dateien und Verzeichnisse sind derzeit installiert.) Entpacken von brickd (aus brickd-2.0.4_i386.deb) ... brickd (2.0.4) wird eingerichtet ... update-rc.d: using dependency based boot sequencing Starting Brick Daemon: Starting /usr/bin/brickd... # /etc/init.d/brickd status Status of Brick Daemon: stopped # brickd --debug 2013-04-17 00:51:28.473466 <I> <main_linux.c:385> Brick Daemon 2.0.4 started 2013-04-17 00:51:28.478345 <D> <event.c:55> Initializing event subsystem Ungültiger Maschinenbefehl Problem bleibt das gleiche aber man muss nicht 500km Telefonsupport machen. Nachtrag: Am Debian "itself" liegt es nicht, da ich den brickd 2.0.4 auch auf einem anderen PC am laufen habe. Es muss mit der Hardwarearchitektur zusammenhaengen?! Der Loetkolben

Edit: Originaltitel war: "[brickd] Version v2 laesst sich nicht starten. Mit v1 Version kein Problem." Hallo zusammen, hatte ich das nicht schon mehrmals gesagt, dass ich die Protokoll Version fuer keine gute Idee halte? Hier ein weiteres Problem: Auf einem kleinen PC mit Debian 6.0.7 in aktuellem Zustand laesst der Brickd nicht starten. /var/log/brickd sagt: 2013-04-16 23:08:19.432998 <I> <main_linux.c:383> Brick Daemon 2.0.4 started (daemonized) 2013-04-16 23:09:11.591176 <I> <main_linux.c:383> Brick Daemon 2.0.4 started (daemonized) 2013-04-16 23:09:21.784311 <I> <main_linux.c:383> Brick Daemon 2.0.4 started (daemonized) Es sieht so aus als waere er gestartet. Ein "/etc/init.d/brickd status" sagt aber "brickd stopped" ... Merkwuerdig Ein manueller Start bringt das: # brickd --debug 2013-04-16 23:28:21.928855 <I> <main_linux.c:385> Brick Daemon 2.0.4 started 2013-04-16 23:28:21.931551 <D> <event.c:55> Initializing event subsystem Ungültiger Maschinenbefehl # brickd --debug # Mal eine "alte" Version 2.0.1 probiert 2013-04-16 23:36:47.939376 <I> <main_linux.c:315> Brick Daemon 2.0.1 started 2013-04-16 23:36:47.942613 <D> <event.c:55> Initializing event subsystem Ungültiger Maschinenbefehl Die Protokollversion v1 (1.0.9) lief einwandfrei und wurde mit "dpkg --purge brickd" deinstalliert. Welche Angaben muss ich noch nachliefern, dass jemand hier helfen kann. Mein persoenlicher Tip: Compilerswitch. Danke fuer die Unterstuetzung. Der Loetkolben

Ich hab auch meinen Stolz! Nachdem ich nun alles hinbekommen habe moechte ich es auch einsetzen. Ich versuche es mal so: Hallo Onkel TF. :wink: Koenntest du dem WLAN Stack bitte sagen, dass er sich wie ein USB Stack verhalten soll und generell spontane Callbacks nicht mehr zulassen. Danke. :winkewinke: Der Loetkolben

Hallo AuronX, danke fuer die Antwort. Das sieht ja richtig "Zivil" aus. Kann mir aber einer sagen was ich damit machen soll? Ich habe keine Enumeration bestellt. Wenn jetzt das erwartete Anwortpaket immer an der gleichen Stelle stehen wuerde koennte man es mit Shellbefehlen einfach ausschneiden. Bei diesem Bytesalat, wo auch die Paketreihenfolge zufaelligt ist, muss vielleicht doch Dr. Tinkerforge ran. Vielleicht hat er ja was von Tinkerpharm. Der Loetkolben

Hallo AuronX, das "zweite" Paket muss aus mehreren Paket bestehen, denn man kann eindeutig die 10 Bytes erkennen die erwartet wurden! "00 80 00 00 0a 01 18 00 47 0a" "47 0a" sind die Temperaturwerte und somit "schwankend" Wenn man sich mal optisch den ASCII Dump ansieht so kommt oefters die Masterbrick ID "62fV73" vor. Ich denke das es 8 Pakete sind?! Ausserdem sind alle IDs der Bricklets vorhanden. Kann es sein, dass es sich um einen Enumerationsrespond handelt? [size=8pt]cat paket.WLAN.temp0 | hexdump -C 00000000 32 21 75 c4 22 fd 08 00 [color=red]36 32 66 56 37 33 [/color]00 00 |2!u."...[color=red]62fV73[/color]..| 00000010 30 00 00 00 00 00 00 00 30 01 00 00 02 00 06 0d |0.......0.......| 00000020 00 01 00 80 00 00 22 fd 08 00 [color=green]61 4a 59[/color] 00 00 00 |......"...[color=green]aJY[/color]...| 00000030 00 00 [color=red]36 32 66 56 37 33[/color] 00 00 61 01 01 00 02 00 |..[color=red]62fV73[/color]..a.....| 00000040 01 d8 00 01 ce 7c 00 00 22 fd 08 00 [color=green]61 75 53[/color] 00 |.....|.."...[color=green]auS[/color].| 00000050 00 00 00 00 [color=red]36 32 66 56 37 33[/color] 00 00 62 01 01 00 |....[color=red]62fV73[/color]..b...| 00000060 02 00 00 15 00 01 [color=blue]00 80 00 00 0a 01 18 00 47 0a[/color] |..............G.| 00000070 8e 83 00 00 22 fd 08 00 [color=green]62 31 45[/color] 00 00 00 00 00 |...."...[color=green]b1E[/color].....| 00000080 [color=red]36 32 66 56 37 33[/color] 00 00 63 01 01 00 02 00 00 1b |[color=red]62fV73[/color]..c.......| 00000090 00 01 |..| 00000092[/size] Blau = Das erwartete Paket. Anbei die Stack IDs per Screenshot aus dem Brickviewer. Der Loetkolben

Hallo AuronX, danke fuer die schnelle Antwort! Ich baue mir gerade wieder selbst die Shellscripte. Nachdem die Huerde von base58 genommen wurde dachte ich eigentlich ich waere "durch". Ich koennte eigentlich damit leben wenn sich USB und WLAN nicht unterscheiden wuerden. Mal sehen was die Erfinder von Protokoll v2 sagen. :grpf: Edit: @AuronX: Habe ich gemacht. Wie beschrieben kommt das WLAN Paket sogar in 2 Versionen an. Mal so, mal so. Die 10 Bytes "00 80 00 00 0a 01 18 00 47 0a" verstecken dann an unterschiedlichen Stellen innerhalb der 146 Bytes. (Leider nicht im Forumcode markierbar) Der Loetkolben tempv2.tar

Im Moment kommt dieser "Kaese" raus. Im obigen Beispiel waren die letzten 10 Byte die Nutzdaten, hier sind sie mitten im Paket. :'( cat paket.WLAN.temp0 | hexdump -C 00000000 32 21 75 c4 22 fd 08 00 36 32 66 56 37 33 00 00 |2!u."...62fV73..| 00000010 30 00 00 00 00 00 00 00 30 01 00 00 02 00 06 0d |0.......0.......| 00000020 00 01 00 80 00 00 22 fd 08 00 61 4a 59 00 00 00 |......"...aJY...| 00000030 00 00 36 32 66 56 37 33 00 00 61 01 01 00 02 00 |..62fV73..a.....| 00000040 01 d8 00 01 ce 7c 00 00 22 fd 08 00 61 75 53 00 |.....|.."...auS.| 00000050 00 00 00 00 36 32 66 56 37 33 00 00 62 01 01 00 |....62fV73..b...| 00000060 02 00 00 15 00 01 00 80 00 00 0a 01 18 00 47 0a |..............G.| <-- 10 Byte Daten hier 00000070 8e 83 00 00 22 fd 08 00 62 31 45 00 00 00 00 00 |...."...b1E.....| 00000080 36 32 66 56 37 33 00 00 63 01 01 00 02 00 00 1b |62fV73..c.......| 00000090 00 01 |..| 00000092 Der Loetkolben

Hallo zusammen, ich habe hier zwei Temperaturbricklets. Einmal ueber USB Master einmal ueber WLAN Master angesprochen: Antwort vom USB Master2.0 FW 2.0.6 mit 10 Byte. OK. Send: "bQL" \x74\x8e\x00\x00\x08\x01\x18\x00 Receive: hexdump -C paket.USB.temp0 00000000 74 8e 00 00 0a 01 18 00 40 09 |t.......@.| 0000000a Antwort vom WLAN Master1.0 FW 2.0.6 mit 146 Byte. :'( Send: "aJY" \x00\x80\x00\x00\x08\x01\x18\x00 Receive: hexdump -C paket.WLAN.temp0 00000000 32 21 75 c4 22 fd 08 00 36 32 66 56 37 33 00 00 |2!u."...62fV73..| 00000010 30 00 00 00 00 00 00 00 30 01 00 00 02 00 06 0d |0.......0.......| 00000020 00 01 00 80 00 00 22 fd 08 00 61 4a 59 00 00 00 |......"...aJY...| 00000030 00 00 36 32 66 56 37 33 00 00 61 01 01 00 02 00 |..62fV73..a.....| 00000040 01 d8 00 01 ce 7c 00 00 22 fd 08 00 61 75 53 00 |.....|.."...auS.| 00000050 00 00 00 00 36 32 66 56 37 33 00 00 62 01 01 00 |....62fV73..b...| 00000060 02 00 00 15 00 01 8e 83 00 00 22 fd 08 00 62 31 |.........."...b1| 00000070 45 00 00 00 00 00 36 32 66 56 37 33 00 00 63 01 |E.....62fV73..c.| 00000080 01 00 02 00 00 1b 00 01 00 80 00 00 0a 01 18 00 |................| <-- 10 Byte Daten hier 00000090 53 0a |S.| Kann mir das einer erklaeren? Im Brickviewer 2.0.4 ist alles ok. Wo habe ich den Fehler gemacht, bzw. warum reagieren die beiden Stacktypen unterschiedlich? Der Loetkolben