Nic

Gut, und nichts anderes hatte ich gemeint; warum AuronX meine Eräuterungen als fachlich falsch interpretiert, wird nur er erklären können Etwa anderes: Aiken beschreibt sein Projekt als lauffähig direkt aus VS, man könnte den Eindruck bekommen, dies funktioniert ohne BrickD. Nicht das ich hier im Forum etwas verpasst hätte, aber eine native Verbindung nur zw. Bindings/TF-Framework und Hardware via USB Kabel ohne BrickD-Treiber ist nicht möglich ?!

Ich bin da etwas irretiert, aber das habe ich doch auch in meinem 1.Posting schon erwähnt. Ohne Mono würde die EXE erstmal nicht lauffähig sein.

Eine mit C#/VB.NET erstellte .exe kannst du so wie sie ist unter Linux ausführen, das ist in der Tat unproblematisch Also eine typische Linux-Distrib. für den RaspPi hat als Grundbestandteil schon eine Laufzeitumgeb. für .NET integriert ? Und diese ist abwärtskompatibel bis zur 2.0 ?

Fairweise sollte man auch noch daraufhinweisen, dass * auf dem RaspberryPI als Betriebssystem nur Linux läuft * die VB.Net Anwendung aber unter einem Windos-Rechner und VisualStudio erstellt wurde, die EXE ist so auf dem Linux erstmal nicht lauffähig (irgendwelche VMs oder WinEmu lassen wir mal weg) * es sei man benutzt den Mono-Framework für Linux: https://www.microsoft.com/germany/msdn/solve/knowhow/howto/cliententwicklung/WieKannIchNETAnwendungenUnterLinuxErstellenUndAusfuehren.aspx Ob der o.g. Code so ohne weitere Anpassung auch unter Mono kompatibel ist, bleibt offen. * Ohne BrickD-Treiber/Service sollte der Betrieb von TF-Bricks nicht möglich sein. Die selbstgeschr. Anwendung egal ob VB.net, C#, Java, C etc. sind erstmal nur lauffähig auf dem Host-PC, auf dem ein BrickD-Dienst installiert und lauffähig ist. Dazu gehört auch der RaspbPi, der allerdings u.a. die Vorteile mitbringt wenig Strom zu verbrauchen und sehr kompakt gegenüber Notebook oder Desktop-PC ist. Wenn das nötig ist, würde sich als Programmiersprache für den RaspPi z.B. Java anbieten. Der Brick-Viewer ist sehr praktisch um die TF-Bricks/bricklets erstmal ohne DIY-Programmierung zu testen oder auszuprobieren. PS: Alternativ um den TF-Stack dezentral vom PC zu betreiben: http://www.tinkerforge.com/de/doc/Hardware/Master_Extensions/WIFI_Extension.html#wifi-extension oder kabelgebunden z.B. http://www.tinkerforge.com/de/doc/Hardware/Master_Extensions/Ethernet_Extension.html#ethernet-extension

Für Phyton gibt es ein Openbook von Galileo, kostet nix und ist online http://openbook.galileocomputing.de/python/

Falls er die volle(!) Leistung des Motors wirklich nutzen will, aber aus seinen Angaben ist zu schließen, dass für sein Modellbau nur geringe Lasten bewegt werden. Da dürften schon 9V reichen optimal sind die 12V durchaus. Erstrangig ist der verfügbare, eingestellte Strom. Das ist der Ausgang wieviel Dreh/Haltemoment der Motor liefert. Die zu erwartende Last bestimmen, Datenblatt des Motors dessen Kennlinien studieren um die ausreichende Stromversorgung zu bestimmen.

@RouvenE Das ist schon sehr sportlich, RaspPi verwenden und noch ohne Programmierkenntnisse Die Demoanwendung oder Teile davon sind in diversen Sprachen: http://www.tinkerforge.com/de/doc/Kits/WeatherStation/WeatherStation.html#ressourcen Die bevorzugte Sprache rauspicken und den SourceCode studieren, u.a. lernt man auch so das Programmieren.

http://www.tinkerforge.com/en/doc/Hardware/Master_Extensions/Chibi_Extension.html#chibi-extension BTW, Dont hesitate to explain your issues in English, if its easier for you. Otherwise answers might wait too long to arrive...

For example if a battery pack like this one: http://www.amazon.com/dp/B00A7PF3KA has a capacity of 10000 mAh and the whole brick stack would consume approx. 300mA (in average), the battery could deliver the necessary power not more than 33 hours (theoretically For a month you should take a https://www.tinkerforge.com/en/shop/power-supplies/usb-power-supply.html. If the stack is too far away from Host-PC, the WIFI Extension (wireless) or the coming soon Ethernet-Ext.(wired connection) could be used. A brick stack has no idle (or low power) feature except the WIFi-Extension. A step down supply is needed if a power source delivers more than 6V.

