Hjælp til fotometri forklaring og tidssynkroniseri

[nightskyDeltager Neutron star]

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

Jeg mangler dog et program/metode til at beregne I_FFaverage
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

[Lars MalmgrenDeltager Super Nova]

Nightsky wrote:

Jeg mangler dog et program/metode til at beregne I_FFaverage

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…

[Lars MalmgrenDeltager 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…

[nightskyDeltager 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

[mhansenDeltager 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

[nightskyDeltager 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 🙂

[Lars MalmgrenDeltager 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

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….

[Lars MalmgrenDeltager 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)

[nightskyDeltager 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

[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

[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

[nightskyDeltager 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

[nightskyDeltager 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.

Binding	X start px	Y start px	Size px	Exp. Time S	Frames	Total Time	Exp pr Sec	Transfer time
2×2	100	100	140×140	0,10	200	63,62	3,144	0,218
2×2	100	100	420×140	0,10	200	63,81	3,134	0,219
2×2	100	100	280×140	0,10	200	64,69	3,092	0,223
2×2	100	100	140×280	0,10	200	86,38	2,315	0,332
1×1	740	575	140×70	0,10	200	86,50	2,312	0,333
1×1	740	575	280×70	0,10	200	86,31	2,317	0,332
1×1	0	100	140×140	0,10	200	86,69	2,307	0,333
1×1	1400	100	140×140	0,10	200	86,75	2,305	0,334
1×1	100	100	140×140	0,10	200	86,94	2,300	0,335
1×1	740	540	140×140	0,10	200	87,06	2,297	0,335
1×1	100	100	280×140	0,10	200	87,19	2,294	0,336
1×1	100	100	640×140	0,10	200	87,38	2,289	0,337
1×1	100	100	280×140	0,10	200	87,44	2,287	0,337
1×1	100	100	420×140	0,10	200	87,50	2,286	0,338
1×1	740	505	140×280	0,10	200	101,92	1,962	0,410
1×1	100	100	140×280	0,10	200	105,62	1,894	0,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

[nightskyDeltager 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

[Lars MalmgrenDeltager 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/

[Forfatter]

Indlæg