FLI camera

From CCDSH
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
  • A Schmidtben ki lett cserélve a kamera egy FLI-re, a fókuszok megváltoztak: 19.42-52-62, source /usr/local/ccdsh/scripts/load-camfilt-proline.ccdsh kell (...-apogee.ccdsh helyett proline)
  • Szoftveres és/vagy hardveres gliccsek: ezek joreszet mar javitottam azota, igy barmiefele "szoftveres és/vagy hardveres gliccs" az a nem normalis mukodesnek a jele. Persze a vis maior jelleguek (pl energenie-manage --camera off egy expozicio kozben) nem tartoznak ide. Normalis hasznalat eseten (beleertve a ctrl+c-s megszakitast is!) nem igazan szabad elofordulnia semminek. Ha elofordul, legyszi szoljatok mihamarabb.
  • Ennek a kameranak ket readout mode-ja van: az egyik esetben eleg gyorsan (8Mhz-s mintavetelezesel, 4-5 masodperc alatt) kiolvassa a kepet, a masik esetben meg a "szokasos" apogee-s sebesseg van (1Mhz, 20 masodperces kiolvasas). Az alapertelmezett ezutobbi, ez a fits headerbe is bekerul (RO_MODE, ami egy string, ami vagy '8 MHz' vagy '1 MHz' lehet). A gyorsabb kiolvasasnak az a hatranya hogy a kep az zajosabb lehet, illetve a ket readout mode-ot nem illik keverni a kalibracio soran (azaz az egyikkel felvett bias/dark/flat az nem lesz jo a masik readout mode-dal keszult kephez). Alapertelmezesben a sztenderd 20 masodperces, kis zaju readout mode jon fel, de figyeljetek arra hogy tenyleg mindig ez jojjon fel. Ha alapbol a gyors kiolvasassal indulna a kamera, akkor az a fenti "szoftveres és/vagy hardveres gliccs" kategoriaba tartozik.
  • Az effektiv gain erteken meg dolgozunk, az most 1.8 - 2 korul van (a korabbi 1 helyett). Emiatt van ez hogy mar latszolag 47k ADU korul szaturalodik a kamera, ellenben vsz megmarad a toltes viszonylag jo hatekonysaggal, nincs integer overflow miatti adatvesztes. Persze a kalibracio nehezebb lesz, es a fotonzaj-becslesnes is figyelembe kell venni ezt a nem-egysegnyi gaint.
  • A kamera beszerelesenek sajatossagai miatt a kep el van fordulva 90 es/vagy 270 fokkal (polus-keresztezodes fuggvenyeben, lasd meg: LSD-szinu abra), viszont cserebe legalabb tukrozve nincs. Azon el lehet filozofalni hogy ez igy jo-e nekunk vagy legyen-e valami szoftveres emulacio hogy ugyanugy alljon a kep mint ahogy eddig. Ha megszavazza a köz hogy legyen normalis allasban a kep, akkor csinalok valamit az ügy erdekeben. Ezt mihamarabb dontsetek el legyszi hogy csak relative rovid idoszakaszt erintsen. Nekem szemely szerint igy is jo lenne de az en vagyok :]
  • A fits headerekbe bekerult egy DATE_DRV es egy DATE_CAM keyword. Ennek a tartalma egy datum. Amennyiben barmi olyan jellegu valtozas tortenik a driverben es/vagy kameraban, ami miatt a korabbi kalibracios kepek nem hasznalhatoak akkor ezek a keyword-ok valtozni fognak (jellemzoen a valtozas bevezetesenek a datuma lesz ez). Masszavakkal, az elozoeket (is) ossze- es belefoglalva: ha bias/dark/flat kepeket keresunk a meresunkhoz, akkor figyeljetek arra, hogy a DATE_DRV, DATE_CAM, RO_MODE es a CCDTEMP keyword-ok _mindegyike_ megegyezzen a tudomanyos es a kalibracios kepeknel is.