Hejka. Posiadam pewną prostą kamerę na USB (uzywana przez stomatologow, do robienia zdjec jamy ustnej). Posiada ona przycisk, dzięki któremu można zrobić zdjęcie pomijając konieczność klikania przycisku w programie pokazującym obraz - ten program nie działa zbyt dobrze (a inne programy nie obsługują tego przycisku) dlatego zabrałem się za stworzenie własnej prostej alternatywy dla tego programu. Użyłem do tego pythona, biblioteki opencv do przechwytywania obrazu z kamery, oraz biblioteki pyusb do komunikacji z tą kamerą. Zainstalowałem też wiresharka oraz drivera do przechwytywania ruchu USB, aby zobaczyć, co właściwie wysyła kamera podczas gdy klikam przycisk do zrobienia zdjecia (żeby obsłużyć w moim programie ten przycisk) Ale tutaj utknąłem. Wiem tylko, że kamera komunikuje się z hostem za pomocą trybu transferu "Isochronous" ale kompletnie nie moge nic z tego wyczytać, żadnych różnic pomiędzy zwykłym transferem obrazu, a kliknięciem przycisku. W jaki sposób mogę obsłużyć to kliknięcie przycisku na kamerze w pythonie za pomocą libusb? Ktoś mnie nakieruje? Dziekuje z góry!
Jesteś pewny, że nie ma innej transmisji po USB w wiresharku niż iso? Ogólnie to tryb iso był przeznaczony głównie do obsługi streamingu. Poszukaj może czy nie ma tam jakichś transmisji do endpointów kontrolnych albo Bulk albo Interrupt w momencie kliknięcia przycisku w tej aplikacji, którą chcesz zastąpić - a nie przycisku na samej kamerce
vtx napisał(a):
Jesteś pewny, że nie ma innej transmisji po USB w wiresharku niż iso? Ogólnie to tryb iso był przeznaczony głównie do obsługi streamingu. Poszukaj może czy nie ma tam jakichś transmisji do endpointów kontrolnych albo Bulk albo Interrupt w momencie kliknięcia przycisku w tej aplikacji, którą chcesz zastąpić - a nie przycisku na samej kamerce
W wireshark jest coś o adresacji 3.6.1 - wysyła ona dane w trybie isochronous - czyli ten streaming obrazu z kamerki. Żadnych innych danych ten adres nie wysyła. Zaś inne adresacje wysyłają bulki, interrupt, i inne takie mniej zrozumiałe dla mnie rzeczy - zaznaczam, że w opcjach przehchwytywania zaznaczyłem tylko i wyłącznie kamerke, czemu na tym interfejsie są różne adresacje? Nie jestem w stanie zauważyć żadnych szczególnych pakietów gdy klikam przycisk w programie
kutek napisał(a):
vtx napisał(a):
Jesteś pewny, że nie ma innej transmisji po USB w wiresharku niż iso? Ogólnie to tryb iso był przeznaczony głównie do obsługi streamingu. Poszukaj może czy nie ma tam jakichś transmisji do endpointów kontrolnych albo Bulk albo Interrupt w momencie kliknięcia przycisku w tej aplikacji, którą chcesz zastąpić - a nie przycisku na samej kamerce
W wireshark jest coś o adresacji 3.6.1 - wysyła ona dane w trybie isochronous - czyli ten streaming obrazu z kamerki. Żadnych innych danych ten adres nie wysyła. Zaś inne adresacje wysyłają bulki, interrupt, i inne takie mniej zrozumiałe dla mnie rzeczy - zaznaczam, że w opcjach przehchwytywania zaznaczyłem tylko i wyłącznie kamerke, czemu na tym interfejsie są różne adresacje? Nie jestem w stanie zauważyć żadnych szczególnych pakietów gdy klikam przycisk w programie
Jeśli chodzi o adresację 3.6.1 to jest to z tego co pamiętam adresacja pokazywana użytkownikowi z poziomu kernela. Samo USB w adresacji urządzeń używa numerów 0-127 o ile dobrze pamiętam. Czyli jest wysoce prawdopodobne, że ten adres 3.6.1 da się jakoś przełożyć na adresację stosowaną w USB. Mogłoby to być np. adr_urzadzenia/interfejs/endpoint. Sorki ale nie pamiętam wszystkich szczegółów.
Odnośnie samej komunikacji - na chwilę obecną zostawiłbym tę transmisje iso i skupił się na pozostałych transmisjach - bo piszesz, żę są takie. Nie wiem dokładnie z jakiego poziomu wireshark pokazuje dane dotyczące transmisji USB ale może się przydać znajomość deskryptorów stosowanych w USB. Na tę chwilę skupiłbym się na deskryptorze urządzenia i tam poszukał endpointów kontrolnych, interrupt bądź bulk - i spróbował filtrować transmisję dla każdego z nich osobno w wiresharku. Mówiąc inaczej - odfiltruj iso całkowicie i analizuj po kolei pozostałe typy transmisji podczas naciskania przycisku w aplikacji.
I jak tam? Udało się rozpoznać metodę kontrolowania tej kamerki? Wiadomo coś więcej o szczegółach komunikacji?
Pytam bo ciekaw jestem jak deweloperzy to rozwiązali.
Jak będzie coś więcej wiadomo - daj znać, pochwal się :)
znajac projektantów elektroniki to robią jak jest im wygodniej, programista potem sobe poradzi i jakoś "złapie dane" ;)
W strumieniu danych isoc mogą być zaszyte dane kontrolne w postaci paru bajtów, obraz jest generowany caly czas wiec można tam umieścić przycisk , ale nie zaszkodziło by tak jak sugeruje @vtx sprawdzić wszystkie endpointy.
Do sprawdzenia:
- zgrać dane z zasłonięta kamerą , potem może jakieś obrazy kontrolne i porównanie danych może to podpowie jak zbudowany jest protokół
- dobrą metodą jest tez wyswietlenie danych RAW na ekranie w postaci BMP gdzie można sobie zmieniać szerokosc,wysokosc, ilość bitów
Adamek Adam napisał(a):
znajac projektantów elektroniki to robią jak jest im wygodniej, programista potem sobe poradzi i jakoś "złapie dane" ;)
Potwierdzam :)
W strumieniu danych isoc mogą być zaszyte dane kontrolne w postaci paru bajtów, obraz jest generowany caly czas wiec można tam umieścić przycisk , ale nie zaszkodziło by tak jak sugeruje @vtx sprawdzić wszystkie endpointy.
Jako, że iso unikałem do tej pory jak ognia a nie chce mi się teraz szukać - to mam pytanko odnośnie endpointów iso: czy te endpointy iso są dwukierunkowe?
Też myślałem o tym, że kamerka w strumieniu iso może przemycić eventa od naciśnięcia przycisku. Ale to komunikacja w kierunku device do hosta.
Ale @kutek pisał o tym, że chce z poziomu jakiejś aplikacji sterować kamerką - więc tutaj masz komunikację w drugą stronę: host -> device. Stąd moje pytanie o dwukierunkowość endpointów iso :)
Wydawało mi się, że tylko kontrolne endpointy mogą być dwukierunkowe...
Do sprawdzenia:
zgrać dane z zasłonięta kamerą , potem może jakieś obrazy kontrolne i porównanie danych może to podpowie jak zbudowany jest protokół dobrą metodą jest tez wyswietlenie danych RAW na ekranie w postaci BMP gdzie można sobie zmieniać szerokosc,wysokosc, ilość bitów
Po chwili zastanowienia stwierdzam, że dobrze nawet kombinujesz :)
Kamerka może też cały czas wysyłać strumień wideo i w ogóle nie oczekiwać interakcji ze strony hosta - czyli nie czeka na naciśnięcie klawisza w aplikacji. Tylko sama aplikacja w momencie naciśnięcia przycisku w tej aplikacji robi sobie screenshota z tego strumienia, który do niej przychodzi - a nie wysyła żadnego żądania do kamerki.
Ale z drugiej strony takie ciągłe pchanie danych iso po USB byłoby wielkim marnotrawieniem zasobów.
Wszystko zależy co tam sobie deweloperzy wymyślili :)
Ja nie dostrzegłem komunikacji w obie strony w opisie OP
Każdy endpoint ma tylko jeden kierunek , w oprogramowaniu mogą być ustawienia do kamery ale wszystko to może być postprocesing
Adamek Adam napisał(a):
Ja nie dostrzegłem komunikacji w obie strony w opisie OP
Ok, założyłem, że kamerka robi zdjęcie na żądanie i tylko w sytuacji użycia fizycznego przycisku na kamerce albo kliknięcia przycisku w aplikacji przesyła dane o obrazie. W tym drugim przypadku chyba musi być jakaś interakcja: aplikacja => host => kamerka.
Każdy endpoint ma tylko jeden kierunek , w oprogramowaniu mogą być ustawienia do kamery ale wszystko to może być postprocesing
Poszukałem w specyfikacji i tylko kontrolne ep mogą być dwukierunkowe. Defaultowo kontrolny ep0 jest dwukierunkowy.