USB2.0 i 480 Mbit/s, går det så fort?

[stoffe]

Bearing, inte databladet isig, däremot en flyer (man måste tydligen registrera sig för att få mer info om kameran)
Nåväl, ZWO's hemsida säger att det är en:

Specification:

Sensor: 1/3" CMOS AR0130CS(Color) / MT9M034(mono)

Dvs kameran är egentligen en är en MT9M034 från Aptina om jag fattat saken rätt.

Stämmer helt rätt, QHY5L-II har exakt samma sensor, dock så har ZWO kameran lite bättre mjukvarustöd och intern värmeavledningsförmåga sägs det. Därför valde jag den istället.

Mao för optimistisk bönräknar USB2 får man 32 fps. Medan det är mer realistiskt att förvänta sig runt 27 fps (400 Mbit/s).

Uppenbarligen så funkar kameran med 35 fps med en av mina datorer och många andra oxå, 32 fps är nära.

Här är en som plockat isär kameran med avsikt att kyla bildsensorn direkt:
http://stargazerslounge.com/topic/18719 ... e-cooling/

(hittade rejäl jämförelselista med andra modeller)

Mer data som säger att 1280x960 @ 35 fps är max. Fast det ger 516 Mbit/s som är mer än USB2 någonsin lär klara.

Info om den magiska 6-pol RJ kontakten.

Kanske lämpligt objekt för en modifiering till Ethernet. 1000 Mbit/s är något häftigare än USB2..

Den magiska 6-pol RJ kontakten är en ST4 port för guidning och är ett måste vid långa exponeringstider vid astrofotografering.

Att modda kameran till ett annat interface övergår mitt förstånd men däremot så kommer det en USB3.0 variant senare i år sägs det.

I listan du postade så finns det en sån där blå TIS kamera med Firewireanslutning som jag ratat. Dock med 21 sensors istället för 618, de har även andra problem som t ex lökringar i bilderna.

Jag som äger denna ASI120MM kamera kan ju försöka luska reda på vad den kör för eventuell codec med oförstörande komprimering, hur gör jag det i så fall?
Jag kan säga att detta är en helt otrolig kamera som jag är jättenöjd med, CMOS tekniken går framåt och med sina 75% peak qe så är den mycket känslig, dock så kunde man förväntat sig lite mer känslighet i rött och speciellt infrarött.

[blueint]

Trodde det bara vart CCD som dök när det gällde skarpa användningsområden.

Kodningen kan du börja med att kolla med t.ex "lsusb -v" (på Linux) och kika efter saker som
"bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED)"
"bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)"

Andra parametrar att kika på:
bDescriptorSubtype
bColorPrimaries
bTransferCharacteristics
bMatrixCoefficients

Annars får du programmera en bit kod som konfigurerar kameran och sedan kopplar upp sig mot en USB ändpunkt. Kan vara rätt intressant och användbart. Om du får till det så hittar man oftast formatet vid konfigurationen. Annars syns det oftast i videoströmmen.

[bearing]

I Windows finns snoopypro och liknande för att sniffa USB-överföringen. Har för mig att det också fanns något av Microsoft själva, men jag minns inte vad det hette. Man kunde se alla möjliga "events" i Windows med det programmet, samt filtrera vilka events som skulle synas/loggas.

[stoffe]

Jag var helt inne på att skaffa en CCD först men denna CMOS kamera var så mycket bättre på praktiskt taget allt så jag slog till på den. Jag hittade ingen CCD kamera som var bättre.

lsusb -v gav följande resultat för min kamera. Transfer Type Bulk står det, ingenting om någon codec eller så. Kan det vara så att beräkningen för hur maximal hastighet över USB2.0 bussen är beräknad på en färgkamera? En monokrom kamera har en lägre hastighet på dataströmmen. Det ser ut som att färgversionen av ASI120 kameran endast har 8 bitar per färgkanal, min kamera har 12 bitar. Dessutom så tror jag att färgkameran dessutom skickar dataströmmen odebayerad så där sparar man en hel del datatrafik oxå.

Kod: Markera allt

  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x03c3 
  idProduct          0x120a 
  bcdDevice            0.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
Couldn't open device, some information will be missing
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              5 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0

[stoffe]

En hel radda låghastighets enheter kan ställa till det. En annan aspekt som är värt att reflektera över är operativsystemet..

