Loetkolben

Hallo batti, das ist doch die ganze Zeit mein reden! Warum rede ich denn davon die Loecher auf ein _sinnvolles_ Mass zu reduzieren? Beim (Hart)-Karton besteht vielleicht die Moeglichkeit 5 oder mehr Lagen _aufeinmail_ (uebereinaner) zu lasern. Man angenommen: Wenn nun 1/10 der Loecher ausreichen und man 5 Lagen auf einmal machen kann, kommt man schon 50mal schneller voran. Thema Pappe/Hartkarton/Fotokarton: Stellt euch nur mal folgendes vor: Ihr nehmt normles Druckerpapier (80g/m2) und lasert die Loecher darein. Dann schraubt ihr den Stabel und die Bricklets darin "fest". Das wabert ohne Ende. Dann stellt das Gebilde auf den Tisch. Es steht! Die Bauteile verschieben sich nicht gegeneinander. Haette man den gleichen Aufbau _ohne_ Lochplatte gemacht waere alles ueber den Tisch verstreut, die Brickelts wuerden mal so, mal so liegen. Soll heissen: Das Material koennte/sollte/braeuchte nur so stabil sein, dass es nicht reisst, aber es darf sich ruhig ein wenig biegen. Wichtig ist, dass es dem Aufbau einen Halt gibt und sich die Bauteile nicht verschieben koennen. Hier nun den besten Kompromiss zwischen Stabilitaet, Materialdicke, Verarbeitungsgeschwindigkeit und Preis zu finden ist nicht ganz leicht. Der gezeigte Prototyp ist Top und ihr koennt auch in Richtung Kunststoff gerne weiterdenken. Der Loetkolben

Hallo zusammen, Da ich hier wieder mit einem IO4 experimentiere wollte ich das Thema nochmals ins Bewusstsein ruecken. Wie kann man einen Tastendruck lokal speichern bis er per "get" abgeholt werden kann. Muesste da nur die Bricklet FW angepasst werden oder muss da auch die Master FW angepasst werden? Der Loetkolben

Top! Funktioniert! Glueckwunsch an Tinkerforge und AuronX! Danke. Hier nur ein kleines Feedback und die Beschreibung wie es aussieht: Vor dem Reset to Bootloader # lsusb Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 005: ID 16d0:063d GrauTec Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ls -la /dev [...] crw-rw---- 1 root dialout 4, 64 11. Apr 21:24 ttyS0 crw-rw---- 1 root dialout 4, 65 11. Apr 21:24 ttyS1 crw-rw---- 1 root dialout 4, 66 11. Apr 21:24 ttyS2 crw-rw---- 1 root dialout 4, 67 11. Apr 21:24 ttyS3 [...] Nach dem Reset to Bootloader # lsusb Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 006: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ls -la /dev [...] crw-rw---- 1 root dialout 166, 0 20. Apr 02:17 ttyACM0 crw-rw---- 1 root dialout 4, 64 11. Apr 21:24 ttyS0 crw-rw---- 1 root dialout 4, 65 11. Apr 21:24 ttyS1 crw-rw---- 1 root dialout 4, 66 11. Apr 21:24 ttyS2 crw-rw---- 1 root dialout 4, 67 11. Apr 21:24 ttyS3 [...] Ein python flash-brick-cli.py -p /dev/ttyACM0 -f brick_master_firmware_2_0_6.bin erzeugte dann diese Ausgabe: Writing firmware: 100 % Verifying written firmware: 100 % Zip Zap fertig. Geht sehr schnell. Dauert ca. 5 Sekunden. Wie erkenne ich das richtige /dev Device? In meinem Fall war es einfach. Bleiben noch folgende kleine Aufgaben/Wuensche: Das flashen ohne Python moeglich machen? Vielleicht? Den Masterbrick ueber einen freien Port (z.B. via LED) in den Bootloadermodus zu bringen. (Ich loete und Tinkerforge passt die Firmware an) Den Masterbrick 2.1 direkt mit Remotebootloaderfeature ausstatten. Gerne auch per Loetjumper. Den Brickviewer in Zusammenhang mit dem Brickd die Sache erledigen lassen. Zumindest auf PC/USB Systemen Alles in allen schon mal eine Erleichterung, aber zum Knoepchendruecken muss man noch in die Ecke kriechen. Der Loetkolben

