borg

Did you remove the "#define DISABLE_JTAG_ON_STARTUP" in config.h? We have to disable JTAG in the production firmwares, since some of the JTAG pins are dual purpose und used for other things.

@m0d: D.h. du erzeugst eine neue IP Connection? Mhhhh, die WIFI Extension kann 15 Sockets gleichzeitig aufhaben, danach ist Schluss und es wird ein "Connection Refused" geben. Wenn ihr es also irgendwie hinbekommt 15 Verbindungen aufzubauen die nicht wieder geschlossen werden (aus welchen Gründen auch immer), könnte es das hier geschilderte Problem erklären! Hat einer von euch Beispielcode den ich direkt ausführen kann? Oder ist das alles in größere Projekte eingebettet?

Ich kann das leider nicht reproduzieren. Meine Vorgehensweise: Ich stelle eine Verbindung her, öffne Brick Viewer und schaue mir eingehende Daten an (bin ein Raum neben dem AP). Dann schraube ich die Antenne ab und warte bis die grüne LED der WIFI Extension das blinken anfängt (das bedeutet sie versucht sich zu verbinden). Jetzt bekomme ich natürlich im Brick Viewer Timeouts und keine neuen Daten mehr. Dann schraube ich die Antenne wieder an, danach dauert es noch einen Moment bis der Socket merkt das er nicht mehr aktiv ist, es wird eine neue Verbindung aufgebaut und ich kann wieder eingehende Daten im Brick Viewer sehen. Ich betreibe das im Moment mit dem neuen Protokoll, ich meine aber das damals auch mit dem alten Protokoll genauso getestet zu haben.

Wenn ich das richtig sehe sind auf dem LED Flexband einfach 32 von diesem WS2801 ICs drauf, die man per SPI ansprechen kann. Dafür könnte man natürlich ein Bricklet machen. Die große Frage ist sicherlich wie die API für so ein LED Strip auszusehen hat. Bei 32 LEDs mit je 24 Bit Farbdaten machen das 96 Byte in Summe um alle einmal zu stellen. Das passt leider schon nicht mehr in unseren 64 Byte Payload und wir müssten schon aufspalten.

@thunderbird: Jo, guck ich mir gleich noch an. @Loetkolben: Wir erwarten einen Mehraufwand in Höhe von 2Mrd€, Veröffentlichung erfolgt in 2015 .

Wir können das neue Protokoll heute leider noch nicht veröffentlichen, wir haben in letzter Minute noch Fehler im USB Code gefunden, an dem ich jetzt schon den ganzen Tag rumdebugge. Desweiteren wollen wir nochmal die kompletten neuen Enumeration/Connect/Disconnect/ResponseExpected Funktionen in allen Sprachen gründlich durchtesten, da wir dort unerwarteterweise noch Bugs gefunden haben in den C# und Java Bindings.

Weiterentwickelt gar nicht. Schwere Bugs werden wir noch fixen. v1 Firmware für neue Bricklets wirds nicht geben. Der neue Brick Viewer kann automatisch alte (V1) Bricklets an einem neuen (V2) Brick updaten. Bricks selbst müssen "händisch" aktualisiert werden. D.h. in den Bootloader Modus bringen und im Flashing Menü den passenden Brick Typ auswählen. Wir haben einen "Transitioning Guide" in dem für alle Sprachen die relevanten Änderungen kurz mit Codeschnippseln dargestellt werden: http://www.tinkerforge.com/doc_v2/Transitioning_Guide_1To2.html Bei den allermeisten Sprachen muss nur der Enumerationsprozess überarbeitet werden, der wurde Aufgrund der vielen Fragen und des vielen negativen Feedbacks komplett überarbeitet (Device IDs anstatt Strings parsen, genug Informationen um die komplette Brick/Bricklet Netzwerk Topologie aufzubauen etc). In fast allen Sprachen dürften Anpassungen im Code nur ein paar Minuten dauern. Ausnahme ist da evtl C#, dort hat sich relativ viel geändert (CLS-Compliance, sender Objekte, neue Callback Syntax etc). Das waren aber alles sehr häufig angefragte Änderungen!

Habs mir auf die TODO Liste geschrieben, hat aber keine hohe Prio .

