Nic

Ich kann den TP-Link TL-WDN3200 problemlos z.B. auf dem aktuellen Raspbian und einem Raspi 3 bzw. Zero u.a. auch auf 5Ghz benutzen. Unter Win/Ubuntu noch nicht getestet. Gib bitte mal an, welche Abfragen ich auf dem Red machen kann, solange der WDn3200 angesteckt ist, damit ihr zwecks Fehlersuche einfacher habt.

Hammer! Prima, dass der RED ein Upgrade erhält. Der WLAN Dualband Adapter Asus USB-N53 funktioniert schonmal und sogar auf 5Ghz(!). Im Gegensatz zum Raspberry/Raspbian kann ich eine Putty Verbindung zum Red nur über IP öffnen, Hostname red-brick geht nicht. Einen leistungsschwächeren Dualband TL-WDN3200 von TP-Link bekomme ich nicht dazu sich mit dem Router zu verbinden. Im BrickV wird zwar ein Interface Name wlx<Mac-Add> angegeben und man kann einen Scan starten aber es wird nix gefunden. Ist das init.d weiterhin nutzbar oder nur noch sytemd? Welchen Desktop haben wir zu erwarten?

Hey Skippi, die Dinger hatte ich auch schon im Auge Gib mal bitte einen Link zu dem Teil womit Du gute Erfahrungen gemacht hast. Bei den Amazonen gibt es zig verschiedene Varianten und Preise PS: Was heißt preinstalled-OpenWRT? Bzw. ist das ein echtes openWRT oder ein Klon?

Tinkerforge auf Android? Im Code lese ich localhost für die Ipconnection? Das setzt voraus dass da im Android System ein Brick Dämon laufen müsste. Auf dem PC wird das u.u. zutreffen. Für Android gibt es leider keine Portierung vom BrickD.

Wieder steht in der Doku: Hast Du die Firmware des RTCs aktualisiert? Abschließend "npm update tinkerforge" oder gem. package.json das Package von tf aktualisieren.

Wenn der Master auf dem RED sitzt, wird der RED zum Super-Master und steuert die Ext. an. Der Master-Brick ist dann nur ein normaler Brick und hat nix mehr zu melden. Der RED unterstützt aber nur Ethernet und RS485 Ext.

In der Doku steht groß und breit https://www.tinkerforge.com/de/doc/Hardware/Master_Extensions/WIFI_V2_Extension.html#wifi-v2-extension Eine WIFI Extension wird vom RED also direkt nicht unterstützt, wenn der Master plus Ext auf dem RED gestackt sind. Du kannst die Ext. nur im Zusammenhang mit dem Master-Brick verwenden. WLAN am RED machst du mit einem kompatiblen WLAN Stick.

Ich erinnere mich an deinen ersten Thread. http://www.tinkerunity.org/forum/index.php/topic,3150.msg19485.html Die 100k Schritte reichen, aber nur für leichte Lasten wie Webcam, kleine Digitalkamera etc. Ohne Getriebe hat der Schrittmotor bei Mikroschritt zu wenig Power. Wenn eine massive DSLR plus Objektiv bewegt werden soll, eine Russentonne oder Celestron Teleskop braucht es trotzdem ein Getriebe um genügend Drehmoment zu erreichen. Mit zunehmender Brennweite wächst auch der Anspruch an die Schrittauflösung/genauigkeit. Die Motor/Planetengetriebe Kombo aus dem Shop wäre ev. ein Anfang. Wenn du verbrieftes Astro Feedback möchtest, würde ich auch einschlägige Foren hinzuziehen: http://forum.astronomie.de/phpapps/ubbthreads/ubbthreads.php/topics/859286/Frage_Schrittmotor_Nachfuhrung

Du hast das u.U. mit dem alten Stepper verwechselt. Clipboard02.bmp

Na endlich! Das war ne Geburt Ich kann das auf den Bildern nicht sehen, sind da schon die neuen Bricklet Buchsen 7polig drauf?

Der Silent Stepper macht seinen Namen alle Ehre Gibt es Neuigkeiten zum Brick oder wird er bald in leisen Schritten Richtung Shop steppen?

Meiner bescheidenen Meinung nach ab Master 2.0 (2013) und jede Extension: http://www.tinkerunity.org/forum/index.php/topic,1404.msg8909.html