Hallo AuronX, da gibt es Nachteile die mir einfallen: [*]Zum einen finde ich eine schlichte Optik schoener. Viereckig, kantig, gut. - Siehe Prototyp [*]Je nachdem wie die Zapfen sind kann man daran haengenbleiben oder sich verletzen. Siehe Punkt 3 und 4. [*]Um die Platten fest miteinander zu verbinden muessen die Nasen eng sitzen und sind ggf. scharfkantig (Wie hier und hier). Dabei besteht das Risko, dass man sich nich unfallfrei auseinander bekommt. Wenn man sie nur locker zusammenstecken kann, kann man die Platten nicht transportieren weil wenn man eine hochhebt bleibt die andere stehen (Wie ein Puzzle). [*]Wenn man 2 Platten zusammengesteckt hat und man hebt eine Platte an, was passiert dann mit der anderen? Macht es knack und beide sind "essig" oder ist die Verbindung so stabil, dass das haelt? Da muesste man probieren und haengt sicher von der Materialstaerke ab. Das kostet Zeit und Geld. So schoen die Idee ist, um so schwieriger ist sie _aus meiner Sicht_ umzusetzen! Ich lasse da gerne die Experten sprechen und unterstuetze die Idee der Nasen und Anreihbarkeit, aber praktikabel sollte die Loesung sein. Edit: @Tinkerforge: Koennte man nicht auch Hartkarton nehmen um die Boards noch guenstiger zu machen? Die waeren zwar nicht so stabil aber fuer einen Aufbau sollte es reichen. Ich selbst habe es gemacht und bin halbwegs zufrieden. Vielleicht koennte man 5 Kartonlagen aufeinmal (uebereinander) fertigen? Ein weiterer Vorteil waere, dass man zu Hause auch noch ein zusaetzliches Loch reinbekommt. Der Loetkolben.

Hallo borg. Eine tolle Idee. Man koennte die Platte auch ohne "Nasensystem" anreihbar machen indem man den Rand der Platten so breit waehlt, dass wieder 0,5cm rumkommen und man die dann mit einem Steg oder sogar mit einem Brick(let) (Ein Teil auf Platte 1, ein Teil auf Platte 2) verbinden kann. In anbetracht der technischen Moeglichkeiten (Kleinserie) waere mein Vorschlag, dass man erstmal eine halbwegs gutdurchdachte Platte mit sinnvoller Anordnung der Loecher macht. Ich denke es kommen in der Praxis noch viele Ideen hinzu an die man bei den ganzen "Trockenuebungen" nicht denkt. Diese kann man dann sukzessive mit einfliessen lassen kann. Um nochmal auf die Anreihbarkeit zurueckzukommen. Da muesste man sich schon vorher ein System an Groessen ueberlegen die spaeter zueinanderpassen. Ob das jetzt hilfreich ist weiss ich nicht so ganz. Auch mir sprudeln noch viele Ideen aus dem Kopf aber so kommt man von Hoelzchen auf Stoeckchen. Der Loetkolben

Eigentlich zwei Bricklets"plaetze", aber du kannst ja stapeln. Somit sind 2*2 "Mini"bricklets (2,5*1,5cm) moeglich. Oder noch hoeher. Auch kannst unten ein 2,5*2,5cm Bricklet nehmen und darueber ein 2,5*1,5cm Bricklet. Das haelt dann "nur" mit 2 Schrauben. Wenn unten noch groessere Bricklets sind, kann man darueber ggf. das Bricklet mit nur einer Schraube befestigen. Wichtig ist aber, dass nichts mehr rumfliegt. Das IO4 und IO16 Bricklet oben zu haben (mit langen Distanzbolzen) find ich prima, da dort die meisten Kabel abgehen. Vielleicht kommt es aber auch auf ein paar Loecher mehr nicht an und man koennte den Brickletteil (Rechte Haelfte) vollkommen durchsieben und beim Masterteil (Linke Haelfte) nur 4 Loecher machen. Auch waere es denkbar unter dem Master noch ein Bricklet anzubringen. Um aber eine sinnvolle* Borschablone anzufertigen muss da jemand drueberschauen der den Ueberblick ueber die Brickletgroessen hat. Auch muesste man "mal eben" probieren ob der Abstand zwischen den 3 Plaetzen gross genug ist umd die Kabel und Stecker zu "verlegen". Man wird es nicht allen recht machen koennen, aber wenn 60% der Miniprojekte oder Haurucktest damit realisiert werden koennen waere das sicher ein Erfolg. 100% Zustimmung Der Loetkolben * Preis/Leitung/Groesse

Hallo borg, auch wenn die Loecher mit Lichgeschwindigkeit gemacht werden, dauert es eine Weile. Ich habe mal einen simplen Plan erstellt, der nochnichtmal ein Entwurf ist, aber die Idee veranschaulicht. Als Loecher sind die Roten Felder zu verstehen. Aus meiner Sicht wuerde man mit 1/10 der Loecher auskommen und somit recht schnell die Boards herstellen koennen. Jeder der gute Ideen hat sollte, bzw muss hier weiterhelfen. Wuerde mich freuen wenn da noch was moeglich waere. Der Loetkolben tinkerforge_prototype_easy.xls