"selection_mask" gefällt mir, das hab ich gleich überall übernommen: https://github.com/Tinkerforge/generators/commit/f6891ca88ce2e6656bf3487b13ce25f892bde115 Die Implementierung folgt dann jetzt. PS: Wir werden dann jetzt definitiv auch diese Woche noch Protokoll V2 veröffentlichen.

That would be very hard to realize with the protocol we are currently using to transfer data between the Bricks and a PC. With the protocol we are transfering 1000 messages per second and a message has a max size of 64 byte. That makes a bandwith of 64Kb in total. Also, we can't possibly achieve a similar price to existing USB sound cards: http://www.amazon.com/Virtual-5-1-surround-External-Sound-Card/dp/B000N35A0Y/ref=sr_1_2?ie=UTF8&qid=1358157708&sr=8-2&keywords=usb+sound+card This price is preposterously low, it would cost 10 times as much if we would produce this thing.

Yes, currently you always need a PC connection. But your PC can also be a tablet or smartphone or Raspberry PI!

@Nic: Wir haben jetzt U.FL zu SMA Adapter im Shop: https://shop.tinkerforge.com/accessories/gps-pigtail-cable.html SMA GPS Antennen gibt es überall. Getestet hab ich hier mit: http://www.aldafunk.com/GPS-Antennen/GPS-Antenne-Magnetmontage-SMA-Male::143.html Der Empfang ist damit trotz 5m Kabel sehr gut (ist aber ein bisschen teuer die Antenne).

Klingt sinnvoll. Wir würden dann dafür einfach zusätzlich API hinzufügen. Was haltet ihr von "setValueSelective(pin_mask, value_mask)" oder "setPartialValue(pin_mask, value_mask)"? Wie würdet ihr es nennen?

WTF? Das macht keinerlei Sinn . Wie sieht denn die Software aus, fängst du vielleicht irgendwo Timeouts ab ohne es mitzubekommen?

Mit Protocol V2 (was im Laufe der nächsten Woche veröffentlicht wird), geht das. Du ziehst das LCD Bricklet im laufenden Betrieb ab? Das ist so leider nicht erlaubt . Der Brick hat keine Möglichkeit mitzubekommen ob das Bricklet im laufenden Betrieb an/abgesteckt wurde.

Ui, ich bin gespannt .

@Nemo: 1.1.18 sollte auf einem 10.8.2 Macbook funktionieren. Soweit ich das sehe gibt es nur Probleme bei OS X < 10.8, da es dort noch kein CoreText gab. Wir werden aber noch ein 1.1.19 releasen das wieder kein CoreText benötigt. @boscha: What version of Brick Viewer did crash for you?

Ist gefixt, Danke für den Tipp!

Echt komisch. Du hast aber bei beiden RS485 Extensions auch die gleichen Einstellungen, ja? Ich hatte schonmal ausversehen in einem Netzwerk eine RS485 Extension mit 1 Stopbit und eine mit 2 Stopbits. Das funktioniert dann auch nur sehr sporadisch. Wenn es einwandfrei funktioniert sobald du nur einen RS485 Slave hast, kann es ja nicht am AP liegen, denke ich. Du könntest auch noch einmal Probieren das EEPROM auf allen RS485 Extensions einmal auf Auslieferungszustand zurück zu setzen (im Brick Viewer unten bei "Configure Extension Type" nochmal RS485 auswählen).

Wie ist die WLAN Extension denn konfiguriert (AP/Verschlüsselung etc)? Der Power Mode steht nicht zufällig auf Low Power oder? 200ms roundtrip-time ist in der Tat ein bisschen langsam.

@Einstein: Kannst du mal probieren die WIFI Extension auf AP zu stellen? Um zu gucken ob dein Router oder QOS etwas damit zu tun haben. Wie meintest du das? Wenn du den Aufbau wie oben hast und den "leeren" RS485 Stack entfernst funktioniert es?

Komisch, wir haben ja intern eigentlich ein 2,5 Sekunden Timeout. Da sollten 6-9ms nichts ausmachen.

Kann ich leider auch nicht reproduzieren . Ich hab den gleichen Aufbau nachgestellt. Screenshots von der Konfiguration sind angehängt. Ich lasse das mal über Nacht laufen bis morgen.

Kann ich leider nicht reproduzieren.

Very cool !