Długość kabla, a jakość zdjęć z sesji

RMK · 23 Listopada 2020

5 minut temu, lkosz napisał:

Pytanie było o stratę na jakości, więc prześledźmy to od początku.

[....]

Przepraszam, że nie cytuję całości ale dobrze to opisałeś. Dodałbym jeszcze tylko jeden problem na wyższych warstwach pomijany przez nieświadomych użytkowników.

Załóżmy, że ustawimy sobie klatki co 15 minut bo niebo i sprzęt na to pozwalają, czas usypiania USB na 10 minut i aktywne odłączanie nieużywanych urządzeń na USB w zarządzaniu energią na PC. Zapewne każdy dopowie sobie jaki będzie skutek

♥ Jan Bielański · 23 Listopada 2020

3 godziny temu, sullifan napisał:

Hej

Czy orientujecie się czy długi kabel USB może mieć wpływ na jakość zbieranego materiału podczas sesji.

Pytam bo mam zwykły tani kabel 10m (niby aktywny), który mimo wszystko działa podczas sesji (wydaje się że ok). Jednak zastanawiam sie czy może powodować jakies zakłócenia, wiekszy szum, słabszy detal na zdjeciach itp?

Czy ewentualnie w tym wypadku lepszym rozwiązaniem byłoby zastosowanie zapisu na karcie aparatu, zamiast na PC i stackowanie dopiero materiału z karty?

Co o tym myslicie?

Nie tylko długość kabla ma znaczenie, ale również jego wykonanie. Ja stosuje (podobnie jak Tayson) 3m kable firmy Lindy ze względu na:

wykonanie z wysokiej jakości miedzi beztlenowej 99,96% - gwarantuje to lepszy przepływ prądu i żywotność (tlenek miedzi gorzej przewodzi prąd, niższej jakości miedź może zawierać tlen i kabel będzie się szybciej tracił swoje właściwości)
podwójne ekranowanie - chroni przed zakłóceniami z zewnątrz, a o źródło takich nie trudno np. znajdujący się obok zasilacz, kabel doprowadzający prąd, wszelkie źródła fal elektromagnetycznych (sieci wifi, komórki itd.)
pozłacane styki - poprawia transmisję sygnału

Takie kable tanie nie są: 3m USB 3.0 - około 130zł. Ale dobre okablowanie ma duże znaczenie: testowałem z moją kamerą QHY600 najtańszy kabel USB 3.0 o ile w ciepły pomieszczeniu jeszcze jako tako sobie radził to gdy zacząłem go używać w warunkach polowych to wręcz dochodziło do zrywania połączenia z kamerą. Co do dłużysz kabli niż 3m nie testowałem, ponieważ nie znalazłem nic o podobnych parametrach. Uważałbym też na tanie kable z aliexpress są one tanie bo są do d...: miedź niskiej jakości, dodatkowo bardzo cienka, itd.

lkosz · 23 Listopada 2020

4 minuty temu, RMK napisał:

Załóżmy, że ustawimy sobie klatki co 15 minut bo niebo i sprzęt na to pozwalają, czas usypiania USB na 10 minut i aktywne odłączanie nieużywanych urządzeń na USB w zarządzaniu energią na PC. Zapewne każdy dopowie sobie jaki będzie skutek

dlatego mówię - obserwujcie z miasta. Tam nie ma takich problemów z USB

w linuksowym kernelu można to wyłączyć przez "usbcore autosuspend=-1"

MateuszW · 24 Listopada 2020

No dobra, jak już jesteśmy w temacie niezawodności transmisji, to ktoś umie powiedzieć, co tu się wydarzyło?

image-20201123173308.jpg.062b81ab27389e328dddb5c5e1a5495e.jpg

Tego typu klatki pojawiają się raz na kilkanaście / kilkadziesiąt długich klatek. Wygląda to jakby zgubił się jakiś bajt czy dwa i w efekcie wszystko się rozjechało. Czy to może być błędna klatka, uszkodzona podczas transmisji, ale jakimś cudem zaakceptowana przez komputer, zamiast zrobienia retransmisji?

szuu · 24 Listopada 2020

16 minut temu, MateuszW napisał:

Czy to może być błędna klatka, uszkodzona podczas transmisji, ale jakimś cudem zaakceptowana przez komputer, zamiast zrobienia retransmisji?

biorąc pod uwagę że miliony ludzi codziennie przesyła miliony plików przez usb a uszkadzają się tylko klatki z astrokamery, zaryzykowałbym twierdzenie że to kamera jest badziewnie zrobiona a nie że transmisja usb przepuszcza błędy

lkosz · 24 Listopada 2020

