Nic

M.W. soll erst ab Win8 USB3 autom. unterstützt werden, da müssen noch die Treiber-Updates ran. Bei mir war da noch zusätzl. eine HW Unverträgl. bezgl. der LibUSB vom BrickD.

LED ausschalten ? Das habe ich doch glatt übersehen, aber in der Changelog und Veröffentlichung steht nix drin: http://www.tinkerunity.org/forum/index.php/topic,673.msg19327.html#msg19327 Aber die Fkt. sind in der API: http://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_CSharp.html#BrickMaster::DisableStatusLED Schon ausprobiert ob das wirklich schon funktioniert ?

Eleganter wäre es , ihn zu fragen, welche Punkte noch unklar sind, oder dass er seine Ergebnisse aus der Probephase später hier präsentiert, um das eine oder andere Probleme noch zu diskutieren... Ansonsten hat Raphael ganz gut zusammengefasst, mir fällt sonst nur noch dieses GUI Tutorial mit TF Teilen ein: http://www.tinkerforge.com/de/doc/Kits/HardwareHacking/RemoteSwitchGUI_CSharp.html

Eigentlich schon, aber vor etwa 1 Jahr hatte ich mit einem Asus T100TA Tablet Win8 auch speziell am USB3 Port Probleme mit dem TF Stack. Das Tablet hat eine zusätzliche Tastatur mit dem USB3, da ging es nicht, aber über den MicroUSB2 allerdings schon. Entweder probiere unter Win (Welche Version?) die HW-Treiber für Chipset/USB etc. zu aktualisieren, oder probiere mal einen zusätzl. USB2 Hub zw. dem USB3 und dem Stack zu stecken, dass hatte m.W. bei mir damals als Workaround geholfen. Ansonsten starte den BrickD im Debug Modus, das Logfile hänge hier in den Thread zur Analyse, ev. kann dann photron eine Ursache/Lsg. im BrickD/Libusb finden. Gebe mal auch die ModellNr, Hersteller, OS Version mit an.

Ja, das Berlebach ist legendär, aber das und das Einnorden habe ich nicht gemeint. Sondern wie du die Polhöheneinstellung mechanisch lösen willst ? Die Neigung wohl nicht mit dem Stativ- oder Kugelkopf...

Ein 2.Getriebe würde ich nicht zusätzlich anbringen, das Getriebespiel dürfte zunehmen und es ist gut möglich abh. von der Motorleistung, die Abtriebswelle der 2.Stufe gar nicht mehr anfährt (Selbsthemmung des Getriebes). Das Gesamtgewicht nimmt auch zu. Wie hast du die Montage ans Stativ etc. gedacht ? Wie löst du die Polhöheneinstellung ? Was dir eher helfen würde wäre ein noch stärkere Schrittunterteilung als die 1/8. Vielleicht gibt es irgendwann mal einen Stepper-Brick Nachfolger mit Mikroschritt bis runter auf 1/256 Ich würde erstmal mit einem 28er Weitwinkel anfangen, und prüfen wie lange du maximal belichten kannst bis sich die Ungenauigkeit der Nachf. bemerkbar macht.

Nema 17 mindestens bei der Last, und nicht Nema 11. Beim 500er liegt es nicht unbedingt am Gewicht oder der Größe, sondern an der "Vergrößerung". Ein Tele wird die Ungenauigkeit der Nachführ. und die typ. Schrittmotorbewegung deutlicher zeigen als ein Weitwinkel.

Die "Tonne" hat 500mm Brennweite, dass dürfte mit den 43200 nicht klappen. Und mit den Reise-Nachführungen auch nicht Der Grenzbrennweite war bei diesen Teilen m.W. bei etwa max. 200mm je nach Ausrichtung und Belichtungszeit.

M.E. orientiert man sich nicht nach den Sonnentag (86400sec) sondern muss wohl nach dem http://de.wikipedia.org/wiki/Siderischer_Tag nachführen, also 86164sec. Die 43200 Schrittanzahl scheint mir erstmal nicht schlecht, allerdings richtet sich der optimale Wert u.a. nach der Auflösung des optischen Systems, d.h. für das Nachführen einer Webcam dürften die 43200 locker reichen. Ev. auch noch bei Weitwinkel--Objektiven. Entscheidend dürfte die Brennweite, Belichtungszeit, Pixelanzahl und wie gut die Montierung ausgerichtet ist. Ich würde auf den 27:1 Motor nicht nochmal eine Getriebestufe aufflanschen. Geared Schrittmotoren jenseits der 27:1 gibt es z.B. von http://phidgets.de/NEMA-17-Planetengetriebe-9951-1-Schrittmotor oder Stepperonline http://www.omc-stepperonline.com/gear-ratio-1001-planetary-gearbox-nema-17-stepper-motor-17hs191684spg100-p-46.html Von dort ist vermutl. der 27:1 aus dem TF Shop. Die Schrittmotorkarten von kommerz.Nachführungen. leisten zusätzlich noch Mikroschritt bis 1/256 Aufl. Was genau möchtest du (astro-)fotografieren ?

