Wifi-Extension auf Stack, kein Verbindungsversuch

Hallo,

ich habe eine Stack aus einem Master-Brick und 4 DC-Bricks.

Ganz oben sitzt die WiFi Master Extension. Damit habe ich keine Verbindung hinbekommen. Mir ist aufgefallen, das die grüne Status-LED nicht, wie in der Dokumentation beschrieben, blinkt. Ich habe dann nur einen Master-Brick und die Extension zusammengesteckt. Damit hat es dann auf Anhieb funktioniert.

Der große Stack bestand aus

Step Down Power Supply (9V)

Master Brick (Firmware V1.3.4)

4x DC Brick (Firmware V1.1.2

Wifi Master Extension

Der kleine Stack besteht nur aus dem Master und der Wifi-Extension.

Strom bekommt er über USB.

Weiterhin ist mir aufgefallen, das der BrickViewer bei der WLAN Konfiguration

träge oder gar nicht reagiert. D.h. es dauert 2-3 Sekunden bis eine Combobox aufklappt. Beim klicken auf "Show Status" oder "Save Wifi Configuration" hängt der Viewer einige Sekunden, aber es erscheint kein Popup-Fenster.

Wenn ich beim Master(Großer Stack) Reset ausführe (sowohl aus dem Viewer als auch per Taste) blinkt die Status LED der Wifi-Extension nicht und leuchte nicht.

Wenn ich wie oben beschrieben nur Master und Wifi-Extension verwende, habe ich keine dieser Probleme. Die Verbindung wird aufgebaut, die grüne Status-LED blinkt und leuchtet dann dauerhaft.

Sind solche Probleme bekannt?

Was kann ich tun?

Ich verwende

  Brick Viewer 1.1.11

  Brick Daemon 1.0.9

Ergänzung:

Ich hab noch ein bischen rumprobiert. Sobald ein zusätzlicher Brick (getestet mit DC- und IMU-Brick auf dem Master steckt, funktioniert  die Wifi-Extension nicht mehr. Ich habe dann aus Versehen die zusätzlichen Bricks auf die Wifi-Extension gesteckt.

Die Wifi-Extension steckte direkt auf dem Master. Damit hat die Wifi-Extension dann wieder funktioniert. Stellt sich jetzt für mich die Frage, an welcher Position im Stack die Master-Extensions stecken sollten. Die Chibi-Extension hat auch funktioniert, wenn sie an oberster Stelle steckte. Ist die Position der Extensions nun egal, solange sie über den Master steckt, oder muss die Extension direkt auf dem Master stecken und es war Zufall, das die Chibi-Extension trotzdem funktioniert hat. Eigentlich wäre es ja sinnvoll wenn Extensions mit Antenne ganz oben im Stack sitzen.

Danke

lightman

Die WIFI Extension sollte überall im Stack funktionieren, am besten einmal den DC Brick und die IMU updaten: http://www.tinkerunity.org/forum/index.php/topic,673.msg5715.html#msg5715

Danke,

nach dem Update aller Bricks auf die neuste Firmware funktioniert es.

Besteht vielleicht die Möglichkeit, das im BrickViewer vor bekannten

Inkompatibilitäten gewarnt wird.

Oder vielleicht besser, das angezeigt wird wenn neue Firmware-Versionen zur Vergügung stehen. Es wäre auch schön wenn man den Brick über den BrickletViewer in den Modus zum Flashen setzen könnte.

Übrigens Danke für die Arbeit die Ihr bisher geleistet habt.

Endlich mal Elektronik, die ohne Löten funktioniert. Damit kann sogar ich

als Sehbeinderter mal was "basteln". Weiter so.

lightman

Oder vielleicht besser, das angezeigt wird wenn neue Firmware-Versionen zur Vergügung stehen.

Da bin ich wohl nicht der einzige mit diesem Wunsch

Oder vielleicht besser, das angezeigt wird wenn neue Firmware-Versionen zur Vergügung stehen. Es wäre auch schön wenn man den Brick über den BrickletViewer in den Modus zum Flashen setzen könnte.

So ein "Check for Updates" im Brick Viewer ist geplant und da das mittlerweile mehrere Leute gewünscht haben wird das jetzt in Kürze kommen.

Einen Brick per Brick Viewer in den Bootlader zu bringen ist wohl möglich, braucht aber neue API. Ist auf der TODO Liste.

Was auch geht ist den Brick automatische nach dem Flashen neuzustarten. Das habe ich gerade in den Brick Viewer eingebaut

Hallo photron.

Einen Brick per Brick Viewer in den Bootlader zu bringen ist wohl möglich, braucht aber neue API. Ist auf der TODO Liste.

Remote FW update??? Bitte.

Der Loetkolben.

Einen Brick per Brick Viewer in den Bootlader zu bringen ist wohl möglich, braucht aber neue API. Ist auf der TODO Liste.

 

Remote FW update??? Bitte.

Auch das automatisiertere Flashen wird noch eine USB Verbindung zwischen Brick und Rechner mit brickv brauchen. Aber ja es sieht so aus als könnte man es so bauen, dass man zum Flashen eines Bricks keinen Knopf mehr am Brick selbst drücken müsste.

Auch das automatisiertere Flashen wird noch eine USB Verbindung zwischen Brick und Rechner mit brickv brauchen.

Geht es auch wenn zwischen dem Brickv 100km und ein Brickd sind? 

Also remote an einem entfernten Rechner? Dann muesste der brickd unterstuetzen.

Der Loetkoben

Mit brickd hat das Flashen von Bricks ja nichts zu tun. Du musst nur auf deinem 100km entfernten Rechner brickv starten.

Hallo photron,

das Prinzip habe ich verstanden, deshalb meinte ich auch, dass der Brickd "helfen" muessen.

Das Problem ist, dass man auf den kleinen Linuxrechnern keinen Brickv starten kann, da dort keine grafische Oberflaeche, weder lokal noch per X, vorhanden ist.

Dementsprechend muesste a) entweder der brickv den brickd steuern, wobei der brickd dann das eigentliche flashen in der Ferne uebernimmt oder b) es koennte ein Kommandozeilentool zum flashen geben was aus einem abgespeckten brickv besteht.