Bei mir WIn10 macht der Chrome v55 das Icon, der Firefox v50.1 seltsamerweise nicht.

Meine Vermutung stimmt anscheinend nicht, die libusb wird zur Laufzeit geladen: 2017-01-15 15:55:08.997002 <I> <main_linux.c:284> Brick Daemon 2.2.4 started (pid: 1500, daemonized: 0) 2017-01-15 15:55:08.997539 <D> <libusb.c:105> Successfully loaded libusb-1.0.so 2017-01-15 15:55:08.997654 <D> <event.c:57> Initializing event subsystem 2017-01-15 15:55:08.997760 <D> <event|event.c:221> Added generic event source (handle: 5, events: 0x0001) at index 0 2017-01-15 15:55:08.997832 <D> <hardware.c:39> Initializing hardware subsystem 2017-01-15 15:55:08.997874 <D> <usb.c:238> Initializing USB subsystem 2017-01-15 15:55:08.997937 <D> <usb_posix.c:161> Successfully loaded libusb-1.0.so [timestamp] [threadID] facility level [function call] <message> -------------------------------------------------------------------------------- [ 0.000028] [000005dc] libusb: debug [libusb_init] created default context [ 0.000111] [000005dc] libusb: debug [libusb_init] libusb v1.0.21.11156 ... Am Router habe ich jeweils am USB2 oder USB3 Port einen Master-Brick plus RTC angeschlossen, ansonsten hängen da nur Harddrives/USB Stick. lsusb und dmesg geben nicht viel her. Der Master-Brick soll ein GSM Modem sein admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# dmesg | grep usb usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb usbcore: registered new interface driver usb-storage usb usb1: No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0 ep 129: using minimum values [xhci-hub] usb2mode:[0] usbcore: registered new interface driver usblp usbcore: registered new interface driver asix usbcore: registered new interface driver cdc_ether usbcore: registered new interface driver rndis_host usbcore: registered new interface driver cdc_ncm usb 2-1: new high speed USB device using ehci_hcd and address 2 usbcore: registered new interface driver cdc_wdm usbcore: registered new interface driver qmi_wwan usbcore: registered new interface driver cdc_mbim usb 2-2: new high speed USB device using ehci_hcd and address 3 usb 2-1.1: new high speed USB device using ehci_hcd and address 4 scsi0 : usb-storage 2-1.1:1.0 usb 2-1.2: new high speed USB device using ehci_hcd and address 5 scsi1 : usb-storage 2-1.2:1.0 usb 2-1.4: new high speed USB device using ehci_hcd and address 6 usb 2-1.4.1: new high speed USB device using ehci_hcd and address 7 usb-storage 2-1.4.1:1.0: Quirks match for vid 152d pid 2329: 8020 scsi2 : usb-storage 2-1.4.1:1.0 usb 2-1.4.3: new high speed USB device using ehci_hcd and address 8 scsi3 : usb-storage 2-1.4.3:1.0 usb 2-2.1: new high speed USB device using ehci_hcd and address 9 scsi4 : usb-storage 2-2.1:1.0 usb 2-2.2: new high speed USB device using ehci_hcd and address 10 scsi5 : usb-storage 2-2.2:1.0 usb 2-2.3: new high speed USB device using ehci_hcd and address 11 usb 2-2.4: new full speed USB device using ehci_hcd and address 12 usb 2-2.3: new high speed USB device using ehci_hcd and address 13 scsi6 : usb-storage 2-2.3:1.0 usbcore: registered new interface driver usbserial usbcore: registered new interface driver usbserial_generic usbserial: USB Serial Driver core usb 2-2.4: GSM modem (1-port) converter now attached to ttyUSB0 usbcore: registered new interface driver option admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# lsusb Bus 001 Device 001: ID 1d6b:0003 Bus 002 Device 001: ID 1d6b:0002 Bus 003 Device 001: ID 1d6b:0001 Bus 002 Device 002: ID 05e3:0608 Bus 002 Device 003: ID 2109:2811 Bus 002 Device 004: ID 174c:1153 Bus 002 Device 005: ID 1058:0830 Bus 002 Device 006: ID 05e3:0608 Bus 002 Device 007: ID 152d:2329 Bus 002 Device 008: ID 0951:1643 Bus 002 Device 009: ID 13fd:3940 Bus 002 Device 010: ID 1058:10b8 Bus 002 Device 012: ID 16d0:063d Bus 002 Device 013: ID 1058:10a8 Laut Router-Log müsste der Master-Brick das hier sein, keine Ahnung warum. Könnte dieser Kernel-Treiber blockieren? Aug 1 00:00:35 kernel: USB Serial support registered for GSM modem (1-port) Aug 1 00:00:35 kernel: option 2-2.4:1.0: GSM modem (1-port) converter detected Aug 1 00:00:35 kernel: usb 2-2.4: GSM modem (1-port) converter now attached to ttyUSB0 Aug 1 00:00:35 kernel: usbcore: registered new interface driver option Aug 1 00:00:35 kernel: option: v0.7.2:USB Driver for GSM modems Achso, ich hatte den Brick zwischendurch angesteckt, Hotplug geht aber nicht. Nachdem ich den Brickd nach Reboot autom. starte, klappt das nun ganz hervorragend : 2015-08-01 00:00:31.419171 <I> <main_linux.c:284> Brick Daemon 2.2.4 started (pid: 1076, daemonized: 0) 2015-08-01 00:00:31.435792 <I> <usb.c:191> Added USB device (bus: 2, device: 9) at index 0: Master Brick [6Qm1Qj] brickd_komplett.log