Exakt, das würde reichen. Für Statusinformationen machen 24bit pro Pixel keinen Sinn, mit dem MiniDisplay von Yoctopuce lässt sich gut arbeiten, sehr praktisch ist den OLED Kopf von der Treiber-Karte abzubrechen. Das OLED lässt sich dann prima auf die 8x8 Montageplatte schrauben. Allerdings braucht man für das Teil immer einen USB Port

Ich habe hier nicht von vollwertigen VGA Displays gesprochen, sondern an die Diskussion von Batti http://www.tinkerunity.org/forum/index.php/topic,2525.msg16534.html#msg16534 angeknüpft. Da war von technologischen Grenzen kein Thema, und ich verstehe nicht, wieso hier alle sich nur (Monitor-) Displays vorstellen Es geht um die Darstellung von mehr Text als beim Segment,ähnlich wie beim 20x4 LCD aber im eben wesentlich kleineren Formfaktor. Und ich hatte bisher verstanden, dass das technisch machbar ist. Adafruit: OLED 16x2 https://www.adafruit.com/products/823 Etwas mehr Zeilen...128x32 https://www.adafruit.com/products/931 Sowas zum Beispiel 96x16: Lässt sich je nach Fonts bis zu 2 Zeilen darstellen: http://www.yoctopuce.com/EN/products/usb-displays/yocto-minidisplay Anwendung bei Stacks: Z.B. Darstellung der augenblicklichen Motorkennwerte Drehzahl, Speed, Strom etc. und das möchte ich direkt am oder in Nähe des Motors anbringen. Und dafür brauchts eben nicht ein Touchscreen oder Smartphone.

Ging es hier beim Thema um Raspi Display Alternativen, oder habe ich nach speziellen HDMI Displays für den RED gefragt ? Das 20x4 LCD- oder Segment7x4-Bricklet erfreut sich großer Beliebtheit wenn man nach den Forenbeiträgen geht. Und dabei gehts erstmal überhaupt nicht um Linux, Rapsi oder RED. Eine kleines, kontrastreiches OLED-Bricklet mit 1-2 Zeilen würde die Lücke vom 20x4 und Segment u.U. schließen. Ich soll also Deiner Meinung nach für ein OLED erstmal meinen Stack mit Raspi ergänzen ?

Normalerweise deploye ich mein Programm mittels des BrickV einmalig und setze den Scheduler entsprechend um die Ausführung immer, im Interval oder Cron Job autom. zu starten. http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick_Program_Tab.html#red-brick-program-tab Wenn das Programm manuell oder bei Bedarf gestartet werden soll bietet sich z.B. die RED-API an:http://www.tinkerforge.com/de/doc/Software/Bricks/RED_Brick_Java.html#BrickRED::startProgram__i und http://www.tinkerunity.org/forum/index.php/topic,2827.msg17982.html#msg17982

Mir gehts hier in dem Thema nicht um den Raspi und seine Hardwareerweiterungen. Wenn ihr das diskutieren wollt, erzeugt dafür einen neuen Thread oder macht das in den einschlägigen Raspi-Foren. Solche Beiträge sorgen ev. nicht nur bei mir für Verwirrungen .

@TF Verstehe und macht Sinn im Zusammenhang mit den offenen Punkten des Powermanagement (Hibernate/Suspend) im RED u.a. @Angler Klär mich doch bitte auf, wie die "massenhaften" OLED-Displays an den Bricklet Port oder Board2Board Connectoren oder wie auch immer am Stack verbunden werden sollen ?

In http://www.tinkerforge.com/de/blog/2015/5/27/sneak-preview:-11-neue-bricklets vermisse ich eine Neuauflage/Ergänzung des PowerSupply (Lipos, Solarzellen etc.) http://www.tinkerunity.org/forum/index.php/topic,2525.msg16544.html#msg16544 und ein OLED Display ?