Auch die Gehaeuse sind einzeln im Shop zu bekommen! Der Loetkolben

Meine Ergaenzung in Rot, denn das ist der springende Punkt. Grummel. Da schauen wir mal. Auch ich habe auch das Gefuehl, dass sie die Bindungs nur fuer mich stricken (werden). Das muss wirklich nicht sein, da ich nur wenige Funktionen benutze! So viel Hardware kann ich garnicht kaufen, dass sich die Programmierstunden dafuer bezahlt machen. Das ist mir schon klar und aergert mich selbst. Es wuerde mir es reichen wenn das Protokoll sinnvoll funktionieren wuerde. Wer will das schon, ich esse gegrilltes auch lieber ohne diese Marinadentunke. Wer weiss was sich darin alles verbirgt. Vielleicht kommt da auch das ein oder andere Paket unverlangt wieder hoch vorbei. Auf zur Revolution. Hiermit starte ich die Petition: Tinkerforge Protkoll V2.1 Der Loetkolben

Hallo AuronX, hallo borg. Darf ich zusammenfassen: Wenn jemand eine Antwort anfragt (R=1) , diese aber nicht abholt/abnimmt wird sie an alle geschickt, die gerade eine Verbindung offen haben, auch wenn sie sie nicht haben wollen (BEISPIEL 1). Sollte keine Verbindung offen sein wird sie verworfen (BEISPIEL 2). Richtig? Der Loetkolben

Hallo borg. Warum erst durch die Gegend schicken wenn sie dann doch weggeschmissen werden. :gruebel: Das mit der Routingtablle ansich verstehe ich nicht ganz. Sollte man da nicht die Routingtabelle in Ordnung bringen wenn sie fehlerhaft ist und nur dorthin was schicken wo es hingehoert? Geht mir weg mit dem WLAN. Da habe ich bisher noch gar keine Loesung. Der WLAN Stack muellt mich mit Broadcast zu ohne dass ich vorher testen kann ob es ein WLAN Stack ist. Das eigentliche erwartete Datenpaket steekt dann irgendwo mitten drin. Diese ganzen unverlangten Pakete die irgendwann und irgendwo auftauchen machen mich vollkommen fertig. Siehe auch den Beitrag direkt darueber von mir. Mal wird ein Broadcast erzeugt wenn kein Empfaenger (mehr) da ist, mal nicht. Das ist doch keine Lotterie hier sondern Computerei. Manchmal moechte ich die Brocken hinwerfen. BTW: Ich mag Tinkerforge, aber habe ich schon gesagt, dass ich das Protokoll V2 nicht gut finde? Der Loetkolben

Hallo AuronX, irgendwie es ist noch mysterioeser. Um Deine Frage zu beantworten ob die Verbindung noch aktuell war habe ich alle nicht relevanten PC Anfragen rausgenommen. Hier redet nur noch der PC1 der die Temperatur abfragt und PC2 der das IO4 setzt mit R=1, aber ohne auf Antwort zu warten. Dies ist wie erwartet. Siehe obige Beitrage. BEISPIEL 1 18:13:01.459377 <I> <network.c:94> Added new client (socket: 10, peer: [color=blue]PC1[/color]) # Get-Temepratur open 18:13:03.475265 <I> <network.c:94> Added new client (socket: 16, peer: [color=red]PC2[/color]) # Set-IO4 open, [color=red]don´t wait for answer, R=1[/color] 18:13:03.476944 <I> <client.c:65> Client (socket: 16, peer: [color=red]PC2[/color]) disconnected by peer # Set-IO4 close 18:13:03.477411 <W> <network.c:280> Broadcasting response because no client has a matching pending request 18:13:09.566455 <I> <client.c:65> Client (socket: 10, peer: [color=blue]PC1[/color]) disconnected by peer # [color=red]Get-Temperatur close, with IO4 Data[/color] -rw-r--r-- 1 root root [color=purple]18[/color] 19. Apr 18:13 IN.20130419_181309.bin Hier wird es "lustig". Ich lasse zuerst das IO4 setzen, warte dann 15 Sekunden und hole dann die Temperatur ab. Komischerweise wird kein Broadcast erzeugt? Auch hier ist die Anfrage fehlerhaft. BEISPIEL 2 2013-04-19 18:16:03.683922 <I> <network.c:94> Added new client (socket: 10, peer: [color=red]PC2[/color]) # Set-IO4 open, [color=red]don´t wait for answer, R=1[/color] 2013-04-19 18:16:03.685432 <I> <client.c:65> Client (socket: 10, peer: [color=red]PC2[/color]) disconnected by peer # Set-IO4 close - [color=orange]WARUM WIRD KEIN BROADCAST ERZEUGT??[/color] #15 Sekunden Pause 2013-04-19 18:16:16.919782 <I> <network.c:94> Added new client (socket: 10, peer: [color=blue]PC1[/color]) # Get-Temepratur open 2013-04-19 18:16:22.952056 <I> <client.c:65> Client (socket: 10, peer: [color=blue]PC1[/color]) disconnected by peer # Get-Temperatur close, [color=green]ONLY Temperatur Data[/color] -rw-r--r-- 1 root root [color=purple]10[/color] 19. Apr 18:16 IN.20130419_181622.bin Tritt das Phaenomen nur auf wenn zufaellig andere Anfragen "offen" sind? Der Loetkolben

