Liebes Forum,
ich habe aus einem alten Thinkpad die integrierte Kamera aus dem Deckel
ausgebaut. Der Controller ist von Vimicro und angeschlossen war sie an
einem 5-poligen Stecker (siehe Bilder). Die Rückseite der Platine zeigt
die Belegung des Steckers. Offensichtlich USB.
Die Kamera wird jetzt über einen TS11178 mit 3.3 V versorgt, DM(D-) und
DP(D+) sind entsprechend angeschlossen und beide Ground-Leitungen liegen
auf GND.
Wie in den Screenshots zu erkennen, liefert dmesg unter Linux das
korrekte Resultat, allerdings ist sie nicht einsetzbar/nutzbar. Unter
Windows gibt es die entsprechenden Fehlermeldungen (siehe Anhang).
Vorher hatte ich durch Suche der Hersteller- und Geräte-ID zumindest bei
Lenovo ein Treiberpaket gefunden, das Windows aber nicht zuordnen kann.
Hat jemand so ein Teil schon mal extern zum Laufen gebracht?
P.S.: Sicherlich ist die Versorgung mit 3.3 V aber Anschluss von D+ und
D- an einen 5V-Anschluss nicht ganz sauber, aber immerhin liefert das
Gerät Daten.
Gruß
Jiri
Die Meldung "not running at top speed, connect to a high speed hub"
kommt mir etwas verdächtig vor. Habe die zumindest noch nie gesehen.
Evtl sind die Leitungen der D+/D- nicht gut genug, oder zu lang, o.ä.?
(Gedanke dahinter: womöglich geschieht der initiale Verbindungsaufbau
bei geringer Geschwindigkeit und funktioniert noch, aber bei full-speed
treten dann zu viele Fehler auf)
Ist die Kamera über einen Hub angeschlossen oder direkt am Host?
Mathias A. schrieb:> Die Meldung "not running at top speed, connect to a high speed hub"> kommt mir etwas verdächtig vor. Habe die zumindest noch nie gesehen.
Bedeutet das Gerät braucht ein schnelleren Port. Habe ich erst 2 x
gehabt.
Unter Windows kommt es schon mal vor, das Windows ein Gerät nur als USB
1.* einbucht. Dann kommt die sinngemäß die Meldung "Dieser Gerät kann an
ein schnelleren Port schneller sein"
Ich vermute dein Gerät wird nicht als USB-2.0 anerkannt, sondern als USB
1.x .
Gruß
Pucki
Mathias A. schrieb:> Evtl sind die Leitungen der D+/D- nicht gut genug, oder zu lang, o.ä.?> (Gedanke dahinter: womöglich geschieht der initiale Verbindungsaufbau> bei geringer Geschwindigkeit und funktioniert noch, aber bei full-speed> treten dann zu viele Fehler auf)>> Ist die Kamera über einen Hub angeschlossen oder direkt am Host?
Die Kamera ist direkt an den Host angeschlossen (USB 3).
Allerdings leuchtet mir die Leitungs-Geschichte ein. Das Modul ist auf
dem Steckbrett befestigt und der Schirm vom (recht langen) USB-Kabel ist
nicht aufgelegt.
Ich versuche mal, die Verbindungsqualität zu verbessern.
Frage: kann es auch sein, der schwache 3.3-V-Sendepegel am 5-V-Empfänger
die Sache noch verschlimmert?
Jiri schrieb:> Frage: kann es auch sein, der schwache 3.3-V-Sendepegel am 5-V-Empfänger> die Sache noch verschlimmert?
Wovon redest Du? USB arbeitet mit 3.3V, nur die (optionale) Versorgung
durch den Host passiert mit 5V.
Hmmm schrieb:> Wovon redest Du? USB arbeitet mit 3.3V, nur die (optionale) Versorgung> durch den Host passiert mit 5V.
Und wieso wird dann der Pin immer mit 5 Volt angegeben.
https://www.reichelt.de/reicheltpedia/index.php/USB#USB-PIN-Zuordnung
Der einzige der da eine Ausnahme machen KANN, ist USB-C. Da darf man
mehr.
Gruß
Pucki
Jiri schrieb:> Sicherlich ist die Versorgung mit 3.3 V aber Anschluss von D+ und> D- an einen 5V-Anschluss nicht ganz sauber, aber immerhin liefert das> Gerät Daten.
Vermutlich aber nicht lange.
Mit den 5V grillt man Chips die nur für 3,3V entwickeklt wurden.
Außerdem sind dann die Busspannungen flasch, denn USB läuft trotz 5V
VBus mit 3,3V Signalen an D+ und D-. Kann also sein das Windows sich
beschwert weil die Kamera mittlererweile defekt ist.
Nebenbei. Ich hoffe du hast die Kamera an ein AKTIVEN (mit Netzteil) Hub
laufen.
Ich kenne nämlich einige Geräte die Probleme an passiven Hubs haben,
bzw. bei direkt Anschluss. Der Grund ist, das Mainboards oft 2
Schnittstellen an den selben Hub geben. Und dann verhungern die Teile.
Das Gegenteil gibt es auch. ;) Festplatten mit 2 USB-Anschlüssen, damit
die mehr Saft bekommen.
Gruß
Pucki
Alexander K. schrieb:> Hmmm schrieb:>> Wovon redest Du? USB arbeitet mit 3.3V, nur die (optionale) Versorgung>> durch den Host passiert mit 5V.>> Und wieso wird dann der Pin immer mit 5 Volt angegeben.
Weil das der Pin für die erwähnte Versorgung ist, während die
Datenleitungen mit 3.3V arbeiten.
Seine Sorge ist, dass die 3.3V-Logikpegel der Kamera für den
vermeintlichen "5V-Anschluss" nicht ausreichen würden.
Jiri schrieb:> P.S.: Sicherlich ist die Versorgung mit 3.3 V aber Anschluss von D+ und> D- an einen 5V-Anschluss nicht ganz sauber, aber immerhin liefert das> Gerät Daten.
Danke schon mal für die Antworten.
Ja, D(+) und D(-) haben 3.3 V. Wie schnell doch die Versorgungsspannung
zu Fehlannahmen verleitet.
Ich habe jetzt den Anschluss des Moduls weiter optimiert. Kurzes Kabel
mit Schirm, einziges Gerät am internen Hub, Spannungsversorgung (wie
schon vorher) über 3.3-V-Regler. Damit kann ein 5V-Schaden ja
ausgeschlossen werden.
Mir scheint das Problem inzwischen beim Treiber zu liegen.
Im Anhang die dmesg-Ausgabe. Die interne Kamera wird als UVC-Gerät
richtig erkannt. Das angebastelte Modul kommuniziert ja offensichtlich,
Linux bindet es aber nicht als UVC-gerät ein.
Der Rechner, aus dem es ausgebaut wurde, lief nie mit Linux. Deshab
lässt sich nicht sagen, ob das Teil da überhaupt mit Linux
funktionierte. Mit Windows schon.
Unter Windows können diese internen Teile ja in irgendeinem propriäteren
Treiber-Blob integriert sein.
Jiri schrieb:> Im Anhang die dmesg-Ausgabe. Die interne Kamera wird als UVC-Gerät> richtig erkannt. Das angebastelte Modul kommuniziert ja offensichtlich,> Linux bindet es aber nicht als UVC-gerät ein.
Was meinst du damit, im Screenshot wird das device doch aufgelistet?
Ist der User, der die braucht, in der gruppe video? (id befehl zum
nachsehen)
Welche Berechtigungen sind auf /dev/video0 und /dev/video1? (mit "ls -l
/dev/video*" nachsehen)
Versuch mal, die in vlc zu öffnen:
https://medium.com/@petehouston/use-vlc-to-play-camera-with-different-formats-17cf839b72d0
Jiri schrieb:> Ich habe jetzt den Anschluss des Moduls weiter optimiert. Kurzes Kabel> mit Schirm, einziges Gerät am internen Hub, Spannungsversorgung (wie> schon vorher) über 3.3-V-Regler. Damit kann ein 5V-Schaden ja> ausgeschlossen werden.>> Mir scheint das Problem inzwischen beim Treiber zu liegen.
Ok, denke auch dass die Hardware nun nicht mehr das Problem ist. War es
vielleicht auch nie, aber immerhin ist es nun ziemlich ausgeschlossen.
Die Warnung bzgl speed kommt vermutlich immer noch oder? (Nur
interessehalber, glaube wie gesagt jetzt nicht mehr dass das ein Problem
darstellt)
Treiber wäre jetzt auch mein nächster Verdacht, eine konkrete Idee was
es sein könnte hab ich allerdings nicht. Würde es allerdings auch
erstmal unter Linux probieren, falls es da einen Treiber gibt der den in
der Kamera verbauten Chip kennt, sollte es dann mit einiger
Wahrscheinlichkeit klappen. Bei Windows hatte ich öfter die Erfahrung
gemacht, dass Treiber vom Gerätehersteller kommen und dann nur mit
Geräten von dem Hersteller funktionieren, auch wenn letztlich der Chip
im Gerät der selbe ist...
Jiri schrieb:> ich habe aus einem alten Thinkpad die integrierte Kamera aus dem Deckel
Ja, ja, das namenlose Thinkpad!
DPA schrieb:>> Im Anhang die dmesg-Ausgabe. Die interne Kamera wird als UVC-Gerät>> richtig erkannt. Das angebastelte Modul kommuniziert ja offensichtlich,>> Linux bindet es aber nicht als UVC-gerät ein.>> Was meinst du damit, im Screenshot wird das device doch aufgelistet?
Klar, der Salamitaktiker präsentiert ja auch zwei verschiedene Kameras,
siehe IDs. Der zweite Screenshot wird wohl die interne Kamera des
Rechners sein, an dem er die ausgebaute Kamera des namenlosen Thinkpad
testet. Das wird mal wieder der typische Wurschtel-Murks-Thread, der
sich dann im Nichts verläuft.
M.M.M schrieb:> Der zweite Screenshot wird wohl die interne Kamera des> Rechners sein, an dem er die ausgebaute Kamera des namenlosen Thinkpad> testet.
Klar. Natürlich hängt das Teil an einem Rechner zum testen. Das
Testgerät (Vaio) hat auch eine Kamera, die auch funktioniert und als
video0 und video1 eingebunden ist.
Das ist ja auch deswegen gut zu wissen, da es also am grundsätzlichen
Framework nicht liegt.
Hätte ich mehr Infos zum Thinkpad, stünden die hier. Leider stammt die
Kamera aus einem abgerissenen Deckel aus der Elektroschrottkiste, wo
Thinkpad auf dem Klebeetikett stand.
Kleiner Exkurs, warum ich das eigentlich mache:
Wie die meisten gemerkt haben, sind Webcams momentan preislich sehr
unattraktiv. Und alles, was als Modul billig zu bekommen ist, hat auch
eine eher mäßige Qualität. Diese Deckel-Dinger sind eigentlich ganz OK.
Und der Recyclinghof ist eigentlich eine unerschöpfliche Quelle dafür.
Bist du dir sicher, dass D+ und D- richtig angeschlossen sind?
Ich habe letzte Woche auch ein Cameramodul eines Laptops an eine
USB-Strippe gehangen und hatte zuerst die gleiche Fehlermeldung wie bei
dir, bis ich D+ und D- getauscht habe.
Jetzt läuft sie einwandfrei
jobi schrieb:> Bist du dir sicher, dass D+ und D- richtig angeschlossen sind?
Das ist ein sehzr nützlicher Hinweis. Würde nämlich auch den
Geschwindigkeits-"Fallback" erklaren. LowSpeed und FullSpeed-Geräte
unterscheiden sich nämlich u.a. darin, an welcher der beiden Strippen
der Idle-Widerstand des Device appliziert wird.
jobi schrieb:> Bist du dir sicher, dass D+ und D- richtig angeschlossen sind?> Ich habe letzte Woche auch ein Cameramodul eines Laptops an eine> USB-Strippe gehangen und hatte zuerst die gleiche Fehlermeldung wie bei> dir, bis ich D+ und D- getauscht habe.> Jetzt läuft sie einwandfrei
Ja, D+ und D- sind richtig. Ich habe die beiden Leitungen testweise
vertauscht, leider ohne Erfolg. Auf die Art wird auch die Geräte- und
Hersteller-ID nicht mehr übertragen.
Wäre eine einfache Lösung gewesen.
Jiri schrieb:> Ja, D+ und D- sind richtig.
Wie sieht denn Deine Verkabelung der Datenleitungen aus?
Full Speed (12Mbps) ist recht anspruchslos, bei Hi-Speed (480Mbps)
sollte die schon vernünftig aussehen.