Ja, wäre prima könnte ich auch gebrauchen ! Bisher gibt es das anscheinend nur für USB-A: http://www.cytron.com.my/viewProduct.php?pcode=BB-USB-A und mit einem Adapter von USB-A Buchse zu Mini-USB-Stecker verbinden: http://www.amazon.de/dp/B000Q9PROE Alternative wie von Chris: Altes Mini-USB Kabel die 5 Aderchen freilegen. PS: Die Breakout-Boards unterstützen i.d.R. aber nur geringe Ströme ! Und wenn es nur darum geht 5V Versorgungsp. in den TF-Stack zu speisen, kannste das alternativ auch über einen BoardToBoard-Connector machen.

If you really want to use this 9V battery, take the more powerful, (and expensive) lithium version. Energizer declare its capacity around 750mAh: http://www.energizer.com/batteries/performance-lithium/advanced-lithium/Pages/9v.aspx At the beginning in your case it could be enough to take a Master-Brick and connect it with a IO4 (1) or Distance IR Bricklet (2). This stack can be powered directly by the USB-Cable connected to Host-PC. Data comm. between software and the stack is provided by this cable too. In case of (1) you need an additional mechanical microswitch e.g.: https://www.tinkerforge.com/en/shop/accessories/micro-switch.html So there is no need to take both bricklets. It depends how do you want to determine door status mechanically or contact-free. A step-down-power supply is optional, but a must if you provide external servo- or stepper motors (via corresponding bricks) with higher voltage and current than the ordinary (USB-) 5V. But on the other hand a step-down supply offers more opportunities to power the stack with an external accu or battery pack that delivers a higher capacity e.g. for long term operations. A step-down power supply regulates the origin voltage (6-27V) down to 5V used by brick/bricklet-stack and loops through the full voltage to other bricks e.g. motors etc. A callback is often used to recognize state changes at pins or channels: http://www.tinkerforge.com/en/doc/Software/Bricklets/IO4_Bricklet_PHP.html#io4-bricklet-php

Welche Version vom I04 ? Die im Shop aktuelle oder die alte 1.0 ?

Ja, meine Sorge galt aber mehr dem Datenstrom, und nicht der Stromversorgung. Beides, Stack-Comm und fetter Videostream wird über eine USB Leitung nicht machbar sein. Übers Netzwerkkabel wäre zumindest PoE möglich.

Nein, interessant ist das allemal, sicher eine gute Ergänzung zum IMU, oder späteren Roboter/Oktokopter Anwendungen. Aber über den "dünnen" USB-2 Strom würde ich das ins Stack nicht pressen. Die Kamera übers Netzwerk einzubinden, würde praktikabler sein.

Wäre prima, aber würde die entstandene Datenmenge bei 1080p dann noch durch die BrickStack-Architektur passen ?

Nasen oder Verbindungslaschen etc. siehe Attachment. Im ersten Moment dachte ich, die sind unten länger, um dann in eine 2.Box oben einzustecken, also stapelbar zu gestalten. Voraussetzung für die Laschen unten dann aber ein gewisser Versatz. Die Fußerl Feature bleibt weiterhin bestehen.

In der Tat, sieht sehr gut aus, die Verbindungsnasen unten sind aber länger als an den Seiten, damit lässt sich das nur stapeln ? Also mit diesem Konzept sind also erstmal nur Bricklets im Gehäuse umschlossen ?

Wenn ichs richtig verstanden habe, gibt es im Modell insgesamt 18 Stockwerke. Pro Stockwerk kommt 1 LED-Streifen mit 12V@170mA zum Leuchten. Dann würde ich auch zu 5 Indus.QuadRelays greifen. Unabhängig davon sollen noch 2 Schrittmotoren versorgt und gesteuert werden. Mit Step-Down... Mit dem StepDown-Power-Supply wird zum einen der Brick/Bricklet-Stack mit 5V versorgt und die beiden Schrittmotoren (über die Stepper-Bricks) erhalten ihre spezielle Versorgungsspannung gleichzeitig. Dabei kann, muss es aber nicht ein Netztteil sein, sondern ev. auch ein 12 oder 9 V Akku mit ausreichender Kapazität je nach Betriebsdauer. Ich gehe davon aus es werden nur minimale Lasten (300-500gr) von den Motoren gefordert. Ev. sind die Motoren etwas oversized, die 2A pro Phase und das Haltemoment von theor. max. 9,32 Kg/cm wirst Du i.d.R. nicht anfahren. Ohne Step-Down... Der Stack kann aber auch nur über USB-Kabel seine 5V bekommen. Oder mittels (AufladeHandy)-Akku 5 V über USB-Stecker. Dann muss aber an jedem Stepper-Brick die Stromversorgung für die Motoren extra angeschl. werden. Die Versorgung der LEDs über die Quad-Relay wird aber nicht über den Step-Down-Supply geliefert sondern muss separat geschaltet werden siehe Bild.