Nachdem ich noch ein wenig gesucht habe hier eine kleine Zusammenfassung: Antwortpakete die nicht zugestellt werden koennen erzeugen einen Broadcast und werden irgendeinem anderen Anfrager mit aufs Auge gedrueckt. nc -q1 nc wartet nicht auf Antwort und "response expected flag = 0" : Alles OK. nc -q1 nc wartet nicht auf Antwort und "response expected flag = 1" : Erzeugt einen Error und ein Broadcastpaket an alle, da der Stack nicht weiss wohin er die Antwort schicken soll. nc -w1 nc wartet auf Antwort und "response expected flag = 0" : Alles OK, da sowieso keine Antwort kommt. nc -w1 nc wartet auf Antwort und "response expected flag = 1" : Alles OK, da die Antwort abgeholt wird. Hallo photron, habe gerade vor dem abschicken deinen Beitrag gelesen und freue mich _wirklich_ sehr das das Phaenomen geklaert ist. Danke. Du stellst das auch gut da, aber ist folgende Aussage wirklich clever? Soll man da lachen oder weinen? Ich wuerde sagen: Wenn eine Antwort kommt auf die keiner wartet, dann schmeiss sie weg! Damit kann ein fehlerhaftes Programm alle anderen Programme die auch auf den gleichen Stack zugreifen ausser Tritt bringen. Was sollen denn ueberhaupt andere Programme mit Antworten anfangen die sie nie angefragt haben? - Das verstehe ich nicht. Der Loetkolben

Hallo photron, danke fuer die Unterstuetzung. Ich habe bei allen 4 PC die "IO4.set_configuration" benutzen das "response expected" flag geloescht (auf "0" gesetzt) und dann war Ruhe. Die Temperaturabfrage hat nur 10 Byte empfangen. Soweit ok. Die Info von photron hat mir keine Ruhe gelassen und ich habe NUR an PC2 das "response expected" wieder auf 1 gesetzt. Das Problem ist wieder da. Damit sollte ausgeschlossen sein, dass es sich um die gleiche IP Verbindung handelt. Also: 3 PCs (0,1,3) greifen mit "response expected flag = 0" auf das IO4 zu. PC 1 holt AUCH Temperaturdaten ab. PC 2 greift als einziger mit "response expected flag = 1" auf IO4 zu. Ergebnis: 18 Byte lange Antworten an PC1 der die Temperatur abfragt: # hexdump -C IN.20130419_163609.bin 00000000 [color=green]62 57 00 00 0a 01 18 00 02 09[/color] [color=red]a2 59 00 00 08 03[/color] |bW.........Y....| 00000010 [color=red]18 00[/color] |..| 00000012 [Temper.+Ambi+Hmidity+IO4--Master--USB--PC0]--LAN--WAN--+--WAN--PC1(fragt Temper. ab) R=1, logisch da Temper. Abfrage | +--WAN--PC1(unset io4 Bit0) R=0 PC0(set io4 Bit0,1,2) R=0 + +--WAN--PC2(unset io4 Bit1) R=1 +--WAN--PC3(unset io4 Bit1) R=0 Alle PCs haben unterschiedliche IP und unterschiedliche Netze. Bezueglich Logfile: 17:01:01.200814 <I> <network.c:94> Added new client (socket: 10, peer: [color=green]PC1[/color]) 17:01:01.655124 <I> <network.c:94> Added new client (socket: 16, peer: [color=brown]PC0-lokalhost[/color]) 17:01:01.655828 <I> <client.c:65> Client (socket: 16, peer: [color=brown]PC0-lokalhost[/color]) disconnected by peer 17:01:03.180328 <I> <network.c:94> Added new client (socket: 16, peer: [color=green]PC1[/color]) 17:01:03.183070 <I> <client.c:65> Client (socket: 16, peer: [color=green]PC1[/color]) disconnected by peer 17:01:03.676506 <I> <network.c:94> Added new client (socket: 16, peer: [color=red]PC2[/color]) 17:01:03.677726 <I> <client.c:65> Client (socket: 16, peer: [color=red]PC2[/color]) disconnected by peer 17:01:03.678439 <W> <network.c:280> Broadcasting response because no client has a matching pending request 17:01:04.289453 <I> <network.c:94> Added new client (socket: 16, peer: [color=purple]PC3[/color]) 17:01:04.293536 <I> <client.c:65> Client (socket: 16, peer: [color=purple]PC3[/color]) disconnected by peer 17:01:09.707918 <I> <client.c:65> Client (socket: 10, peer: [color=green]PC1[/color]) disconnected by peer Nochmals zur Erleuterung: [color=brown]PC0[/color] setzt IO4 mit R=0 [color=green]PC1[/color] holt Temperatur UND setzt IO4 mit R=0 [color=red]PC2[/color] setzt IO4 mit R=1 [color=purple]PC2[/color] setzt IO4 mit R=0 Was ich sehen kann ist, dass zumindest die Anzahl der Anfragen passt. Der Warningeintrag scheint ein Hinweis darauf zu sein, aber ich kann es nicht genau interpretieren. So, der Ball ist wieder ueberm Netz. Danke. Der Loetkolben

