Hallo,
ich hätte da gern mal ein Problem, und ich hoffe das die
Schwarmintelligenz hier was weiß.
Vorab: Das ist kein Aprilscherz.
So, um was geht's?
Ganz einfach: Ein kabelloses USB-Kabel.
Mich hat jemand gefragt, ob mir eine Idee einfiele, wie man das lästige
Kabel an dem Gerät loswerden könnte, denn die Länge und vor allem das
einfache Vorhandensein des Kabels stört ("es zieht und stört beim
hantieren").
Ein Akku, Gewicht und Platz ist nicht wirklich das Problem, Geld nur
zweitrangig.
Was allerdings sein muss:
- Kein Treiber, da der Ziel"computer" kein großartig verfügbares OS hat,
auch wenn offensichtlich USB benutzt wird.
- Reichweite wenige Meter sind genug, wie beim Kabel auch.
- Akkubetrieb möglich, aber das sollte sich von allein ergeben.
- Transparent
- USB 2.0
Übliche WLAN-Bridges fallen aus wegen dem Zielcomputer, oder weil
einfach nur bestimmte USB-Geräte unterstützt werden, z.B. Drucker.
Das hier verwendete Gerät wird unter Windows erkannt, ist aber was
eigenes, mit eigener VID, also weder Seriell, Kamera, HID oder Medium.
Ich bräuchte quasi 2 Kisten, eine mit einer USB-Buchse, eine mit einem
Stecker, und was ich in die eine Buchse reinstecke kommt am Stecker der
anderen Kiste wieder raus. Nur das dazwischen keine Schnur ist.
Ich hab keine Ahnung wie schnell das Gerät Daten überträgt und/oder ob
es bestimmte Anforderungen an den Bus stellt, aber das gibt sich dann.
Wenn jemand weiß, wie man (am liebsten unter Windows, weil ich da eine
Demosoftware habe) dem USB mal auf den Finger schauen kann, bitte auch
her damit.
Und bevor die Frage kommt: Es ist egal was es für ein Gerät ist, denn es
gibt keine Alternative Lösung. Es geht nur ein transparentes wireless
USB. Oder Kabel.
Danke für die Aufmerksamkeit. :)
wUSB gab es zu kaufen, der PC als USB Master muß windows haben, den Client, das kann ein Arduino, oder DSLR Camera sein läuft bei mir prima es gab diese wUSB von HAMA, Olidata.... https://www.amazon.de/Hama-53140-Wireless-USB-Starter-Set-Basic/dp/B001QU2WI6 https://www.amazon.de/Olidata-Wireless-USB-Set/dp/B002BX3LRI gibt es leider nicht mehr!
:
Bearbeitet durch User
Dr. Sommer schrieb: > Bluetooth Ja danke aber nein. Gab es vor 10 Jahren mal ganz kurz, aktuell nix zu kaufen. Obwohl die CWA-und-HWA-Geschichte genau ist was ich gebraucht hätte. Wird es wohl nie wieder geben. Und die die es damals gab sind schon lange im E-Schrott. Joachim B. schrieb: > PC als USB Master muß windows haben Möp. Das war schon ein Ausfall. Joachim B. schrieb: > gibt es leider nicht mehr! Und das der zweite. Schade, aber trotzdem danke.
Jens M. schrieb: > Ich bräuchte quasi 2 Kisten, eine mit einer USB-Buchse, eine mit einem > Stecker, und was ich in die eine Buchse reinstecke kommt am Stecker der > anderen Kiste wieder raus. Nur das dazwischen keine Schnur ist. Gibts nicht. Ist nicht mit vertretbarem Aufwand konstruierbar. (Die erwähnten, nicht mehr verfügbaren Produkte waren nicht "transparent", sondern brauchten ihre spezifischen Devicetreiber)
Rufus Τ. F. schrieb: > Gibts nicht. Ist nicht mit vertretbarem Aufwand konstruierbar. Och nö. Das hab ich mir schon gedacht, aber ich wollt's nicht hören. :( Irgendwie ist alles in dem Gebiet von vor 10 Jahren. Geräte gibt's wie Sand am Meer, nichts mehr erhältlich und bei Amazon mit Glück 3 Sterne. Sh*t.
Jens M. schrieb: > Dr. Sommer schrieb: >> Bluetooth > > Ja danke aber nein. > Gab es vor 10 Jahren mal ganz kurz, aktuell nix zu kaufen. Ich denke er wollte zum Ausdruck bringen Bluetooth anstelle von USB (nativ, nicht BT als bloße USB-Verlängerung). Bei der Formulierung der Betreffzeile fällt einem das auch als erste Antwort ein, die Lösung passt halt leider nur nicht zum Kleingedruckten in Deiner Frage.
:
Bearbeitet durch User
Jens M. schrieb: > Schade, aber trotzdem danke. wenn das Geld egal ist, dann 1 Raspbery PI und virtualhere kostet zwar Geld, Hardware und Software, setzt aber alles über lan/wlan um https://www.virtualhere.com/usb_client_software The VirtualHere USB Client runs on Windows, OSX and Linux evtl. brauchst nicht mal hardware? oder muss was an einen drahtlosen USB Port, dann wäre ein PI der kleineste günstigste PC als drahtlose USB Buchse
https://www.silextechnology.com/connectivity-solutions/device-connectivity/ds-520an Das ist ein Device Server. Da klemmst Du Dein Device dran (Kabel). Verbindung zum Rechner geht über WLAN. Auf dem Rechner wird eine Software installiert, die quasi USB-Karte spielt, aber die ganzen Requests auf die externe Hardware weiterreicht. Ist aus USB-Sicht transparent und geht prinzipiell mit allen Geräteklassen, aber das Timing ist natürlich anders und kann Dir in die Suppe spucken. fchk
Joachim B. schrieb: > wenn das Geld egal ist, dann 1 Raspbery PI und virtualhere Das löst das Problem nicht, da VirtualHere auf der PC-Seite einen Treiber voraussetzt, genauso, wie es jeder andere USB-Deviceserver auch macht. Dieser Treiber muss auf dem PC installiert werden, der das hinter dem ganzen Kram hängende USB-Device ansteuern soll. Dieser Treiber stellt die "virtuelle USB-Karte" dar, die fchk gerade erwähnte. -- Davon abgesehen ist die Kombination Raspberry Pi Zero W und virtualhere tatsächlich die kostengünstigste Umsetzung eines USB-Deviceservers, sofern nur ein einzelnes USB-Device damit angesteuert werden soll. Dann nämlich ist virtualhere kostenlos.
Wenn Geld keine Rolle spielt würde ich doch mal experimentieren den traffic zu analysieren. Je nach Form könnte man ja evtl die nutzdaten tunneln. Da wäre die Nennung der Anwendung halt gut
Rufus Τ. F. schrieb: > Das löst das Problem nicht, da VirtualHere auf der PC-Seite einen > Treiber voraussetzt, genauso, wie es jeder andere USB-Deviceserver auch > macht. > > Dieser Treiber muss auf dem PC installiert werden hmmm, es gibt nur verdammt wenig USB Teile ohne Treiber, auf Anhieb fallen mir nur USB Sticks (nicht alle!) und Soundkarten (auch nicht alle) ein. Sonst soweit ich zurückdenke, ausser HID Tastaturen musste ich immer Treiber installieren.
Jens M. schrieb: > Ganz einfach: Ein kabelloses USB-Kabel. Wer Funk kennt, nimmt Kabel. Dazu kommt noch, das gerade da USB-Protokoll recht kompliziert ist. Such Dir einen anderen Übertragungsweg, z.B. WLan.
Der Rufus hat's erkannt: Alle bislang genannten Lösungen haben einen Treiber, der am "PC-Ende" einen virtuellen USB bereitstellt, dazwischen ist ein Tunnel, meist via IP, also LAN oder WLAN, und an dem "Printserver" ist die USB-Buchse. Mal abgesehen das ich die Lösung noch nicht getestet habe und daher nichtmal weiß ob das überhaupt geht (Timing usw.), fällt das alleine dadurch flach, das die Zielanwendung auf einem geschlossenen System läuft, auf dem ich nichts installieren kann. Ich vermute, da ist ein Linux drauf, aber man sieht es nicht. Kiste einschalten, 21..22..23 Zielanwendung. Da kommt kein BIOS, es gibt keinen Port, nichts. Das Gerät gibt's auch für Win, dafür hab ich eine Software und kann es nutzen, somit wäre ein Versuch mit USB over IP möglich. Aber nicht zielführend, da ich im Endeffekt auf das Windows verzichten muss. Der Traffic ließe sich evtl. so monitoren, aber was bringts? Ich kann das Gerät auch nicht ersetzen, da sowohl Master, als auch Gerät und Anwendung so bleiben müssen. Nur das dusselige Kabel muss weg. Eine Bluetooth-Funkstrecke ist damit leider außen vor, da sie ja eine neue Hardware erfordern würde. Für eine USB-Bridge ist das wohl zu lahm schätze ich. So viel kann ich sagen: Das ist eine sehr schlechte Kamera (es ist eine Optik dran und das Testbild ist extrem unscharf/pixelig) und wird zur Positionserkennung genutzt. Rein Hardwaremäßig würde ich sagen es handelt sich um eine optische Maus mit einer großen Optik, zudem wird auch ein Auslöser erkannt, der eine Messung aktiviert. Man sieht also vorher den relativen Verlauf der Position als "Mausspur" und beim Auslösen wird die Position bewertet. Ich kann als "Zielbild" recht frei kontraststarke Muster anlernen und die dann nachher wiederfinden als Ausrichtmarke. Max D. schrieb: > Je nach Form könnte man ja evtl die nutzdaten > tunneln. Bitte gerne. Nur wie? Joachim B. schrieb: > hmmm, es gibt nur verdammt wenig USB Teile ohne Treiber, auf Anhieb > fallen mir nur USB Sticks (nicht alle!) und Soundkarten (auch nicht > alle) ein. > > Sonst soweit ich zurückdenke, ausser HID Tastaturen musste ich immer > Treiber installieren. Die "Kamera" braucht unter Windows auch einen Treiber. Der ist auf der "OEM-Box" wohl schon drauf, aber einen weiteren bekomme ich da nicht rein, mangels Zugang. Selbst wenn hätte ich keine Idee, was da drin ist. Daher ja die Anforderung der transparenten Box-zu-Box. Die muss genau genommen nur teiltransparent sein, wenn sie exakt und nur genau dieses eine Gerät tunneln kann reicht das ja.
Harald W. schrieb: > Wer Funk kennt, nimmt Kabel. Jap. ich weiß. Ich bin auch nicht derjenige der das Kabel loswerden will. :) Harald W. schrieb: > Dazu kommt noch, das gerade da USB-Protokoll recht kompliziert ist. > Such Dir einen anderen Übertragungsweg, z.B. WLan. Sagen wir mal so: Mein Kumpel hat dieses Gerät, das es in dieser Form für ca. 500€ gibt. Es gibt eine WiFi-Version, wo alleine die Kamera 1700€ kostet, die allerdings auch deutlich mehr kann. Die Idee war nun, die technisch ausreichende Kamera für 500€ zu nehmen, das Teil "mit sone Kiste von amazon oder ebay" für 150-200€ zu entkabelisieren und gut. Er denkt, das die Anwender dieses Geräts durchaus zahlreich sind und ein Markt für eine günstige Schnurlosversion für ein paar wenige hundert pro Jahr da wäre. Wenn ich mal optimistisch sage das 100 Geräte zu verkaufen sind (wir kennen alle die Kunden die sagen "klaar, da mach ich tausend im Monat von weg" und dann kommt nach der Nullserie nix mehr) und jedes 100€ umgelegte Entwicklung kostet (Endpreis also 500 für die Kiste, 200 für den Adapter, 100 Entwicklung, macht 800€): Bekommt man sowas für 10000€ entwickelt? Mit einem Funksystem das zumindest in Europa aus dem Karton legal funzt? Eher nicht so, oder?
Das geht physikalisch nicht. Auch die diversen Kabelverlängerungen, die teilweise USB dann über lange Strecken schicken, verwendet Tricks, die einem auf die Füße fallen können. Das USB Protokoll ist nicht dafür vorgesehen getunnelt zu werden. Dafür bräuchte man eine Zeitmaschine, damit man dann noch die Zeitvorgaben einhalten könnte.
Jens M. schrieb: > Ganz einfach: Ein kabelloses USB-Kabel. Gibt's. Nennt sich DeviceServer. Und stellt halt ein USB-Device haarscharf über dem physischen Bitstream über's Netz zur Verfügung. Sowas wird oftmals verwendet, um UNSÄGLICHKEITEN wie Kopierschutzdongles über's Netz verfügbar zu machen. Den ganzen anderen USB-Prassel können die Dinger dann auch. Nur bei isochronen Transfers hapert es (naturgemäß). > Was allerdings sein muss: > - Kein Treiber, da der Ziel"computer" kein großartig verfügbares OS hat, No way. Irgendwas muss die Pakete in's Clientsystem einspeisen. Typisch kann das nur ein Treiber so tun, dass der Client nicht mitbekommt, dass er hier verarscht wird. Und das aben auch nur für nicht-isochrone Transfers. Bei isochronen kann es der Client bemerken...
Jens M. schrieb: > Die "Kamera" braucht unter Windows auch einen Treiber. ich habe nichts anderes geschrieben was darauf hindeutet das eine Cam keinen Treiber braucht, warum zitierts du mich also dazu? Das ist arg mißverständlich
Die FritzBoxen mit usb können dieses übers netzwerk weitergeben. Dort wird ein echter usb anschluss simuliert also laufen alle gerade. https://www.google.com/amp/s/www.heise.de/tipps-tricks/Den-FritzBox-USB-Fernanschluss-richtig-nutzen-4220751.html Alte boxen die das können gibt es ab 5€
c-hater schrieb: > Gibt's. Nennt sich DeviceServer. Nein. Ist es nicht. Lies genauer. Jens M. schrieb: > Alle bislang genannten Lösungen haben einen Treiber, der am "PC-Ende" > einen virtuellen USB bereitstellt, dazwischen ist ein Tunnel, meist via > IP, also LAN oder WLAN, und an dem "Printserver" ist die USB-Buchse. Auch wenn hier der Begriff "Printserver" statt Deviceserver verwendet wird: Das ist der entscheidende Punkt, Hervorhebung von mir.
Joachim B. schrieb: > ich habe nichts anderes geschrieben was darauf hindeutet das eine Cam > keinen Treiber braucht, warum zitierts du mich also dazu? > > Das ist arg mißverständlich Ich fand deine Aussage zu den Treibern missverständlich. Es ging drum das der Fake-USB-Port einen Treiber braucht, zusätzlich zu dem des angeschlossenen Geräts. Wobei letzterer evtl entfallen kann, z.b. wenn ein Gerät eine Standardklasse verwendet. Das Problem ist hier aber der erforderliche Treiber für den wie auch immer getunnelten USB-Port an sich. c-hater schrieb: > No way. Irgendwas muss die Pakete in's Clientsystem einspeisen. Typisch > kann das nur ein Treiber so tun, dass der Client nicht mitbekommt, dass > er hier verarscht wird. Und das aben auch nur für nicht-isochrone > Transfers. Bei isochronen kann es der Client bemerken... Mittlerweile gehe ich davon aus, das es nicht klappt. Trotzdem, und nur zur Klarstellung: Warum kann ein Gerät am PC nicht anhand der physikalischen Verbindung, sondern logisch die Rolle wechseln, und warum kann es nicht so tun als wäre es ein anderes Gerät? NodeMCU's z.B., oder auch Arduinos mit nativem USB können je nach Situation RS232-Ports, HID, Massenspeicher und sonstwas sein, je nachdem welcher Teil der Software gerade läuft. Alles was es zum wechseln braucht ist ein Reset, der Stecker bleibt drin. Die Idee hier ist eben ein Gerät das erstmal schaut, was der Funkpartner sieht, der wiederrum fragt via Enumeration alles ab, sendet es rüber, und das PC-Ende der Funkstrecke plappert einfach nach was es hört. Abgesehen von Timing-Problemen müsste das doch gehen. Wobei ich mich dann frage, warum es WLAN-Deviceserver gibt, da dürfte das Timing dann doch auch eng werden. Ist das so schwer, das PC+Treiber-Dings durch eine Hardwarekiste zu ersetzen, die dann den USB-over-IP-Weg geht?
Jens M. schrieb: > Ich fand deine Aussage zu den Treibern missverständlich. was davon? Joachim B. schrieb: > hmmm, es gibt nur verdammt wenig USB Teile ohne Treiber, auf Anhieb > fallen mir nur USB Sticks (nicht alle!) und Soundkarten (auch nicht > alle) ein. > > Sonst soweit ich zurückdenke, ausser HID Tastaturen musste ich immer > Treiber installieren. Ich habe USB Sticks die installieren einen Treiber und laufen am Netzwerkdrucker nicht, habe auch andere die ganz normal als USB Stick erkannt werden. Ich habe USB Soundkarten die wollen Treiberinstallation, habe auch andere die sofort am win PC und am PI ohne Installation laufen.
Es geht nicht um den Treiber für das USB-Device, das mit dem "schnurlosen Kabel" angesteuert werden soll, sondern es geht um einen zusätzlich nötigen Treiber, um mit einem USB-Deviceserver kommunzieren zu können. Es ist hier wenig hilfreich, auf anderen Treibern herumzureiten. USB-Host X kann USB-Device Y ansteuern, aber USB-Host X kann kein zusätzlicher Treiber verpasst werden, damit es mit USB-Deviceserver Z reden kann, an dem USB-Device Y angeschlossen werden soll. USB-Host X ist kein normaler PC.
Rufus Τ. F. schrieb: > Es geht nicht um den Treiber für das USB-Device das war mir schon klar, offensichtlich nicht jeden oder es wurde aneinander vorbeigeschrieben. Das virtuelle USB Umsetzer am USB Host Treiber brauchen dachte ich ist klar, braucht mein wUSB HAMA (läuft nur am winPC), mein USB Webserver Sharkoon(läuft nur am winPC), würde vermutlich auch der PI mit virtualhere brauchen. Mir ist klar was der TO wünscht, aber unklar wie es gehen soll.
:
Bearbeitet durch User
Ein Ansatz wäre vielleicht zu schauen wie USB in dem Gerät implementiert ist. Wenn zb. ein USB Device Chip eingesetzt ist der an einem Controller per SPI oÄ. angeschlossen ist, könnte man nach dem USB Chip ansetzen und SPI über Funk tunneln. Somit bleibt das USB Device am PC mit dem spezifischen Treiber. Das ist aber wohl alles andere als von der Stange und wahrscheinlich ein unsägliches Gebastel.
Das wäre in der Tat ein Ansatz, den ich auch schon vorgeschlagen habe. Wir zögern bloß, das Gehäuse aufzubrechen, auch wegen Garantie und weil wir nicht wissen ob da nicht was eingestellt/ausgerichtet & verklebt wurde.
Ich weiss nicht wirklich viel über USB, habe aber eine Idee. Linux hat die "Linux-USB Gadget API", mit welchem es als USB Device agieren kann. Diese USB Gadget Treiber sind, wenn ich das richtig verstandenen habe, auch im Userspace umsetzbar. http://www.linux-usb.org/gadget/ USB/IP kann ein USB gerät eines anderen Hosts lokal verfügbar machen. libusb erlaubt es, userspace USB Treiter zu erstellen, btw. von Userspace aus direkt auf diese zuzugreifen. Ich frag mich jetzt, wäre es möglich, ein USB Gadget Userspace Treiber zu schreiben, welches mit libusb auf ein beliebiges USB Device zugreifen kann, und dieses so quasi exportiert? Dann könnte man doch theoretisch einen RPI nehmen, der sich mit dem speziellen selbst geschriebenen USB Gadget als das Zielgerät ausgibt, und dann ganz normal das bereits bestehende USB/IP und nen zweiten RPI verwenden, um das Zielgerät anzubinden, auf das der eigene Gadget Treiber dann zugreift? Also quasi: Ziel USB Host <-> [ RPI 1 (als OTG Device) -> eigener userspace Gadget Treiber -> libusb -> über vhci-hcd bereitgestelltes USB device ] <-> Ethernet/IP <-> [ RPI 2 (als USB Host) -> usbip-host ] -> USB Zielgerät Wäre es rein Theoretisch möglich, solch ein Gadget Treiber zu schreiben?
DPA schrieb: > Ich frag mich jetzt, wäre es möglich, ein USB Gadget Userspace Treiber > zu schreiben, welches mit libusb auf ein beliebiges USB Device zugreifen > kann, und dieses so quasi exportiert? Das geht nur, wenn man sehr genau weiß, was das eigentliche Gerät so treibt, und wenn man das vollständig nachbilden kann.
DPA schrieb: > Ziel USB Host <-> [ RPI 1 (als OTG Device) -> eigener userspace Gadget > Treiber -> libusb -> über vhci-hcd bereitgestelltes USB device ] <-> > Ethernet/IP <-> [ RPI 2 (als USB Host) -> usbip-host ] -> USB Zielgerät Das wäre exakt was wir brauchen. Rufus Τ. F. schrieb: > Das geht nur, wenn man sehr genau weiß, was das eigentliche Gerät so > treibt, und wenn man das vollständig nachbilden kann. Ich bin da unbewandert: warum? Der Deviceserver ist doch "egal", zumindest sehr weitreichend kann der "alles". Außer durch umsetzungs- und Übertragungswegbedingte Geeschwindigkeitseinbußen ist das Ding doch transparent. Oder? angeblich gehen Lizenzsticks (Netzwerkkarte, HID, COM), Speicher, Drucker, Kameras und Serielle Schnittstellen. Ich hab das noch nicht versucht, ein Gerät dazu ist aber im Zulauf. Dann hätte man einen Proof of concept das es zumindest technisch geht, wenn nicht, das weitere Versuche wahrscheinlich sinnlos sind. Jetzt mein Verständnisproblem: Kann der "USB-ausgang" des RPI am PC-Ende nicht alles nachbilden, der Softwaretreiber aber schon? Liegt's an der Hardware, die sich verkleiden muss und nicht kann? Weil wenn das klappt, könnte ich mir vorstellen das "eine Firma" die Software entwickeln darf und wir jemanden finden der das Produkt verkauft.
Beitrag #5794665 wurde vom Autor gelöscht.
Jens M. schrieb: > Ich bin da unbewandert: warum? Um ein halbwegs normales Zeitverhalten u.a. während der Enumeration durch den Host vorzuspielen, müssen alle relevanten und irrelevanten Informationen des Zielgerätes bereits vorhanden sein. Erst mit dem Beginn der Enumeration durch den Host die Enumeration am anderen Ende der Strecke zu starten ist zu langsam. Anders als bei der netzwerk-Deviceserver-Lösung, wo der komplette USB-Host-Controller virtualisiert nachgebildet wird, wo daher ein deutlich entspannteres Timing vorhanden ist, wäre bei einem sich als USB-Gerät ausgebenden "kabellosen USB-Kabel" das Timing hart an den jeweiligen USB-Host gekoppelt. Und das ist viel zu knapp, als daß man Enumeration oder andere Aktionen erst nach "Durchreichen" starten und entsprechend verzögert beantworten könnte. Wenn aber das anzusteuernde Gerät vollständig bekannt ist, dann kann man auf der zum Host zeigenden Seite dieses Gerät vollständig nachbilden. Die tatsächlichen Nutzdaten würde man dann dort einfügen, wo das reale Gerät sie in Hardware erzeugt. Das ist bei Geräten wie CDC oder HID durchaus umsetzbar, aber bei einer Kamera (darum scheint es hier ja zu gehen) halte ich das für nur mit wirklich extremen Aufwand umsetzbar.
Ach so, der VUSB-Treiber ist einfach ein bissel langsamer, weil das OS warten kann, die Hardwaresimulation müsste aber mit dem vom Host vorgegebenen Tempo schritt halten? Schade. Hörte sich so schön an... :(
:
Bearbeitet durch User
Toll wäre eine grobe Einordnung WAS das mysteriöse gerät denn so treibt. Danach kann man drüber Nachdenken die Daten anstatt dem USB zu tunneln. Beispiel Tastatur: Keystrokes von dem Device abnehmen und über eine (sich identisch anmeldende) emulierte Tastatur an den PC geben. Alles was man da tunneln müsste wären Infos der Art "Taste X gedrückt","Taste Y losgelassen". Schwer zu tunneln sind immer zeitkritische Sachen.
Harald W. schrieb: > Wer Funk kennt, nimmt Kabel. Das sag mal den Milliarden von Smartphone Benutzern.
Max D. schrieb: > WAS das mysteriöse gerät denn so treibt. Es ist wohl eine Kamera, wobei sich Jens da auch irgendwie widerspricht: Jens M. schrieb: > Das hier verwendete Gerät wird unter Windows erkannt, ist aber was > eigenes, mit eigener VID, also weder Seriell, Kamera, HID oder Medium. Jens M. schrieb: > Sagen wir mal so: Mein Kumpel hat dieses Gerät, das es in dieser Form > für ca. 500€ gibt. > Es gibt eine WiFi-Version, wo alleine die Kamera 1700€ kostet, die > allerdings auch deutlich mehr kann. > Die Idee war nun, die technisch ausreichende Kamera für 500€ zu nehmen, > das Teil "mit sone Kiste von amazon oder ebay" für 150-200€ zu > entkabelisieren und gut.
Ja, das ist das Problem. Für den Laien ist es eine Kamera, mit einer Optik vorne dran sieht das jedes Kind. Am PC-Ende jedoch steht im Gerätemanager eine Kategorie "XY Sensors" mit dem Gerät "XY Sensor $Lizenztyp" drin. Von dem Ende her kann man das Gerät nicht als Kamera erkennen, noch als irgendwas anderes. (Daher auch die Schlussfolgerung meines Kumpels, das es ja wohl nicht so schwer sein kann das Kabel durch Funk zu ersetzen, sind doch nur 5 Strippen im Stecker. Es sieht halt nach nix aus.) Andere Software kann mit dem Ding nichts anfangen, man muss/kann es nicht auswerfen, es gibt kein Laufwerk oder so. VID/PID ist google unbekannt, weitere Namen sind im Treiber nicht zu finden. Einen losen Treiber gibts auch nicht, man muss das Programm installieren und dann kann Windows auch das Gerät erkennen. Mehr als eine winusb.inf gibt's aber nicht, und die scheint MS-Standard bei Win7 zu sein, daher die Vermuting das es ein HID ist. Erst da im Programm gibt es sich als wirkliche Kamera zu erkennen, obwohl die optische Auflösung sehr grob ist, das Bild ist auch s/w. Die Positionserkennung ist weit feiner als ein pixel, was mich drauf bringt das es sich um eine optische Maus handeln könnte von der Hardware her. Evtl. auch von Magnetometer, Gyroskopen und/oder Accelerometern unterstützt, der Hersteller schweigt sich da aus. Zudem ist ein Mikro an bord, das ein nahes "Klick" auswertet, so das man ohne weitere Verkabelung "ein Foto machen" kann in dem man an der mit der Kamera ausgerüsteten Messvorrichtung den Messpunkt markiert (was man althergebracht eben ohne das System macht, "auf Papier"). Oder das Testbild der Kamerasoftware ist mit anderen Parametern als die normale Anwendung. Glaub ich aber nicht, weil es wirklich schlechte Qualität hat. Das sind aber alles Schlussfolgerungen aus dem Verhalten der Kamera und der Software, was da wirklich vorgeht weiß ich nicht, das ist alles geheim, und weiter will ich das hier nicht wirklich austreten weil da evtl. Patente oder so dranhängen. Wenn ihr Programme wisst, die mir den USB mal etwas besser aufdröseln als der Gerätemanager, bitte her damit. Dann kuck ich da mal rein.
:
Bearbeitet durch User
Jens M. schrieb: > Mehr als eine winusb.inf gibt's aber nicht, und die scheint MS-Standard > bei Win7 zu sein, daher die Vermuting das es ein HID ist. Nein, Winusb ist die Microsoft-Reinterpretation von libusb, das bedeutet, daß nahezu beliebige USB-Geräte ohne spezifische Treiber betrieben werden können -- der Code, der das macht, was normalerweise im Treiber sitzt, befindet sich bei Winusb bzw. libusb in der eigentlichen Applikation, die das Gerät nutzt. > Wenn ihr Programme wisst, die mir den USB mal etwas besser aufdröseln > als der Gerätemanager, bitte her damit. https://www.uwe-sieber.de/usbtreeview.html Das erzählt alles, was das USB-Gerät über sich verrät. Das eigentliche Protokoll aber kann man mit aktuellen Varianten z.B. von Wireshark aufzeichnen. Allerdings ist das ein äußerst steiniger Weg. Warum aber schreibst Du jetzt etwas vom PC-Ende, wo Du doch bisher ausgeschlossen hast, daß zusätzliche Treiber installiert werden können? Wenn das ein normaler PC ist, der winusb nutzt, dann kann man auf dem natürlich auch die Software installieren, die nötig ist, um mit einem USB-Device-Server zu kommunizieren.
Rufus Τ. F. schrieb: > Nein, Winusb ist die Microsoft-Reinterpretation von libusb, das > bedeutet, daß nahezu beliebige USB-Geräte ohne spezifische Treiber > betrieben werden können -- der Code, der das macht, was normalerweise im > Treiber sitzt, befindet sich bei Winusb bzw. libusb in der eigentlichen > Applikation, die das Gerät nutzt. Oh, danke. Dann ist wohl noch "eigener" als angenommen... Rufus Τ. F. schrieb: > Warum aber schreibst Du jetzt etwas vom PC-Ende, wo Du doch bisher > ausgeschlossen hast, daß zusätzliche Treiber installiert werden können? Das bezieht sich auf die Demoversion, die Software gibt's auch für Windows, für zum kucken. Da könnte ich was installieren und mal nachsehen, ist ja mein Laptop. Am Ende muss das aber wieder an die richtige Kiste, die ist eben leider zu. Ich versuch das mit dem Treeview mal. Danke.
Jens M. schrieb: > Am Ende muss das aber wieder an die richtige Kiste, die ist eben leider > zu Dafür hat der Hersteller sicher seine Gründe, und er wird nicht begeistert sein, wenn seine zuverlässige Konstruktion mit USB-Kabel ersetzt wird durch eine störanfällige Funkverbindung - wer steht denn dann dafür gerade? Georg
Jens M. schrieb: > Oh, danke. Dann ist wohl noch "eigener" als angenommen... Naja, eigen würde ich das nicht nennen. Das System ist genial, ein extra Treiber wird nicht benötigt, damit gibts auch keine aufwendige Treiber-Entwicklung und Testerei, signiert ist er auch schon und auf jedem Windows Seit XP SP2 vorhanden. Mittlerweile benutzen den WinUSB Treiber massenhaft Geräte. Wir setzen den auch seit 10 Jahren ein, der hat nie auch nur das geringste Problem verursacht.
georg schrieb: > Dafür hat der Hersteller sicher seine Gründe, und er wird nicht > begeistert sein, wenn seine zuverlässige Konstruktion mit USB-Kabel > ersetzt wird durch eine störanfällige Funkverbindung - wer steht denn > dann dafür gerade? Naja, zuerst mal mein Kumpel, der will das ja mit seinem Eigentum machen. Und im Wunschfall als transparentes "WLAN-kabel" sollte das schlimmstmögliche eine Nichtfunktion sein, die sich mit einem 1,95-Kabel aus dem Baumarkt beheben ließe. Sollte er auf den Trichter kommen den Kram in Serie über eine Firma zu verkaufen, wäre die Garantie auf den Adapter seine, das Restsystem wird ja nicht verändert. Christian R. schrieb: > Naja, eigen würde ich das nicht nennen. Ich meinte mit "eigen" das "Datensystem" der Kamera. Wenn libusb im Spiel ist und die App volle Kontrolle hat, ist das ja nichtmal ein Standard wie COM, Datenträger, Kamera oder HID, sondern wirklich was was nur die originale Anwendung beherrscht. And there goes the simulation. Die Wahrscheinlichkeit das erfolgreich zu tunneln (wie auch immer) geht damit stark runter.
Noch mal: Die Reihenfolge in der die Probleme angegangen werden ist falsch. Als erstes bitte eine Zeitmaschine entwickeln, mit der Signale in der Zeit zurück geschickt werden. Danach dann ein irgendwie geartetes Tunnel-Device mit dieser Zeitmaschine bauen
Ach komm, so schlimm isses nicht. Digitus hat für nicht mal 70€ einen WLAN&LAN-4-Fach-USB-Hub im Programm der angeblich alle Geräte via Netzwerk zur Verfügung stellen kann. Und alle heißt hier nicht "die vier" sondern "es ist egal was du da dransteckst". Das Timingproblem entsteht also wohl nur an der Host-Seite des nicht vorhandenen Kabels, wohl einer der Gründe warum es ein solches System auf dem MArkt nicht gibt. Hersteller und sogar Softwarelösungen für Virtuelle USB-Ports via LAN gibts von 0 bis 1000€. Das USBTreeView hat mich ncht wirklich weitergebracht. Kein Device, kein Child, keine Class außer "USB", den Herstellernamen weiß ich schon. Klassischer Fall von schön wär's gewesen. Als Witz am Rande: Jemand (ich schaue jetzt niemanden an...) hat tatsächlich ein Kabel bestellt, das ein MiniUSB-Ende für die Kamera und ein A-Buchse-ende für einen WLAN-Stick hat. Wohl ein OTG der ersten Stunde. Oder für irgendein Sondergerät? Dazu ein WLAN-Stick aus dem Mediamarkt, sogar mit externer Antenne. Dann den Stick am Laptop mit dem WLAN verbunden, damit der die Daten kennt, rausgezogen und mit dem Kabel der Kamera verbunden. Dann ist ihm eingegangen das die LEDs nicht an sind, denn wo soll der Strom herkommen? Also kurzerhand das Kabel durchgeknipst, die bunten Drähte wieder zusammengetüdelt (immerhin gelötet) und auch ein altes Handynetzteil seiner Schnur beraubt. Da dort zufälligerweise auch rot und schwarz drin waren, hat er die mit drangemacht an das Adapterkabel. Jetzt leuchten die LEDs, aber weder ist die Kamera im WLAN, noch scheint der Stick zu wissen was er machen soll, denn außer Power leuchtet nichts. Das man der Software gar nicht sagen kann wie sie eine Kamera im WLAN benutzen sollte, ist ihm noch gar nicht aufgegangen. Fragende Augen, die meinen Tränen folgen: "Warum tut das nicht?" Manchmal verzweifle ich an den jungen Leuten von heute... Der Junge ist Anfang 20 und ein Playstation/XBOX/PC-zocker von Schnuller auf, wohlhabenden Eltern sei Dank. Achja: Man kann keine ZM entwickeln um damit zurück zu reisen. Du würdest ja an einem Punkt ankommen, an dem sie nicht existiert. Klassisches Paradoxon. Also beschränke ich mich auf die, die hier unter meinem Tisch steht und mich konstant und zuverlässig in der Zeit reisen lässt. Zwar nur vorwärts, und leider auch nur mit 1s/s, aber immerhin: sie war günstig.
my2ct schrieb: >> Wer Funk kennt, nimmt Kabel. > > Das sag mal den Milliarden von Smartphone Benutzern. Ich weiss nur, das die immer jammern, wenn sie mal in eine etwas einsamere Gegend kommen. Das Schnurtelefon funktioniert m.W. auch im kleinsten Dorf.
Harald W. schrieb: > Ich weiss nur, das die immer jammern, wenn sie mal in eine > etwas einsamere Gegend kommen. Das Schnurtelefon funktioniert > m.W. auch im kleinsten Dorf. In Afrika ist es umgekehrt. Aber die sind uns halt auch ein Stück voraus. Mit 5G schaffen wir aber bestimmt den Anschluss an Äthiopien. Georg
my2ct schrieb: > Harald W. schrieb: >> Wer Funk kennt, nimmt Kabel. > > Das sag mal den Milliarden von Smartphone Benutzern. Die bezahlen sich dumm und dämlich für jedes einzelne Gigabyte das schmerzhaft durch den Äther gequetscht werden muss, mit dem Kabel hingegen kann man Daten saugen bis der Arzt kommt ;-)
georg schrieb: > In Afrika ist es umgekehrt. > Aber die sind uns halt auch ein Stück voraus. Der Bedarf an Funktechnologien ist höher, wenn es keine kabelgebundenen Infrastrukturen gibt...
georg schrieb: > Mit 5G schaffen wir aber bestimmt den Anschluss an Äthiopien. Ich dachte, 5G wird nur eingeführt, damit sich zwei nebeneinander stehende Industrieroboter unterhalten können?
5G dient dazu dass der Kunde nochmal schneller sein Datenkontingent rauablasen kann und dann wieder auf Modem-Geschwindigkeit gedrosselt wird.
Jens M. schrieb: > Ach komm, so schlimm isses nicht. > Digitus hat für nicht mal 70€ einen WLAN&LAN-4-Fach-USB-Hub im Programm > der angeblich alle Geräte via Netzwerk zur Verfügung stellen kann. > Und alle heißt hier nicht "die vier" sondern "es ist egal was du da > dransteckst". Das ist ein Remote-Hostcontroller. Dafür braucht man Treiber auf dem Host-System und genau das war ja ausgeschlossen worden. Remote-Hosts funktionieren problemlos, da die USB-Kommunikation ja erst in der Box beginnt, bis zu der die Daten über IP oder anderes laufen. Damit gibt es dann ggf. etwas weniger Datendurchsatz, aber keine Timingprobleme im Protokoll.
Tja, ich hab mit dem Projekt abgeschlossen, weil es exakt das geforderte nicht gibt. Und wohl auch nicht geben kann... Diese Digitus-Kiste habe ich aber trotzdem mal kaufen lassen, um das zu testen, rein aus Spieltrieb. Die "Kamera" ist ja ein Gerät mit "ohne Class", möchte doch mal wissen ob das trotzdem klappt. Ich muss es ja nicht bezahlen ;)
Ist noch nicht da. Mal sehen ob ich diese Woche was rauskriege, dann sind erst Osterferien.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.