Beide Versionen verursachen auf jeden Fall Mehraufwand auf eurer Seite. Mein Problem ist, dass ich einem normalen User nicht erklaeren kann wie man einen Brick am seinem User-PC flasht. Wenn alles gut geht, muss er nur den Brickv bedienen. Im Problemfall muss er dann aber Trieber von Hand installieren usw.

Das Thema ist nicht wirklich akut fuer mich, aber vielleicht nehmt ihr es einfach mal mit in eure Ueberlegungen auf.

Der Loetkolben

+++ für Kommandozeilenmöglichkeit

Mir geht es ja auch so, dass die Stacks an einer "kleinen" Maschine hängen. Keine grafische Oberfläche, nichtmal ein Monitor. Ich muss also immer die Stacks abpflücken und neu flashen und anschliesend wieder ranhängen.

Es wäre eine super Sache, die mal im Betrieb zu aktualisieren...

Okay, jetzt verstehe ich das Problem. Flashen per Kommandozeile ist auf der TODO Liste. Wird dann ein Python Script werden.

Dann gehe ich mal in die Vollen 

Muesste man dann den brickd stoppen oder deinstallieren, damit man mit dem brick_flash_cmd das Brick flashen kann?

Brrr. Langsam ....  Lasst uns doch erstmal die wichtigen Sachen fertigmachen. 

Der Loetkolben

Muesste man dann den brickd stoppen oder deinstallieren, damit man mit dem brick_flash_cmd das Brick flashen kann?

Nein, brickd und Flashen haben nichts mit einander zutun. Abgesehen, davon dass das Flash Script initial einmal über brickd mit dem Brick reden muss um ihn in den Bootloader bringen zu können, wenn das Script vollautomatisch Flashen können soll.

Der Ablauf wäre: flash.py verbindet sich mit dem lokalen brickd und ruft auf dem zu flashenden Brick die Funktion zum Wechsel in den Bootloader auf (diese Funktion gibt es im Moment noch nicht). Dann taucht der Brick als Seriel Port auf und flash.py schreibt die neue Firmware in den Flash. Zuletzt löst flash.py ein Reset des Bricks aus und er startet mit der neuen Firmware.

Dieses automatische Neustarten nach dem Flashen wird auch schon die nächste brickv Version können.

Brick Viewer 1.1.12 hat jetzt einen Check-for-Update Dialog.

TOLL! 

Wenn jetzt noch der Brickletflasher wuesste an welchem Port welches Bricklet haengt  ... Aber wenn ich das richtig gelernt habe ist das nicht ohne weiteres herauszufinden, da das Brick die Bricklets einfach durchnumeriert, oder?

MB + A=leer + B=Temp + C=Humi ==> ID 01,02,03

MB + A=Temp + B=Humi + C=leer ==> ID 01,02,03

Stimmt das?

Aber vielleicht habt ihr ja noch eine Moeglichkeit die Zuordnung abzufragen, per ID zu flashen oder das ins neue Protokoll mit aufzunehmen.

Aber fuer diesen Schritt hier erstmal einen herzlichen Dank!

Der Loetkolben

Richtig, es gibt im Moment keine Funktion um robust herauszufinden, wo welches Bricklet dran hängt. Dazu müsste man den Bricks eine neue Funktion beibringen um genau an diese Information zu kommen. Damit kann man dann automatisch Bricklets flashen.

Eine weitere neue Funktion ist nötig um einen Brick per API in den Bootloader zu bringen. Damit kann man dann automatisch Brickls flashen.

Das sollte alles möglich sein und steht auch erstmal auf der TODO Liste.

Richtig, es gibt im Moment keine Funktion um robust herauszufinden, wo welches Bricklet dran hängt. Dazu müsste man den Bricks eine neue Funktion beibringen um genau an diese Information zu kommen. Damit kann man dann automatisch Bricklets flashen.

Ich mache es immer so im BrickViewer:

[*]UID für den Port laden

[*]Gegen angeschlossene Bricklets prüfen im Hauptfenster

[*]zugehörigen Typ der für die geladene UID gilt auswählen

[*]Bricklet flashen

Müsste doch auch automatisch so gehen?