So ganz falsch liegst Du damit nicht, denn der EnumerateEvent-Handler in C# gibt die FW- und Hardware-Version hier jeweils als Array der festen Größe 3 vom Typ short zurück, Arrays erkennbar an den eckigen Klammern: ...short[] hardwareVersion, short[] firmwareVersion... Der Ursprung ist sehr schön zu sehen in der Methode DispatchPacket der IpConnection Class.

Nur so übers Knie gebrochen: (+) geringerer Verbrauch 10mA zu 100mA geringerer Aufwand zu konfigurieren geringerer Preis, damals um die 30 Euro u.U. höhere Reichweite bis zu 2km (laut Angabe der Spezif.) (-) u.U. geringerer Datendurchsatz soll langsamer in der Datenübertragung sein als WIFI nicht so universal einsetzbar wie WIFI, Netzwerkfähigkeit Zu Datendurchsatz und Performance hatte ich mal vor seeeehr langer Zeit hier im Forum eine Anfrage, aber so wegen schlechten Wetterbedingungen und so... konnte man von TF da noch keine Vergleichtests machen. Für mobile Anwendungen (Outdoor, Verbrauch, robuster) würde ich persönlich das Chibi verwenden, wenn es um stationäre Projekte (mit Netzwerk-Hintergrund) eher zum WIFI. PS: Was soll in der WIFI-Doku eigentlich bedeuten ?

möchtest du WIFI als Stack-zu-Stack Verbindung einsetzen, das ist so nicht vorgesehen. Lässt das die Hardware nicht zu oder ist das nur eine Anpassung der FW ?

Sowas suche ich auch, aber von TF wurde (unverbindlich) die Absicht bekundet eine Neuauflage ev. zu veröffentlichen, die wird aber etwa genauso teuer wie die WIFI: http://www.tinkerunity.org/forum/index.php/topic,1243.msg7628.html#msg7628 http://www.tinkerunity.org/forum/index.php/topic,1418.msg9069.html#msg9069 PS: Ev. kann TF mal was über den neuesten Stand dazu schreiben...

Hmmh, denke auch, dass Pluto damit das OnDevice-Programming meint: Der umfangreichste Thread war bisher: http://www.tinkerunity.org/forum/index.php/topic,1459.0.html Ergebnis offen, ob es nun in C oder Phyton oder irgend neue neue (Basic-) Scriptsprache dafür gibt.

Das würde mich auch interessieren, wenn ichs richtig verstanden habe: Du möchtest eine PC zu Master-Stack Verbindung nur über 2 Chibis. Dieser Master-Stack hat noch eine 2.Ext die WIFI und mit der möchtest Du Dich mit mehreren WIFI-Stacks verbinden ?

Seltsam hier in Berlin gibt es zahlreiche Baumärkte, da sucht man aber vergebens nach geeignetem PMMA. Da gibt es nur Alu, Stahl oder Holz. Vom Zuschnitt ganz zu schweigen, i.d.R. ist dabei die kleinste Kantenlänge 100, aber auch nur für Holz. Onlineshops unterstützen den mm-genauen Zuschnitt von Kunststoff für Endverbraucher kaum, und wenn mit saftigen Aufpreis und entsprechender Stückzahl. Ein paar Montagelöcher in 3mm starkem PMMA zu bohren sollte keine hohe Kunst sein, zumal das für die neue Wetterstation ausdrücklich empfohlen wird, und im Vorfeld das niemand in Frage gestellt hat. Es wäre also zu Beginn schon ein Fortschritt, Montageplatten im passenden Zuschnitt für die Bricks/Bricklets anzubieten, Hilfsmarkierungen/Sollbruchstellen vermeiden das unnötige Ausmessen und sollten technisch und wirtschaftlicher zu fertigen sein als eine Hundertschaft von Bohrungen, von denen man i.d.R. nur 4 oder max. ein Dutzend benötigt, alles andere erhöht unnötig den Preis. Ich möchte nicht wissen wie teuer z.B. der o.g. Prototyp wäre. So wie die Montageplatte bisher konzipiert ist als 2-dimensionaler Lochrasterteppich, würde ich ev. weiter gehen und die Platten relativ einfach halten um den 3D-Gehäusebau auch zu unterstützen.