Ja, die LED am IO4 mache ich so aus: SENDPACKET=$UID"\x0B\x03\x18\x00\x01\x6F\x00 SENDPACKET= \$UID = UID in Hex \x0B = Paketlange 11 Byte \x03 = Funktion " IO4.set_configuration" \x18 = "Sequence number 1 and response expected 1 as uint8 (0x18) and" \x00 = Flags = 0 \x01 = "Selection Mask", welche LED/Port gesteuert werden soll \x6F = 6f="o", also Output \x00 = 00=off x01=on Ja, setze ich. Ich warte nicht unbedingt, zumindest Werte ich die Antwort nicht aus. Das schaue ich mir nochmals an. Ok, das schaue ich mir nochmals an. Danke fuer die Hinweis, ABER hat das wirklich was mit meinem Problem zu tun. :gruebel: Vielleicht kann ich damit mein Problem vermeiden, aber warum werden eventuell nicht abgeholte Paket dann bei irgendeiner anderen, hier Temperatur, Abfrage mit weggeschickt? Frei nach dem Motto: Pakete die keiner abgeholt hat, bekommt dann einfach der naechste der eine Anfrage stellt??? Das kann es doch nicht sein. Wie denn sonst? Mir hat man versprochen: Raider heisst jetzt Twix, sonst aendert sich nix. Der Loetkolben

Richtig, in beiden Faellen "normal" angeschlossen. Er arbeitet und kann erfolgreich abgefragt werden. Den Bootloadermodus, bzw. das Flashen habe ich aus Zeitgruenden noch nicht getestet. Viele Gruesse Der Loetkolben

Hallo zusammen, der eigentliche Betragstitel sollte heissen: "Bitte keine Werbung schicken oder was ist das fuer Paketpost?" Ich habe mich doch dann mehr sachorientiert ausgedrueckt. Ich stelle gerade einen weiteren Brickstack auf Protokoll v2 um. Dabei tritt folgendes Problem auf, dass ich jetzt in Antwortpaketen einer Temperaturabfrage Daten von IO4 Paketen habe! Dies ist das Temperaturabfragepaket. # hexdump -C OUT.NOW.bin 00000000 [color=green]62 57[/color] 00 00 08 01 18 00 |bW......| 00000008 Wird fast immer mit 18, 26, 34 Byte langen Paketen beantwortet! Erwartet werden aber nur 10 Bytes. -rw-r--r-- 1 root root 26 19. Apr 14:04 IN.20130419_140409.bin -rw-r--r-- 1 root root 18 19. Apr 14:05 IN.20130419_140509.bin -rw-r--r-- 1 root root 18 19. Apr 14:06 IN.20130419_140609.bin -rw-r--r-- 1 root root 34 19. Apr 14:07 IN.20130419_140710.bin -rw-r--r-- 1 root root 26 19. Apr 14:08 IN.20130419_140810.bin -rw-r--r-- 1 root root 26 19. Apr 14:09 IN.20130419_140909.bin -rw-r--r-- 1 root root 34 19. Apr 14:10 IN.20130419_141011.bin -rw-r--r-- 1 root root 18 19. Apr 14:11 IN.20130419_141109.bin -rw-r--r-- 1 root root 26 19. Apr 14:12 IN.20130419_141209.bin Hier ein Beispiel: hexdump -C IN.20130419_135509.bin 00000000 [color=green]62 57 00 00 0a 01 18 00 15 09[/color] [color=orange]a2 59 00 00 08 03[/color] |bW.........Y....| 00000010 [color=orange]18 00[/color] [color=pink]a2 59 00 00 08 03 18 00[/color] [color=red]a2 59 00 00 08 03[/color] |...Y.......Y....| * Die ersten 10 Byte sind meistens* die erwartete Antwort. Der Rest kommt von einem IO4 Bricklet. Warum kommt es mehrmals (Orange,Pink.Red)? Warum ist das letzte Paket kaputt? Hat das was mit der Folgenummer zu tun? Die Pakete kommen aber von unterschiedlichen IPs/PCs oder zumindest von einer anderen TCP Session. So sieht die Infrastruktur folgendermassen aus. Dies sind die Bricklet UIDs: 7DG [color=green]62 57[/color] Temperatur 7ud 3c 55 Ambient 7Tf 74 5a Humidity 7PC [color=red]a2 59[/color] IO4 Der Aufbau sieht folgendermassen aus: [Temper.+Ambi+Hmidity+IO4--Master--USB--PC0]--LAN--WAN--+--WAN--PC1(fragt Temper. ab) | +--WAN--PC1(unset io4 Bit0) PC0(set io4 Bit0,1,2) + +--WAN--PC2(unset io4 Bit1) +--WAN--PC3(unset io4 Bit1) Alle 3 PC (1,2,3) arbeiten per Cron jede Minute einen Job ab und greifen auf die Bricklets an PC0 zu. So, warum bekommt ich bei der Temperaturabfrage Fragmente von IO4 Paketen? Wer laesst da was uebrig? Danke fuer eure Unterstuetzung Der Loetkolben PS: *Anscheinend gibt es sogar noch Paketkombinationen wo noch mehr Muell drinsteckt, aber die habe ich noch nicht fangen koennen. PPS: Hatte ich schon erwaehnt dass ich das Protokoll v2 nicht so prickelnd finde.