Jetzt verstehe ich, gem. https://github.com/Entware-ng/Entware-ng/wiki/Using-gcc-%28native-compilation%29 muss ich zuerst source /opt/bin/gcc_env.sh ausführen. Dann klappt das mit make und erzeugt ein ausführbares Compilat. admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# ./brickd 2017-01-15 12:45:43.160641 <I> <main_linux.c:284> Brick Daemon 2.2.4 started (pid: 2900, daemonized: 0) 2017-01-15 12:45:43.271910 <E> <usb_stack.c:397> Could not claim interface of USB device (bus: 2, device: 6) after 10 retry(s): LIBUSB_ERROR_BUSY (-6) 2017-01-15 12:45:43.272226 <W> <usb.c:181> Ignoring USB device (bus: 2, device: 6) due to an error admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# ldd ./brickd libdl.so.2 => /opt/lib/libdl.so.2 (0x4012e000) libpthread.so.0 => /opt/lib/libpthread.so.0 (0x40141000) libc.so.6 => /opt/lib/libc.so.6 (0x4016b000) /opt/lib/ld-linux.so.3 (0x400a0000) Da fehlt die Ref. auf libusb, oder? libusb ist aber bekannt: admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# pkg-config --modversion libusb-1.0 1.0.21 admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# pkg-config --list-all | grep libusb libusb-1.0 libusb-1.0 - C API for USB device access from Linux, Mac OS X, Windows, OpenBSD/NetBSD and Solaris userspace admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# brickd