Windows 7 64-bit är den bästa Windows version som jag testat, jag hade gärna fortsatt med 64-bit Linux, dels så finns det inga drivrutiner för ASI120MM kameran för Linux, sen så kan jag inte styra min systemkamera samtidigt från samma program (vilket jag oxå måste kunna göra). Sen saknar Linux ASCOM stöd totalt, det finns något som kanske kommer att ersätta det i framtiden som heter INDI men det är långt ifrån färdigt på långa vägar.

Sätter man alla låghastighets enheter på en egen "host" med ett eget "rotnav" så ska det inte behöva bli några problem om jag kör kameran på en egen "host".

[bearing]

En monokrom kamera har en lägre hastighet på dataströmmen. Det ser ut som att färgversionen av ASI120 kameran endast har 8 bitar per färgkanal, min kamera har 12 bitar. Dessutom så tror jag att färgkameran dessutom skickar dataströmmen odebayerad så där sparar man en hel del datatrafik oxå.

Om färgkameran skickar 8-bit rått (utan debayering) borde ju monokrom 12-bit ha 50% högre hastighet på dataströmmen vid samma FPS och upplösning. Men det kanske var det du menade?

Om datan är komprimerad kanske skillnaderna minskar, eftersom att det borde vara enklare att komprimera en rå monokrom bild än rått bayermönster.

Borde vara ganska enkelt att grovt testa ifall datan är komprimerad. Med linsskyddet på (svart bild) borde datamängden minska jämfört med om det finns en tydlig bild samt mycket gryn.

[blueint]

@stoffe, Kikat på GPhoto och liknande ..?
Med USB räcker det med att stödja USB-video klassen så fungerar i stort sett alla videokameror.

USB dumpen ser ut som någon annan enhet. Prova "lsusb -v".

[stoffe]

En monokrom kamera har en lägre hastighet på dataströmmen. Det ser ut som att färgversionen av ASI120 kameran endast har 8 bitar per färgkanal, min kamera har 12 bitar. Dessutom så tror jag att färgkameran dessutom skickar dataströmmen odebayerad så där sparar man en hel del datatrafik oxå.

Om färgkameran skickar 8-bit rått (utan debayering) borde ju monokrom 12-bit ha 50% högre hastighet på dataströmmen vid samma FPS och upplösning. Men det kanske var det du menade?

Nej, det gjorde jag inte. Den totala datamängden från en färgkamera blir 8 bitar per kanal, dvs totalt 24 bitar vilket är dubbelt så mycket som 12 bitar då jag bara har en färgkanal

Blueint - jag har tittat på GPhoto, det finns inget som slår Maxim DL som jag kör och som jag skrivet tidigare, inget annat OS än Windows har ASCOM stöd. Jag blir ju av med möjligheter som att kunna köra fokuserare, filterhjul, teleskop, systemkamera och inte ens min ASI120MM kamera funkar under Linux så det är totalt uteslutet. Dessutom så brukar färgbalanser och annat bli knas pga av tredjepartsdrivrutiner. GHopto har ju inte stöd för speciellt mycket alls dessutom, det går ju inte ens att göra en plate solve eller nånting just annat än att trigga kameran i max 30 sekunder på en DSLR, det har ju inte ens stöd för bulb kabel via usb för långa exponeringar. Dessutom kör jag oxå andra program som FireCapture som kräver att jag har Windows. Windows 7 64 bit är ett bra och stabilt OS med stort programstöd, du kanske tänker på WinXP? Det var inte alls lika bra på många punkter, t ex minneshantering, stabilitet osv. Nu är vi lite ifrån ämnet dessutom tycker jag.

[Nerre]

För Linux verkar det vara Indi som gäller, men det kanske inte är så utvecklat?

http://www.indilib.org/

[stoffe]

Nä precis, det är inte så utvecklat ännu. Som jag skrev i senaste inlägget så saknas fortfarande bra program för att styra kamera, fokuserare osv. V-kurva med autofokus osv. Automatisering av fotosessioner med automatiska filterbyten, exponeringstider och gå till olika objekt på himlen + autoguidning har jag inte ens sett något som fungerar tillfredställande. Men den dag då allt finns för Linux så kommer jag att överväga att köra det, jag känner mig hemma i Linuxmiljö. Tyvärr så saknas mycket programvara även för bildbehandlingssidan, det enda vettiga jag hittat för Linux är PixInsight.