2 godziny temu, Jan Bielański napisał:

wykonanie z wysokiej jakości miedzi beztlenowej 99,96% - gwarantuje to lepszy przepływ prądu i żywotność (tlenek miedzi gorzej przewodzi prąd, niższej jakości miedź może zawierać tlen i kabel będzie się szybciej tracił swoje właściwości)

podwójne ekranowanie - chroni przed zakłóceniami z zewnątrz, a o źródło takich nie trudno np. znajdujący się obok zasilacz, kabel doprowadzający prąd, wszelkie źródła fal elektromagnetycznych (sieci wifi, komórki itd.)

pozłacane styki - poprawia transmisję sygnału

spójrzmy na to z elektronicznego punktu widzenia... OFC ma niewiele większą przewodność elektryczną od zwykłej miedzi. Jest to chwyt marketingowy niestety, który mocno się rozpropagował w świecie audio, potem poszedł dalej. Układy WCZ buduje się z powodzeniem na zwykłych miedzianych drutach nawojowych, bo reaktancja czy indukcyjność są o wiele silniejsze od rezystancji przewodnika, i to nimi się człowiek martwi. Aluminium lub miedź odpowiedniej grubości będzie ok, po przewodach sygnałowych i tak nie płyną duże prądy, dużo większe znaczenie ma dobre wykonanie kabla. Linia zasilająca to zwykły przewodnik prądu stałego. Wystarczy odpowiedni przekrój, żeby nie było dużych spadków napięć.

Podwójne ekranowanie... Transmisja różnicowa i klasyczny ekran redukują wspomniane w poście zakłócenia. Pozostałe szumy szczątkowe, o ile się wzajemnie nie wygaszą, to są tak niewielkie, że szkoda sobie nimi zaprzątać głowę, a tzw. przydźwięk sieciowy nie ma żadnego znaczenia w tym przypadku.

Jedyne na co warto wydać pieniądz, to porządna wtyczka i przewód wykonany zgodnie z parametrami, równo. Bez oszczędzania na grubości żył. Nie musi to być kablowy De Niro, średnia półka cenowa zadowoli amatora, który trzyma sprzęt w warunkach domowych.

Ciągła wilgoć, pokrycie styków brudem i nieprzewodzącymi związkami, śniedzią, pył, wahania temperatury, szarpanie za wtyczkę, wyginanie jej, pogarszają sprawę.

36 minut temu, MateuszW napisał:

No dobra, jak już jesteśmy w temacie niezawodności transmisji, to ktoś umie powiedzieć, co tu się wydarzyło?

podobne problemy miewałem na raspberry i problemach z zasileniem, sprawdź logi systemowe czy urządzenie nie było resetowane, redukowana prędkość połączenia, jakieś timeouty

---------

jakby ktoś był zainteresowany, to poleceniem lsusb -v sprawdzimy parametry pracy urządzenia, i moja ASI120MC pracuje w trybie bulk

