Hjælp til fotometri forklaring og tidssynkroniseri

Fora SEKTIONER I ASTRONOMISK SELSKAB Sektionen for småplanetokkultationer Hjælp til fotometri forklaring og tidssynkroniseri

  • Dette emne har 31 svar og 6 stemmer, og blev senest opdateret for 8 år siden af nightsky. This post has been viewed 3229 times
Viser 15 indlæg - 16 til 30 (af 32 i alt)
  • Forfatter
    Indlæg
  • #124347

    nightsky
    Deltager
    • Neutron star

    Jeg tror der er ved at styr på formlen nu.

    Jeg mangler dog et program/metode til at beregne IFFaverage
    Det er jo sum af værdien på samtlige pixels divideret med antal pixels. Maxim ser ikke ud til
    at kunne beregne dette, medmindre man bruger Information vinduet, sætter mode til Area
    og marker et felt der fylder hele billedet.

    Hvis jeg kender den værdi er det nemt at lave billede med netop denne værdi på alle pixels.

    Så tilbage står jeg med problemet med præcis tidskalibrering. Hvis det var video kan indskyde
    et GPS video signal og problemet var løst, men med en CCD er det straks mere problematisk.

    Mit Basler kamera med 618 chippen kan faktisk gøre dette. Man kan synkronisere et on-board
    ur på kameraet som indsætter tiden straks efter a-d konverteringen med et ubetydeligt tidstab.
    Problemet med planetkamera som Basler er at der støj og den ikke er kølet.

    Findes der tidssignaler man kan aflytte med en almindelig radio?

    Nightsky2014-11-12 22:30:34

    #124350

    Lars Malmgren
    Deltager
    • Super Nova

    Nightsky wrote:

    Jeg mangler dog et program/metode til at beregne IFFaverage

    Det er jeg ret sikker på at IRIS kan.
    http://www.astrosurf.com/buil/us/iris/iris.htm

    Nightsky wrote:

    Så tilbage står jeg med problemet med præcis tidskalibrering. Hvis det var video kan indskyde
    et GPS video signal og problemet var løst, men med en CCD er det straks mere problematisk.

    Hvilken form for optagelse taler vi om?
    Planetary? Eller lidt længere eksponering?

    Jeg vil tro, at alle programmer der kan optage og gemme i FITS skriver et tidsstempel i FITS headeren.
    Det tages jo fra pc’ens ur, så hvis det er synkroniseret mha GPS signal, så må det vel være ret præcist…

    #124351

    Lars Malmgren
    Deltager
    • Super Nova

    Optager du i AVI, så plejer man at tage middeltiden mellem første og sidste frame.
    FireCapture sætter nogle tidsstempler og den kan lave en txt-fil ved siden af AVI’en, som indeholder en del date.
    Jeg mener at kunne huske, at middeltiden for optagelsen også bliver registreret der…

    #124356

    nightsky
    Deltager
    • Neutron star

    Hej Lars

    Det bliver ikke med firecapture, men et andet program f.eks. Maxim.

    Problemet med GPS tiden er at jeg ikke kender latency – Den tid der går fra GPS modulet
    har sendt tiden via seriel (USB) til pc’en og pc clocken er opdateret.

    Næste problem er at jeg ved hvor tid der går fra shutter lukker og kameraet udlæser til
    programmet har modtaget billedet og stemplet tiden. Dette kan dog beregnes ved noget
    avanceret driftskan, f.eks. winscan.

    Lige nu går jeg efter en DFC 77 modtager der kan aflevere et output ved sekund og minut,
    eller kan aflevere et dekodet signal til f.eks. en Arduino.

    Hvis jeg kan få det til at virke kan jeg lave et blink på minuttet før og efter begivenheden
    som tydeligt se på kameraet optagelser.

    Jeg har fundet sådan et modul, men kan ikke lige se hvorledes signal decodes

    – update åååhhh, 60 pulser (1 hvert sek) pr. signal. Det kan vist ikke være nemmere. Så er det bare at
    sætte en Arduino til at lave et signal som kan opfanges af kameraet.

    http://www.pvelectronics.co.uk/index.php?main_page=product_info&cPath=9&products_id=8

    update #2: Så er der bestilt et par moduler + nogle neon lamper. Med lidt held er det klar i
    weekenden så det kan testes mandag morgen når Io og Europa mødes. Nu mangler jeg
    bare klart vejr.

    Nightsky2014-11-12 23:53:45

    #124357

    mhansen
    Deltager
    • Nova

    Hej Lars,

    Jeg ved at IRAF kan. Der er to metoder. imstatistics og imexamine. Dog skal man holde sig for øje at metoden til at få en mean/mode værdi for hele framen (imstat) ikke nødvendigvis er det bedste. Er der store gradienter over flatframen, hotpixels eller lign. så vil man få et tal som kan være offset fra den bedste værdi. Ofte vil man derfor tage forskellige målinger på relativt ensartede mindre områder på framen (imexamine) og bruge en ca. middelværdi af disse.

    Den bedste måde at teste det på er ved at tage sin nye normaliserede frame og så lave imexamine igen. Hvis man får værdier ~1, så er det fint nok. Det må dog helt ikke være voldsomt større eller mindre end 1. Helst 1-1.3 og helst ikke < 1.

    Hvis du sender mig din masterflatframe på mail, kan jeg sagtens give dig en mean og mode værdi. Så kan du selv vælge hvilken du vil benytte.

    MHansen2014-11-13 00:07:02

    #124358

    nightsky
    Deltager
    • Neutron star

    Hej Morten

    Det lyder som en god ide med at vælge et område som er repræsentativt for det område som
    jeg vil måle på. Specielt da jeg alligevel skal bruge “Region of Interest” for at få nok hastighed
    på download fra kameraet.

    Mange tak for de gode input, hvis du så lige kan klare noget godt vejr 🙂

    #124359

    Lars Malmgren
    Deltager
    • Super Nova

    Maxim stempler helt sikkert tiden i FITS headeren.

    Men hvorfor besværet med at beregne latency i kameraets lukker og udlæsning?
    Det er nok et par 100-ede millisekunder, men vil være ens for hver frame.
    Og har du synkroniseret PC’ens ur, så er dens drift og i samme størrelse over 1 time.
    Der findes vel software, så løbende kan synkronisere uret, evt via signal på en COM-port fra GPS !?
    Feks. hvert minut. Så er det vel præcist inden for ca. 0,01 sek. (gæt)

    Jeg har fuld forståelse, at du prøver at minimere alle unøjagtigheder!
    Men giver det mening? Jeg mener for at kunne bruge en tids-nøjagtighed på 0,05 sek, så skal du have samme eller bedre “tids-opløsning” i dine billeder.
    Med det mener jeg, at månen skal på ca 0,05 sek have flyttet sig så meget, at du med sikkerhed kan se det på dit billede + oven i købet være sikker på, at positionsændringen ikke skyldes en seeing-effekt.

    Altså din instrument-forstørrelse skal være så stor, at på de ca 0,05 sek flytter månen sig 1-2 pixels.
    Det tror jeg ikke er tilfældet. Måske tager jeg fejl Embarrassed

    Men du kan jo beregne dit instrument + kamera opløsning i buesek og sammenligne det med månens egenhastighed også i buesek.
    Ved at dividere disse får du en tid, som kan kaldes dit setups “tidsopløsning”.

    Dit urs nøjagtighed skal være bedre end denne tidsopløsning.
    Hvor meget??? Tjaaa….

    #124360

    Lars Malmgren
    Deltager
    • Super Nova

    I øvrigt mener jeg, at tidsstemplingen i FITS headeren repræsenterer tidspunktet hvor eksponeringen STARTES.

    Dermed mener jeg det er helt uinteressant hvor længe kameraet er om at udlæse billedet og downloaded det til PC’en.
    Eksponerer chippen mens der udlæses, så er den ikke super egnet til formålet.
    Men den ekstra eksponeringstid må kunne antages til at være for 2 på hinanden følgende frames F1 og F2: F2_tidstempel – (F1_tidstempel + F1_eksponeringstid)

    #124361

    nightsky
    Deltager
    • Neutron star

    Hej Lars

    Jeg skal vide kende middeltiden pr. frame bedre end 1/10 sek. i forhold til UTC, så optagelserne
    kan bruges og sammenholdes med andre optagelser.

    Lidt efter hvilket kamera jeg bruger er der et tidsforbrug fra shutteren er lukket til softwaren
    stempler PC’ens tid på filen. Basler planetkameraet er lynhurtigt til dette, da den arbejder
    via en dedikeret Gb Ethernet forbindelse. Det er straks være med f.eks. TIS 618 som bruger
    USB selv om det også går hurtigt. Helt galt går det med rigtige astro kameraer, da udlæsningstiden
    er “sløv” for at holde støjen nede.

    Giver det mening med høj nøjagtighed. Jo fordi det er fotometri, er det ligegyldigt med teleskopets
    opløsningsevne. Jo bedre tidsangivelse, jo bedre en observation.

    Note that the satellite Io, for example, has a velocity of 17.2 km/s, so that an accuracy of 0.1 second
    of time corresponds to an accuracy of 1.7 km in space. Since the internal accuracy of the theory
    of motion of the satellites is around one kilometer, anyone may understand that an accuracy
    better than 0.1 second of time is necessary.

    Hvis jeg skal lave astrometri skal brændvidden være større end 10 meter, der skal bruges
    et rødt eller IR filter for at minimere diffraktionen i atmosfære og observationen skal foregå
    relativt højt på himlen. Derfor har jeg droppet at prøve dette til andet end pæne billeder.

    Nightsky2014-11-13 00:39:58

    #124369

    swr
    • Giant

    Hej Lars

    Nightsky wrote: Jeg tror der er ved at styr på formlen nu.Jeg mangler dog et program/metode til at beregne <font face=”Times New Roman, Times, serif” size=”3″><span style=”font-size: 12pt; line-height: 115%;” lang=”FR”>I</span><span style=”font-size: 12pt; line-height: 115%;” lang=”FR”>FFaverage</span>Det er jo sum af værdien på samtlige pixels divideret med antal pixels.

    Kan du ikke bare bruge en konstant som f.eks. 50% af maksimalværdien hvis du har belyst flats med ca. 50%? Er det ikke blot en skalering af hvor lyst billedet skal være?

    Man hiver og slider jo efterfølgende en del i billedet alligevel, og skal blot sikre at der ikke går information tabt som afrundingsfejl.

    Mvh Søren

    #124370

    swr
    • Giant

    Hej Lars

    Nightsky wrote: Problemet med GPS tiden er at jeg ikke kender latency – Den tid der går fra GPS modulet har sendt tiden via seriel (USB) til pc’en og pc clocken er opdateret. Næste problem er at jeg ved hvor tid der går fra shutter lukker og kameraet udlæser til programmet har modtaget billedet og stemplet tiden. Dette kan dog beregnes ved noget avanceret driftskan, f.eks. winscan.

    Kunne man ikke teste opstillingen på et kendt objekt for at finde forsinkelsen? Den umiddelbare tanke jeg får er at måle hvornår et antal velkendte stjerner forsvinder bag månen, og bruge gennemsnittet af de målinger til at kalibrere tidsforskydningen med.

    På den måde burde man kunne bruge observationer og positionsbestemmelser fra de store dyre og velkalibrerede observatorier til at kalibrere sit eget udstyr. Ujævnheder på månens siluet kunne enten midles væk ved et større antal observationer eller beregnes med hvis de er kortlagt. Lyder det helt tosset, og er sådanne data tilgængelige?

    Mvh Søren

    #124391

    nightsky
    Deltager
    • Neutron star

    SWR wrote: Kan du ikke bare bruge en konstant som f.eks. 50% af maksimalværdien hvis du
    har belyst flats med ca. 50%? Er det ikke blot en skalering af hvor lyst billedet skal være?
    Man hiver og slider jo efterfølgende en del i billedet alligevel, og skal blot sikre at der ikke går
    information tabt som afrundingsfejl.
    Mvh Søren

    Nej, jeg skal oveholde de anbefalinger som der kommet. Desuden skal der IKKE hives og
    slides efterfølgende, da det skal bruges til meget præcise flux målinger.

    SWR wrote: Kunne man ikke teste opstillingen på et kendt objekt for at finde forsinkelsen?
    ………………………………..
    Mvh Søren

    Jo det kan man faktisk og det var faktisk en af de metoder flere brugte tilbage i 2009. Man
    behøver ikke at kende en stjerne position nøjagtigt for at gøre dette. Der viste sig at
    problemer bagefter, da det er meget svært at finde computer urets offset i forhold til UTC, og
    dermed få kalibreret pc uret helt præcist. Nogle har siden valgt en løsning hvor de køber et
    præcist ur som typisk bruges til at holde super præcis tid på netværk. (Vi har selv en her i
    huset, men den kan jeg jo af gode årsager ikke låne)

    Efter hukommelsen: Hvis man kender kender DEC, den præcise brændvidde og den præcise
    pixel størrelse, kan man via noget avanceret drifts skan beregne latency. Der er et program
    som bliver brugt til dette kaldet winscan.

    Nightsky2014-11-13 16:25:59

    #124745

    nightsky
    Deltager
    • Neutron star

    Har nu fået målt mig frem til hvilke frame-rates jeg kan forvente af mit kamera. Det er godt
    nok helt andre hastigheder (lavere) end med et planet kamera.

    Nogle realistiske sub frame størrelser er blevet brugt. Som man ser betyder antallet af
    koloner(Y) på CCD’en relativt meget for udlæsningshastigheden, hvorimod rækker(x) påvirker
    udlæsningshastigheden ganske lidt.

    Desuden ses det også at X,Y koordinatet for sub-frame på CCD’en ikke påvirker hastigheden.

    BindingX start pxY start pxSize pxExp. Time SFramesTotal TimeExp pr SecTransfer time
    2×2100100140×1400,1020063,623,1440,218
    2×2100100420×1400,1020063,813,1340,219
    2×2100100280×1400,1020064,693,0920,223
    2×2100100140×2800,1020086,382,3150,332
    1×1740575140×700,1020086,502,3120,333
    1×1740575280×700,1020086,312,3170,332
    1×10100140×1400,1020086,692,3070,333
    1×11400100140×1400,1020086,752,3050,334
    1×1100100140×1400,1020086,942,3000,335
    1×1740540140×1400,1020087,062,2970,335
    1×1100100280×1400,1020087,192,2940,336
    1×1100100640×1400,1020087,382,2890,337
    1×1100100280×1400,1020087,442,2870,337
    1×1100100420×1400,1020087,502,2860,338
    1×1740505140×2800,10200101,921,9620,410
    1×1100100140×2800,10200105,621,8940,428

    Fik også testet Maxims metode til at udregne latency og sætte et off-set ind og resultatet er
    rigtig godt. Den beregner det meget nøjagtigt og latency ser ud til at være konsistent.

    En anden lektion som kom ud af øvelserne er at man skal meget på med at sætte en USB hub
    mellem kameraet og PC. Der skal ikke meget trafik til fra andre enheder før timingen skrider.
    Så det ender nok med at en kraftig bærbar sættes ved montering med et USB kabel direkte
    mellem PC og kamera når der skal laves tids præcis fotometri.

    Nightsky2014-11-19 23:01:49

    #124747

    nightsky
    Deltager
    • Neutron star

    Komponenterne til min tidssynkronisering er også kommet hjem. En hurtig test ser ud til at det
    er ganske nemt at strike et meget præcist ur sammen med ganske få midler.

    Uret synkroniseres efter DFC 77,5 KHz signalet fra Frankfurt på her hele kommende minut.
    Uret kan så f.eks. blinke foran CCD’en hvert hele sek, minut eller hvad man nu vælger. En
    anden amatør gav mig den ide at man kan projektere tiden fra et tidsdisplay via et flip-mirror
    arrangement og et par linser til CCD’en.

    Det ender nok med at det bliver et permanent astronomisk ur til observatoriet. Sikke et spin-off

    #124755

    Lars Malmgren
    Deltager
    • Super Nova

    Ser spændende ud!

    Hvordan fanger du Frankfurt-signalet ?
    Er der lavet et arduino shield til det ?

    Hvad med dekodning af signalet, gør du det i arduino-programmet?

    Prøv at se den her, den er jeg ret lun på >> http://www.udoo.org/

Viser 15 indlæg - 16 til 30 (af 32 i alt)
  • Emnet 'Hjælp til fotometri forklaring og tidssynkroniseri' er lukket for nye svar.