Das produziert mir zumindest ein brickd File: admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# make WITH_LIBUSB_DLOPEN=yes WITH_LIBUDEV_DLOPEN=yes CC=gcc prefix=/opt libraries/tools: - libusb: dlopen - libudev: dlopen - pm-utils: no features: - logging: yes - epoll: yes - debug: no - profiling: no - red-brick: no - hotplug: libusb (if supported) or libudev - mesh-single-root-node: no CC ../daemonlib/array.o CC ../daemonlib/base58.o CC ../daemonlib/config.o CC ../daemonlib/conf_file.o CC ../daemonlib/enum.o CC ../daemonlib/event.o CC ../daemonlib/file.o CC ../daemonlib/io.o CC ../daemonlib/log.o CC ../daemonlib/node.o CC ../daemonlib/packet.o CC ../daemonlib/queue.o CC ../daemonlib/socket.o CC ../daemonlib/utils.o CC ../daemonlib/writer.o CC ../daemonlib/daemon.o CC ../daemonlib/log_posix.o CC ../daemonlib/pid_file.o CC ../daemonlib/pipe_posix.o CC ../daemonlib/signal.o CC ../daemonlib/socket_posix.o CC ../daemonlib/threads_posix.o CC ../daemonlib/event_linux.o CC ../daemonlib/timer_linux.o CC base64.o CC client.o CC config_options.o CC hardware.o CC hmac.o CC mesh.o CC mesh_stack.o CC network.o CC sha1.o CC stack.o CC usb.o CC usb_stack.o CC usb_transfer.o CC websocket.o CC zombie.o CC usb_posix.o CC main_linux.o CC udev.o CC ../build_data/linux/libusb/libusb.o LD brickd Jedenfalls sehe ich es im aktuellen Verz. admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# ls Makefile config_options.p log_winapi.c network.p sha1.p usb_stack.h assets event_winapi.c main_linux.c red_ethernet_extension.c sources usb_stack.o base64.c fixes_mingw.c main_linux.o red_ethernet_extension.h stack.c usb_stack.p base64.h fixes_mingw.h main_linux.p red_extension.c stack.h usb_transfer.c base64.o fixes_msvc.c main_macosx.c red_extension.h stack.o usb_transfer.h base64.p fixes_msvc.h main_uwp.cpp red_rs485_extension.c stack.p usb_transfer.o brickd hardware.c Aber file not found admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# ldd ./brickd -sh: ./brickd: not found Make install produziert in /opt/bin/brickd admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# make install prefix=/opt libraries/tools: - libusb: 1.0.21 - libudev: not required - pm-utils: no features: - logging: yes - epoll: yes - debug: no - profiling: no - red-brick: no - hotplug: libusb - mesh-single-root-node: no MD /opt/bin MD /opt/etc MD /opt/etc/init.d MD /opt/etc/logrotate.d MD /opt/var/log MD /opt/var/run MD /opt/share MD /opt/share/man MD /opt/share/man/man8 MD /opt/share/man/man5 CP brickd CP brickd.conf install: cannot stat ‘../build_data/linux/etc/brickd-default.conf’: No such file or directory make: *** [Makefile:474: install] Error 1 admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# which brickd /opt/bin/brickd admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# ldd /opt/bin/brickd -sh: /opt/bin/brickd: not found Warum brickd nicht gefunden wird ist mir ein Rätsel?

Hey, danke für deinen unermüdlichen Support Also wir scheinen der Sache langsam näher zu kommen. Die libudev gibt es zwar nicht im Entware-ng repo: http://pkg.entware.net/binaries/armv7/Packages.html Und der opkg Manager listet nichts mit opkg list | grep libudev auf. Nachdem ich die Vorgaben gem. https://github.com/Entware-ng/Entware-ng/wiki/Using-gcc-%28native-compilation%29 erfüllt habe, ging auch das Compilieren der libusb. Sorry in die doc hätte ich mal früher schauen sollen admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# pkg-config --modversion libusb-1.0 1.0.21 admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# pkg-config --list-all | grep libusb libusb-1.0 libusb-1.0 - C API for USB device access from Linux, Mac OS X, Windows, OpenBSD/NetBSD and Solaris userspace Aus dem git habe den Brickd neu geholt und das make kommt hier weiter, aber bricht ab: admin@nas:/tmp/mnt/Optware/entware/_compile/brickd/src/brickd# make WITH_LIBUSB_DLOPEN=yes WITH_LIBUDEV_DLOPEN=yes libraries/tools: - libusb: dlopen - libudev: dlopen - pm-utils: no features: - logging: yes - epoll: yes - debug: no - profiling: no - red-brick: no - hotplug: libusb (if supported) or libudev - mesh-single-root-node: no CC ../daemonlib/array.o /bin/sh: cc: not found cp: can't stat '../daemonlib/array.d': No such file or directory /bin/sh: can't open ../daemonlib/array.d: no such file /bin/sh: cc: not found make: *** [Makefile:518: ../daemonlib/array.o] Error 127 Ist da noch ein Pfad Problem? daemonlib ist parallel zum Verzeichnis brickd unter /src/brickd. Bei der libusb Erstellung musste ich den Standardpfad ändern statt "/usr/local" --PREFIX=/opt anderenfalls würde das im ReadOnly FW des Routers landen. libusb-1.0 config.log

"Neues aus dem Blog" bindet eher die Kunden dauerhaft und hält sie in Spannung. Das Einstiegsmovie ist aber durchaus gut für Anfänger, ich würde es sichtbar halten, aber nicht so groß. Vielleicht nur auf rechtes Drittel des Contents beschränkt. Den Betrachter der Seite so wenig wie möglich zum Scrollen nötigen