Bus 002 Device 002: ID 03c3:120e ZWO ASI120MC-S
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x03c3 
  idProduct          0x120e 
  bcdDevice            0.00
  iManufacturer           1 ZWO
  iProduct                2 ASI120MC-S
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x001f
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              400mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0016
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      HIRD Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   3
      Lowest fully-functional device speed is SuperSpeed (5Gbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        2047 micro seconds
Device Status:     0x000c
  (Bus Powered)
  U1 Enabled
  U2 Enabled

Edytowane 24 Listopada 2020 przez lkosz

MateuszW · 24 Listopada 2020

11 minut temu, lkosz napisał:

podobne problemy miewałem na raspberry i problemach z zasileniem, sprawdź logi systemowe czy urządzenie nie było resetowane, redukowana prędkość połączenia, jakieś timeouty

Tutaj jest właśnie raspberry... Zasilacz 2,5A, a sama kamera jest podpięta 50 cm kablem, którego nikt nie dotyka. Dzięki, sprawdzę logi.

20 minut temu, szuu napisał:

biorąc pod uwagę że miliony ludzi codziennie przesyła miliony plików przez usb a uszkadzają się tylko klatki z astrokamery, zaryzykowałbym twierdzenie że to kamera jest badziewnie zrobiona a nie że transmisja usb przepuszcza błędy

Błędy są naturalną rzeczą w USB. Chodzi o to, jak nimi zarządzamy. Pytanie, która warstwa zajmuje się retransmisją i czy ta powyżej systemu, dostępna dla aplikacji ma na to wpływ. Jeśli ma, to może to być kwestia badziewnego softu astro. Oczywiście badziewność kamery również jest prawdopodobna, przy czym trudno mi sobie wyobrazić takie losowe zachowanie się wskutek jakiegoś błędu w kodzie kamery.

24 Listopada 2020

Transmisja cyfrowa jest wrażliwa na przesunięcia fazowe sygnału i odbicia w linii transmisji. Kumulacja tych błędów może- przy słabej regeneracji sygnału na wejściu - powodować takie efekty jak pokazał Mateusz. Zaawansowane rozwiązania przy wykryciu błędu synchronizacji wstawiają klatkę sąsiednią.

Piotr4d · 24 Listopada 2020

Mój przypadek.

Ten sam laptop, kamera, hub USB, gniazdo USB3.0 w laptopie, zasilacz setupu. Jedyna różnica to Win7 64bit i Win7 32bit. Wszystkie sterowniki urządzeń zainstalowane, a jednak nie mogę zmusić ASI 1600mmc do pracy w USB3.0. Na Win7 32bit wypracowałem schemat działania polegający na odszukaniu 5s od momentu włączenia zasilania i po tym czasie podpisałem przewód USB do laptopa. Skuteczność tego zabiegu na poziomie 90% pozwała uruchomić kamerę z USB3.0.

Na Win7 64bit żaden zabieg nie skutkuje. Kombinacje z kablami, hubem, sterownikami, zasilaniem czy gniazdem w laptopie nie działają.

Bądź tu mądry.

24 Listopada 2020

No popatrz... moja kamera STL11000 ma osiem lat, zacząłem na WIN 2000, potem 7, potem 7 pro teraz 10 i dalej działa bez żadnych kombinacji. Może to wina kamery???

Edytowane 24 Listopada 2020 przez wessel

Piotr4d · 24 Listopada 2020

Im bardziej wysublimowana maszyneria, tym większe pole dla komplikacji.

RMK · 24 Listopada 2020

20 godzin temu, MateuszW napisał:

No dobra, jak już jesteśmy w temacie niezawodności transmisji, to ktoś umie powiedzieć, co tu się wydarzyło?

[...]

Tego typu klatki pojawiają się raz na kilkanaście / kilkadziesiąt długich klatek. Wygląda to jakby zgubił się jakiś bajt czy dwa i w efekcie wszystko się rozjechało. Czy to może być błędna klatka, uszkodzona podczas transmisji, ale jakimś cudem zaakceptowana przez komputer, zamiast zrobienia retransmisji?

Błąd bufora. Po stronie nadajnika lub odbiornika. Można zdiagnozować przepuszczając przez pośrednika programowego (możesz szukać podobnych narzędzi jak np. Debugging USB protocol - USB testing software - Debug USB device (eltima.com)) lub sprzętowego ale to zabawa czasochłonna a i tak nic pewnie na to nie poradzisz. Prawdopodobnie bufor kołowy transmisji jest źle obsługiwany. Jeśli jest to po stronie odbiornika to możesz liczyć na ewentualną poprawę w którejś wersji sterownika.

EDYTA - jeśli tak masz w każdej aplikacji. Bo może być problem w oprogramowaniu, które wyświetla klatki z bufora.

Edytowane 24 Listopada 2020 przez RMK

MateuszW · 24 Listopada 2020

Godzinę temu, RMK napisał:

EDYTA - jeśli tak masz w każdej aplikacji. Bo może być problem w oprogramowaniu, które wyświetla klatki z bufora.

A w której warstwie jest ten bufor? To generalnie działa na sterowniku ZWO, więc soft powinien być względnie godny zaufania...

A odczytem zajmuje się soft do allsky, konkretnie w tym pliku jest odczyt: https://github.com/thomasjacquin/allsky/blob/master/capture.cpp Wszystko sprowadza się do wywołania funkcji ASIGetVideoData, więc nie widać tu miejsca na błąd.

diver · 25 Listopada 2020

Ja niedawno kupiłem taki 5m pasywny kabel USB3: https://www.conrad.pl/p/kabel-usb-30-delock-82759-1x-zlacze-meskie-usb-30-a-1x-zlacze-meskie-usb-30-b-500-m-649864

Bez zastrzeżeń.

Natomiast próba podłączenia mojej kamery przez https://www.morele.net/kabel-usb-unitek-wzmacniacz-sygnalu-usb-3-0-5m-y-3015-432233/

skończyła się kompletnym fiaskiem.

RMK · 25 Listopada 2020

Mateusz,

upraszczając w każdej kamerze działającej przez port szeregowy wygląda to w dużym uproszczeniu tak:

1. matryca->procesor obrazu->układ interfejsu ... kabel ... układ interfejsu i tu nie wnikając, że i tak ktoś napisał kawałek kodu umieszczony w kamerze jako firmware to można założyć, że proces realizowany jest sprzętowo. Tu jest bufor nadawczy po stronie kamery bo informacje o prostokątnym obrazie trzeba przesłać szeregowo oznaczając początek i koniec obrazu i wysłać do bufora odbiorczego w komputerze.

2. Teraz programowo trzeba to gdzieś zmagazynować i wykorzystać

2a. Sterownik ma swój własny bufor i przechowuje odebrane dane udostępniając np. via API dostęp do nich

2b. Sterownik bezpośrednio oddaje odebrane dane do bufora aplikacji.

W przypadku 2a trzeba wiedzieć co siedzi w API - tu też może być błąd

W przypadku 2a i 2b za ewentualne błędne wykorzystanie tego, co poprawnie doszło odpowiada funkcja w aplikacji.

Zerknąłem tylko na kilka sekund na kod i samo poprawne użycie funkcji API nie stanowi odpowiedzi...

Ponieważ jesteś i sprzętowcem i programistą to domyślasz się, że błąd może być w:

- firmware kamery obsługującej bufor nadawczy

- oprogramowaniu sterownika obsługującego odbiór transmisji szeregowej

- funkcjach API

- kodzie aplikacji.

Jeśli dobrze są oprogramowane procedury transmisji przez producenta w API, to nie ma prawa przy błędnej transmisji pojawić się znacznik, że przyszła nowa kompletna ramka obrazu. To, co oglądasz to ewidentne złożenie dwóch kawałków bufora. Odpowiedź na pytanie nie jest prosta więc zasugerowałem najprostsze rozwiązanie - sprawdzić jak kamera działa z inną aplikacją z identycznymi parametrami (które jak widać w kodzie są ustawiane).

Gdy ja mam problemy z transmisją z kamer w systemach, które buduję to w skrajnym przypadku dokonuję akwizycji wszystkiego, co przychodzi do bufora. Najgorszą opcją jest wykazanie producentowi, że ma błąd w firmware kamery - tu już sięgam bo narzędzia do analizy transmisji USB. W dwóch przypadkach na przestrzeni kilkunastu lat się udało, co nawet poprawiono w kolejnych edycjach firmware ale dotyczy to kamer przemysłowych.

RMK · 25 Listopada 2020

@MateuszW

Jeszcze jedno spostrzeżenie - to przypadek, że masz jeden fragment w innych odcieniach? Jeśli jest to powtarzalne to jest jeszcze ciekawiej... na fragmencie transmitowanego bufora masz inaczej ustawiony format danych Wtedy możesz faktycznie mieć znacznik, że ramka obrazu doszła kompletna ale nie zgadza się format na części transmisji... Pytanie, który chochlik to zmienia ?

MateuszW · 25 Listopada 2020

13 minut temu, RMK napisał:

@MateuszW

Jeszcze jedno spostrzeżenie - to przypadek, że masz jeden fragment w innych odcieniach? Jeśli jest to powtarzalne to jest jeszcze ciekawiej... na fragmencie transmitowanego bufora masz inaczej ustawiony format danych Wtedy możesz faktycznie mieć znacznik, że ramka obrazu doszła kompletna ale nie zgadza się format na części transmisji... Pytanie, który chochlik to zmienia ?

Tak, wygląda to zawsze podobnie, obraz jest podzielony na 3 części, a zmieniają się ich proporcje i kolory. Zmiana kolorów to ewidentnie kwestia pomylenia ze sobą składowych RGB - czyli w skopanym fragmencie zaczyna traktować np R jako B itp. Chodzi o sygnał przed debayeryzacją (bo taki jest przesyłany) Może to wynikać ze zgubienia jednego piksela o danym kolorze i w efekcie traktowania kolejnych w zły sposób. Ale może całkiem brakuje tu jakiegoś koloru? Sam nie wiem.

Ale też istotne jest to, że zepsute części obrazu na dole to nie kontynuacja góry, tylko jest to na nowo obraz od pierwszej linii - czyli kamera wysłała najpierw poprawnie kawałek, coś się potem zepsuło i nastąpiła retransmisja, ale nowe dane zostały albo pomylone, albo zawierały błąd, który został zignorowany.

Edytowane 25 Listopada 2020 przez MateuszW

RMK · 25 Listopada 2020

Zrzuć odbierane bufory do plików - następnie edytor HEX i do dzieła. Ułatwieniem będzie statyczny obraz przed kamerą. Skopaną ramkę znajdziesz szybko przez porównanie plików. Po analizie dowiesz się czy to bit, bajt ;), czy jeszcze więcej zmian..

Edytowane 25 Listopada 2020 przez RMK