Hallo photron, danke fuer die Info. Ich konnte es gestern noch nicht ausprobieren. Habe gerade "remote" auf den Rechner geschaut finde das nicht. Lediglich "ttyS0" bis "ttyS3". Ist eines davon das Device und wenn ja welches? Entschuldigung fuer den langen Output. Ich habe ihn schon mit [...] eingekuerzt, aber ich wollte keine wichtige Info zurueckhalten. /dev# ls -la insgesamt 4 drwxr-xr-x 17 root root 3060 11. Apr 21:24 . drwxr-xr-x 23 root root 4096 3. Apr 21:04 .. crw-rw---- 1 root video 10, 175 11. Apr 21:24 agpgart crw------- 1 root root 10, 235 11. Apr 21:24 autofs drwxr-xr-x 2 root root 300 11. Apr 21:24 block drwxr-xr-x 2 root root 60 11. Apr 21:24 bsg crw------- 1 root root 10, 234 11. Apr 21:24 btrfs-control drwxr-xr-x 3 root root 60 11. Apr 21:24 bus drwxr-xr-x 2 root root 2580 11. Apr 21:24 char crw------- 1 root root 5, 1 11. Apr 21:25 console lrwxrwxrwx 1 root root 11 11. Apr 21:24 core -> /proc/kcore drwxr-xr-x 2 root root 60 11. Apr 21:24 cpu crw------- 1 root root 10, 62 11. Apr 21:24 cpu_dma_latency drwxr-xr-x 6 root root 120 11. Apr 21:24 disk drwxr-xr-x 2 root root 80 11. Apr 21:24 dri crw-rw---- 1 root video 29, 0 11. Apr 21:24 fb0 lrwxrwxrwx 1 root root 13 11. Apr 21:24 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 11. Apr 21:24 full crw-rw---- 1 root fuse 10, 229 11. Apr 21:24 fuse crw------- 1 root root 10, 228 11. Apr 21:24 hpet prw------- 1 root root 0 11. Apr 21:24 initctl drwxr-xr-x 2 root root 40 11. Apr 21:24 .initramfs drwxr-xr-x 3 root root 140 11. Apr 21:24 input crw------- 1 root root 1, 11 11. Apr 21:24 kmsg srw-rw-rw- 1 root root 0 11. Apr 21:24 log brw-rw---- 1 root disk 7, 0 11. Apr 21:24 loop0 [...] brw-rw---- 1 root disk 7, 7 11. Apr 21:24 loop7 crw------- 1 root root 10, 237 11. Apr 21:24 loop-control lrwxrwxrwx 1 root root 9 11. Apr 21:24 MAKEDEV -> /bin/true drwxr-xr-x 2 root root 60 11. Apr 21:24 mapper crw------- 1 root root 10, 227 11. Apr 21:24 mcelog crw-r----- 1 root kmem 1, 1 11. Apr 21:24 mem drwxr-xr-x 2 root root 60 11. Apr 21:24 net crw------- 1 root root 10, 61 11. Apr 21:24 network_latency crw------- 1 root root 10, 60 11. Apr 21:24 network_throughput crw-rw-rw- 1 root root 1, 3 11. Apr 21:24 null crw------- 1 root root 1, 12 11. Apr 21:24 oldmem crw-r----- 1 root kmem 1, 4 11. Apr 21:24 port crw------- 1 root root 108, 0 11. Apr 21:24 ppp crw------- 1 root root 10, 1 11. Apr 21:24 psaux crw-rw-rw- 1 root root 5, 2 19. Apr 14:03 ptmx drwxr-xr-x 2 root root 0 11. Apr 21:24 pts crw-rw-rw- 1 root root 1, 8 11. Apr 21:24 random lrwxrwxrwx 1 root root 4 11. Apr 21:24 root -> sda1 lrwxrwxrwx 1 root root 4 11. Apr 21:24 rtc -> rtc0 crw------- 1 root root 254, 0 11. Apr 21:24 rtc0 brw-rw---- 1 root disk 8, 0 11. Apr 21:24 sda brw-rw---- 1 root disk 8, 1 11. Apr 21:24 sda1 brw-rw---- 1 root disk 8, 2 11. Apr 21:24 sda2 brw-rw---- 1 root disk 8, 3 11. Apr 21:24 sda3 brw-rw---- 1 root disk 8, 5 11. Apr 21:24 sda5 drwxrwxrwt 2 root root 40 11. Apr 21:24 shm crw------- 1 root root 10, 231 11. Apr 21:24 snapshot drwxr-xr-x 3 root root 240 11. Apr 21:24 snd lrwxrwxrwx 1 root root 24 11. Apr 21:24 sndstat -> /proc/asound/oss/sndstat lrwxrwxrwx 1 root root 15 11. Apr 21:24 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 11. Apr 21:24 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 11. Apr 21:24 stdout -> /proc/self/fd/1 crw-rw-rw- 1 root root 5, 0 11. Apr 21:24 tty crw------- 1 root root 4, 0 11. Apr 21:24 tty0 crw------- 1 root root 4, 1 11. Apr 21:25 tty1 crw------- 1 root root 4, 10 11. Apr 21:24 tty10 [...] crw------- 1 root root 4, 7 11. Apr 21:24 tty7 crw------- 1 root root 4, 8 11. Apr 21:24 tty8 crw------- 1 root root 4, 9 11. Apr 21:24 tty9 crw-rw---- 1 root dialout 4, 64 11. Apr 21:24 ttyS0 crw-rw---- 1 root dialout 4, 65 11. Apr 21:24 ttyS1 crw-rw---- 1 root dialout 4, 66 11. Apr 21:24 ttyS2 crw-rw---- 1 root dialout 4, 67 11. Apr 21:24 ttyS3 drwxr-xr-x 7 root root 160 11. Apr 21:24 .udev crw------- 1 root root 10, 223 11. Apr 21:24 uinput crw-rw-rw- 1 root root 1, 9 11. Apr 21:24 urandom crw------- 1 root root 7, 0 11. Apr 21:24 vcs crw------- 1 root root 7, 1 11. Apr 21:24 vcs1 [...] crw------- 1 root root 7, 6 11. Apr 21:24 vcs6 crw------- 1 root root 7, 128 11. Apr 21:24 vcsa crw------- 1 root root 7, 129 11. Apr 21:24 vcsa1 [...] crw------- 1 root root 7, 134 11. Apr 21:24 vcsa6 crw------- 1 root root 10, 63 11. Apr 21:24 vga_arbiter prw-r----- 1 root adm 0 19. Apr 14:02 xconsole crw-rw-rw- 1 root root 1, 5 11. Apr 21:24 zero # lsusb Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 16d0:063d GrauTec Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Ein anderer PC an dem auch ein Brick und ein Datenlogger haengt sieht so aus: [...] crw-rw---- 1 root dialout 4, 64 18. Apr 23:09 ttyS0 crw-rw---- 1 root dialout 4, 65 18. Apr 23:09 ttyS1 crw-rw---- 1 root dialout 4, 66 18. Apr 23:09 ttyS2 crw-rw---- 1 root dialout 4, 67 18. Apr 23:09 ttyS3 crw-rw---- 1 root dialout 188, 0 18. Apr 23:09 ttyUSB0 [...] # lsusb Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 004: ID 16d0:063d MCS Bus 003 Device 003: ID 0403:e0ec Future Technology Devices International, Ltd Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Hier gehe ich aber davon aus, dass "ttyUSB0" wohl der Datenlogger ist?! Der Loetkolben