Worauf bezieht sich wenn man die Spannung näher am V-Max des Treiber/Motor fährt ? Ich vermute mal im Stepper-Brick wird immer die Konstantstromansteuerung aktiv sein unabhängig ob nun am Motor eine "Nennspannung" von z.B. 2.8v oder tatsächlich 24 bzw. 38v anliegt. Bezieht sich der Blog nicht eher auf den Vergleich mit einfachen Treiber unter Konstantspannungsbetrieb ? Mir ist dann noch nicht klar warum es dann grundsätzlich günstiger sein soll, immer eine hohe Spannung zu fahren, so richtig praktikabel wird das mit einer Spannung größer als 12v bei mobiler Stromversorgung auch nicht.

(60000*60)/(8*200*27) = 83 U/min ?

Danke Raphael. Bei Adafruit gab es so ein Teil, ist nicht mehr im Sortiment: http://www.adafruit.com/products/776 Ja mit Zahnräder geht das aber prima, ein Hohlring würde da nichts helfen. Oder alternativ an den Aderenden jeweils eine Brickletbuchse anlöten.https://www.tinkerforge.com/de/shop/accessories/connectors/bricklet-connector-header.html

Da hast du aber was feines rausgesucht, so ein Drehring mit Adern suche ich schon lange. Gibt es sowas auch um es auf eine Motorwelle zu stecken oder gar hohl ? Alternativ gibt es das Teil zumindest bei http://www.exp-tech.de/catalogsearch/result/?q=Slip+Ring Ist der Preis für das Bricklet schon bekannt ?

Danke für die Hinweise. Aber so recht kann ich das nicht glauben, dass 2 WLAN Sticks gleichzeitig von Linux benutzt werden. WLAN0 ist TP-Link WN823N + AP, WLAN2 ist der Comfast (vom Shop). WLAN0 bleibt immer am RED. Stecke ich WLAN2 hinzu, und schaue im Brick Viewer nach, so steht unter den AP-Einstellungen plötzlich WLAN2 statt WLAN0 und der Status Hinweis "Inactive- Hardware not supported or wrong config." Wenn der von m0d genannte Standard auch für die 1.4 gilt, müsste es im Viewer nicht trotzdem bei WLAN0 bleiben ? Der TP-Link scheint auch gar nicht aktiv zu sein. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 005: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter Bus 002 Device 003: ID 0bda:8179 Realtek Semiconductor Corp. Bus 002 Device 002: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub tf@red-brick:~$ Ich bekomme aber von iwconfig nur ein Interf. genannt: root@red-brick:/home/tf# iwconfig wlan2 unassociated Nickname:"<WIFI@REALTEK>" Mode:Auto Frequency=2.412 GHz Access Point: Not-Associated Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 lo no wireless extensions. tunl0 no wireless extensions.

Lässt sich das unter Linux "fixieren" ? D.h. Stick 1 mit MacAdd 12345 ist immer der Wlan0 für den AP, Stick 2 mit MacAdd 56789 falls angeschlossen ist immer WLAN1 etc.

Grundsätzlich benutze ich den RED im AP (AccessPoint) Modus. Gelegentlich möchte ich aber ins Web zwecks Installationen etc. Der Wechsel zum Wifi- und wieder zurück zum AP-Modus ist mir zu umständlich und scheint (Image 1.4) noch nicht richtig zu funkt. Gut möglich dass ich als Linux-Anfänger was falsch mache, aber 2 WLAN Stick gleichzeitig am RED geht nicht ? Liegt das an Debian Jessie Distro ? Oder am Brick Viewer ? Jedenfalls stellt sich der Brick Viewer immer auf den letzten WLAN-Stick ein, den er findet, und dann stimmt die Konfig. nicht mehr. Wäre ein Dual Betrieb möglich ?

@Milan oder Kanzler Prima, trägst du dann bitte die Webcam in die Hardware-Liste http://www.tinkerunity.org/wiki/index.php/DE/RED_USB zum RED ein, damit hilfst du anderen User, so wie dir hier geholfen wurde.

Such dir WLAN-Stick aus, entweder das Teil aus dem Shop oder von der Liste, haben wir ganz tüchtig gesammelt, könnte mehr Einträge haben, besonders Empfehlungen von Tinkerforge selbst: http://www.tinkerunity.org/wiki/index.php/DE/RED_USB Wenn du eine VM (http://de.wikipedia.org/wiki/Virtuelle_Maschine) findest die ein Linux für ARM auf einem x86 Host ausführen kann sollte das kein Problem sein Laptops fahren mit einem Intel/AMD/Mac CPU, der RED hat aber einen ARM wie für RaspPi, Smartphone, Androids etc.