[Nerre]

Det brukar vara så för grejer till Linux att rätt vad det är exploderar utvecklingen och det rasslar fram grejer. Det brukar handla om att det krävs en viss "kritisk massa" av användare för att tillräckligt många ska vara intresserade av utvecklingen. Och sen kanske nåt företag tröttnar på att betala licens till andra och lägger lite resurser på utvecklingen.

SVT har ju t.ex. tagit fram Open Source programvara för TV-produktion som är rätt kompetent (de använder den ju själva). För DTP fanns i princip ingenting förut, men Scribus har varit riktigt användbar de senaste åren.

[stoffe]

@stoffe, Kikat på GPhoto och liknande ..?
Med USB räcker det med att stödja USB-video klassen så fungerar i stort sett alla videokameror.

USB dumpen ser ut som någon annan enhet. Prova "lsusb -v".

Jo så är det, jag tror säkert att ZWO blir glada om du hjälper dom att utveckla en drivrutin. Så även jag

Det är den enda enhet som ser tillräckligt lik ut och enda enheten som har rätt storlek på paketen.

wMaxPacketSize 0x0400 1x 1024 bytes

Jag tror säkert att Linux kommer att få ordentligt många användare framöver men dojjan klämmer kring dåligt mjukvarustöd. Jag är inte jätteförtjust i Wine då det ofta blir onödigt krångel hit och dit för att få allt att funka, sen kommer en uppdatering till nånting i systemet och sen så funkar inget. Ofta pga av beroendekonflikter, två olika program vill ha två olika versioner av ett bibliotek som ej går att ha två versioner samtidigt installerade suck. Jag gillar Linux, sitter vid en Linux burk nu och skriver.

När det kommer stöd för vanliga massan med bra fotoprogram som t ex Lightroom och Photoshop så tror jag att Linux kommer få många fler användare ganska snabbt.

Jag bifogar allt som fanns med när jag skrev "lsusb -v | tee test"

[Nerre]

Den främsta orsaken till att det saknas mjukvarustöd i Linux är ju att de som skriver programmen bara skriver dem för Windows.

Program som ursprungligen skrivs för Linux är oftast Open Source och idag blir de väldigt fort portade till Windows (framförallt om de är skrivna mot t.ex. Qt).

[bearing]

Nej, det gjorde jag inte. Den totala datamängden från en färgkamera blir 8 bitar per kanal, dvs totalt 24 bitar vilket är dubbelt så mycket som 12 bitar då jag bara har en färgkanal

Jag menade att om det du misstänker stämmer, att datan skickas som sitt råa bayermönster, skickas ju bara 8 eller 12 bitar per pixel. Det är först i datorn som datan tredubblas, efter att datorn kört debayeralgoritmen.

Det jag snappat upp om astrofotografi är att det nästan är en förutsättning att arbeta med råa bilder, eftersom att resultatet blir så mycket bättre om debayeralgoritmen är optimerad för stjärnhimlen, jämfört med om det är en allmän algoritm.

Anledningen till att jag kan en del om det här ämnet är att jag försökte göra en egen videokamera med hjälp av en 2.5" Aptina-sensor och en FPGA, för några år sedan. Jag hade tänkt att spara datan från sensorn helt rått och okomprimerat i en array av 12 SD-kort, för att få tillräcklig hastighet (och storlek). SD-korten skulle spara en bit per pixel, synkront. Men det var ett lite väl ambitiöst projekt för mig, så det blev aldrig klart. Strax därefter kom D90:n ut, vilken jag köpte och använde tills hela kameraväskan blev stulen under en utlandssemester.

Om din monokroma kamera inte komprimerar med LZF eller liknande, kan det vara så att kameran mappar 12 bitar i 10 eller eller mindre. Med 10-bit blir hastigheten 430MBps, ifall Blueint hade räknat rätt med 517MBps (som jag minns siffran) tidigare. Råfiler till systemkameror brukar vara både mappade till färre bitar, samt komprimerade med LZF eller liknande. Så filerna är egentligen inte helt råa, eftersom att en liten mängd information försvinner vid mappningen. Men eftersom att man vid mappningen sparar "de viktiga bitarna", är det en ytterst liten förlust i bildkvalitet och "redigeringsförmåga".