Super. :-) Bitte denke daran, dass Brickviewer, Brickdaemon, Brickfirmware UND DIE EIGENE SOFTWARE zusammenpassen muessen. Wenn du also Programme uebernehmen moechtest musst du auch anpassen da Version 1 und Version 2 nicht kompatibel sind. Viel Spass weiterhin. Der Loetkolben

Hallo hettmann, so ist es. Zum flashen des Masterbrick brauchst du nur einen laufenden Brickviewer. Der brickd muss nicht installier sein. Kurzversion. Brickviewer installieren. Masterbrick Erasetaste halten und anstecken. Brickviewer starten, USB Port waehlen und flaschen. Die Bricklets koennen spaeter problemlos upgedated werden. Doku hier: Brick Firmware Flashing Bei Windows muessen natuerlich die passenden USB Treiber installiert sein. Was Mac macht weiss ich nicht. Wird schon klappen, ansonsten hier fragen. Das hatte mich iritiert, aber anscheinend ist auf dem Ubuntu der brickdaemon und brickviewer noch in Version 1.x.x. installiert. Was "HD Version 1.2" ist kann nicht nicht interpretieren. Der Loetkolben

Hallo hettmann, kann es sein, dass die Bricklets noch mit Firmware 1.x.x unterwegs sind? Auch die muessen auf die 2.x.x Firmware umgestellt werden, ansonsten siehst du sie nicht im normalen Modus. Der Masterbrick hat aber die Firmwareversion 2.0.x? Starte mal den BrickV und druecke dann den Knopf "Updates/Flashing". Sollte die dort auftauchen ist "alles in Ordnung". Nur noch "Auto-Update" druecken und dann sollte es gut sein. Der Loetkolben