Sehr schick, gefällt mir gut. Unter https://www.tinkerforge.com/de/home/how-it-works/ würde ich unter "Die Programmiersprachen..." Javascript/Nodejs schreiben. Oft wird Javascript nur clientseitig verstanden. Das Video auf der Einstiegsseite ist nur beim allerersten Besuch interessant, dann muss man rüberscrollen zu den für mich interessanteren Artikel wie "Von der Idee bis zum fertigen Produkt". Das Video ist eig. nur für Newbies gerichtet, ich würde es ev. weniger dominant auf der Seite platzieren, und eher den Platz für Neuheiten bzw. wechselnde Anwendungsbeispiele füllen.

So mit dem tar geht das auf dem Entware nicht admin@nas:/tmp/mnt/Optware/entware/_compile# tar xf libusb-1.0.21.tar.bz2 tar: invalid tar magic Aber mit geht es bzip2 -d libusb-1.0.21.tar.bz2 tar xf libusb-1.0.21.tar Aber ich komme nur soweit mit libusb admin@nas:/tmp/mnt/Optware/entware/_compile/libusb-1.0.21# ./configure checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... configure: error: in `/tmp/mnt/Optware/entware/_compile/libusb-1.0.21': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details config.log

Ok, prima und danke, das probiere ich dann. Gibt es die libudev auch als Sourcen zum Compilieren? Im Entware repo ist die nicht drin.

Wie groß sind die 7poligen Stecker/Buchsen dann letztendlich? Ragt das mehr über die Platinenkante?

Meine Frage und bezog sich vordergründig auf die API, die wir als Enkunden verwenden. Also keine zwangsläufigen Anpassungen wenn ich von GPSv1 auf GPSv2 umziehe oder vom alten IO4 auf IO4 mit 7poligen Stecker. Bricklet mit Copo sind aber i.d.R. leistungsfähiger und entlasten den Brick; sie können eigenständig Code ausführen, z.b. Timer, aufwendige Berechnungen, Encodersignale jenseits der 1000hz usw. Kann ich mir nicht vorstellen, wenn das die Sorge der Anwender wird, brauchen sie erst gar nicht mit der Programmierung anfangen. U.U. wird es zu Versehen bei der Bestellung kommen, wenn das aber idiotensicher im Shop auswählbar ist, dann kein Problem.

In ist dann auch die Developer libusb_dev enthalten?

Sehr interressant, dass habe ich mir schon gedacht, d.h. solche Extra-Platinen wie in http://www.tinkerunity.org/forum/index.php/topic,3701.msg23448.html#msg23448 beschrieben, wären dann eher möglich? Ich verstehe allerdings noch nicht ganz - neben dem Benefit Unabh. vom Prozessor, und 7poligen Stecker - den Vorteil innerhalb der TF Architektur. Wenn die neuen Bricklets einen eigenen Copo haben, wie kommuniziert der Bricklet mit seinem Brick, und wie verhält es sich bei 4 Bricklets an einem Brick. Greift der Brick auch wieder im Zeitscheibenprinzip die Ports ab, um zu checken ob eine Datenüb. zum Bricklet erfolgen muss, oder geht das jetzt plain und ohne Zeitverzug durch. Ich könnte mir auch alternativ vorstellen, die von den 10 Polen freigewordenen 3 Leitungen eben für solche "customized" Steuerungen wie direkte Endlagenschalter zu nutzen. Wenn die Bricklets neue Copos und 7polige Stecker bekommen, was bedeutet das für die API die wir in der Anwendungsentw. verwenden? Bedeutet es strukturelle Anpassungen etc? Persönlich ist es mir wurscht ob neue oder alte Stecker, mit den alten hatte ich eig. nie Probleme. Viel wichtiger war und ist mir kompakte, flexible Verbindungskabel, die es es auch erlaubt enge Bauräume zu nutzen. In Grunde sollten solche Stecker/Buchsen bzw. Kabel nicht zu klobig und zu hart zum Biegen sein. Was ich oft vermisst habe sind freie Lötpunkte oder wie z.B. beim RaspberryPi Zero sogen. "Probe Points" PPx..., um enge Verkabelung selbst zu lösen. Yoctopuce stattet alle seine Devices mit kleinen Lötaugen aus, Sensoren oder Displays lassen sich platzsparend von der Hautplatine trennen und wieder verlöten.