Mir kommt gerade noch eine gute Idee. So wie es aussieht sind die zusaetzlichen Beschriftungen noch nicht auf der Platine und batti hat auch Argumente den Taster nicht zu versetzen. Wie waere es, wenn man den Reset- oder Erasetaster in einer anderen Farbe macht. Ich selbst habe diese Art von Taster noch nie in einer anderen Farbe gesehen, aber man weiss ja nie! Reset = Rot oder Erase = Blau Warum komme ich darauf? Ich versuche gerade das "Flashen per Commandline" ans laufen zu bekommen. Sollte es dann mal funktionieren muss noch jemand in der Ferne "den Knopf" druecken. Wie erklaert man das dann? "Erst den linken druecken. - Ja hab ich. - Nein, das andere Links" Da wuerden Farben doch helfen, oder? Der Loetkolben

Hallo AuronX, vielen Dank fuer Deine Muehen! Nachdem ich mir mehrere Python-Fragezeichen aus dem Gesicht gewischt habe und apt-get install python-serial apt-get install python-argparse nachinstalliert habe konnte ich mit folgendem Aufruf # /usr/bin/python flash-brick-cli.py -p /dev/bus/usb/002/002 -f brick_master_firmware_2_0_6.bin (Error) Could not connect to Brick: No Brick in Bootloader found recht weit kommen. Ist die Angabe des /devices in dieser Schreibweise richtig? Ich kann den Livetest erst spaeter machen, da man immer noch nicht remote flaschen kann! - Tinkerforge sollten einen Port/Bit zum Reset/Erase Knopf umbauen, z.B. eine der LEDs. Der Loetkolben

"Tinkerforge: Managed by lightspeed" Wau! Das sieht wirklich toll aus! So luxerioes war es garnicht gedacht, denn jedes Loch kostet Geld (POH). Passen denn auch 2 Loecher fuer den Rasberry Pi? Ich haette dann gerne die schmale halfsize Version 3 mal. Edit: Wenn man kein komplettes 5mm Raster macht, koennte man im unteren Teil auch Loecher fuer die Zollrasterplatinen machen. So koennte man mit Distanzbolzen auch sein passenden Loetfeld mit "aufschrauben". Trotzdem, die Version in eurem Bild ist "todschick"! Der Loetkolben

Hallo borg, danke fuer die freundliche Antwort. Mein Mixer meinte: "Tinkerforgekompatible" - D.h. nicht Rasterplatine wo Loch an Loch ist, sondern eine ueberarbeitet Idee der Gehaeusebodenplatte. Sie sollte halbwegs universell. Mal ein ganz vorsichter Vorschlag: Die Loecher koennten so angebracht sein, dass folgende Kombinationen draufpassen. (Achtung: Nicht genau durchgespielt, nur mal durchgedacht) 1 Stack + 4 Minibricklets oder 1 Stack + 2 Minibricklets + 2 Midibricklets oder 2 Stack + 2 Minibricklets oder 1 Stack + 2 Minibricklets + Rasperry(via 4cm Distanzbolzen ueber den Bricklets) oder oder oder oder Vielleicht kann man eine Lochkombination finden die 80% der Einsatzfaelle abdeckt. Hier waeren dann die Konstrukteure im Forum gefragt um das mal konstruktiv/bildlich umzusetzen. Wie gesagt, nur wenn genug Interesse besteht und es sich organisatorisch machen laesst. Der Loetkolben