SonotaCo.JP
SonotaCo Network Japan Forum
SonotaCo.JP Forum Index
homeTop Page  FAQFAQ   検索検索   メンバーリストメンバーリスト   ユーザーグループユーザーグループ   登録する登録する 
 プロフィールプロフィール   プライベートメッセージをチェックするプライベートメッセージをチェックする   ログインログイン 

I captured a 'plane and a meteor. Can I analyse the meteor?

 
新しいトピックを投稿   トピックに返信    SonotaCo.JP Forum Index -> UFOCapture BBS in English
前のトピックを表示 :: 次のトピックを表示  
投稿者 メッセージ
Alex Pratt



登録日: 2012.01.17
記事: 29

記事日時: Thu Sep 20, 2012 5:34 am    記事の件名: I captured a 'plane and a meteor. Can I analyse the meteor? 引用付きで返信

Hi,

I use UFO software to capture and analyse 2-station monitoring of meteor showers.

In one example, UFO Capture recorded a bright aeroplane moving slowly across the field, then in the last second it recorded a nice Perseid meteor. My colleague, 100km away, also recorded the same Perseid - without the 'plane.

I used the mask option in UFO Analyser to categorise the meteor, but the M*.csv file gives the time of the 'plane, 00:10:52 UT. Its correct time was 00:11:00 UT, 8 seconds later.

Because of the 8 seconds time difference, UFO Orbit does not pair up the meteors. If I edit my M^.csv file to the correct time 00:11:00 it then lists it as a sporadic and its 'rt' radiant point lies outside the 10 degree Perseid radiant circle.

Is this because the positional data in M*.csv are computed for 00:10:52 and not 00:11:00?

Is there a way to rescue this 2-station Perseid or has the aeroplane ruined the capture?

Many thanks,

Alex.
トップに戻る
ユーザーのプロフィールを表示  
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 10025
所在地: 139.67E 35.65N

記事日時: Thu Sep 20, 2012 9:05 am    記事の件名: Re: I captured a 'plane and a meteor. Can I analyse the mete 引用付きで返信

You can assign the analyse start and end frame by f1 and f2 textbox in Profile/Analyze sheet.
if you set. f1 = 200, f2 = -1, then before the 200th frame (almost 8 seconds on 25fps) will be ignored from the analisys.

Try Wink
トップに戻る
ユーザーのプロフィールを表示   投稿者のウェブサイトに移動
Alex Pratt



登録日: 2012.01.17
記事: 29

記事日時: Thu Sep 20, 2012 11:47 pm    記事の件名: Re: I captured a 'plane and a meteor. Can I analyse the mete 引用付きで返信

Hi,

Thank you for this advice,

Like the mask option, it works but it does not update the time in the M*.csv file. The time is still logged as 00:10:52 UT and not 00:11:00 UT. An 8 seconds difference.

UFO Orbit has a default value of 'dt' of 3 seconds. Is this the upper time difference limit for good quality data?

Do you recommend editing the M*.csv file to change the time fields to 00:11:00 UT?

This possible Perseid meteor is just outside the radiant circle, so it is classified as a sporadic. No problem - we will have other examples where one or more meteors have been captured during the passing of a 'plane and we do not want to do an incorrect analysis.

We could have time differences up to 30 seconds if UFO Analyser uses the start time of the 'plane capture and not the meteor time.

Best regards,

Alex.
トップに戻る
ユーザーのプロフィールを表示  
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 10025
所在地: 139.67E 35.65N

記事日時: Fri Sep 21, 2012 8:16 am    記事の件名: Re: I captured a 'plane and a meteor. Can I analyse the mete 引用付きで返信

Hi Alex

Well,
Alex Pratt wrote:
UFO Orbit has a default value of 'dt' of 3 seconds. Is this the upper time difference limit for good quality data?

No, you can change dt setting if it is truly needed, such as each camera captures different part of a long meteor.
In our experience, there were cases up to 30 seconds dt was required.
Dt's default 3 seconds is aimed to reduce miss combination of different meteor's single station observation on automated analysis.
But, you can set dt freely manually as long as it is on one focused long meteor.


Alex Pratt wrote:
Do you recommend editing the M*.csv file to change the time fields to 00:11:00 UT?

No, it is not recommend for usual case.
It should be done only the PC time was not correct. The TimeAdjust function on Uty sheet is for it. It changes many object's time of multiple clip at a time.

BTW
Alex Pratt wrote:
it does not update the time in the M*.csv file. The time is still logged as 00:10:52 UT and not 00:11:00 UT.

Your situation is beyond my imagination. There must be some special reason.
Current my understanding of your case is
1. Clock of PC was correct.
2. Airplane began at 00:10:52 of real UT.
3. The meteor began at 00:11:00 of real UT.
4. Superimposed time on the frame of beginning of the meteor is 00:11:00.
5. UA2 recognized the airplane and the meter independently as two different object using f1 and qm.
6. Time in MCSV file (H(UT) M S field of the record) of the meteor's record was 00 11 00.
This can happen only the airplane does not move so much and the separation of two objects 5. was not succeeded.
Is it so?
トップに戻る
ユーザーのプロフィールを表示   投稿者のウェブサイトに移動
Alex Pratt



登録日: 2012.01.17
記事: 29

記事日時: Fri Sep 21, 2012 10:26 pm    記事の件名: Re: I captured a 'plane and a meteor. Can I analyse the mete 引用付きで返信

Alex Pratt wrote:
it does not update the time in the M*.csv file. The time is still logged as 00:10:52 UT and not 00:11:00 UT.


Quote:
Your situation is beyond my imagination. There must be some special reason.
Current my understanding of your case is
1. Clock of PC was correct.
2. Airplane began at 00:10:52 of real UT.
3. The meteor began at 00:11:00 of real UT.
4. Superimposed time on the frame of beginning of the meteor is 00:11:00.
5. UA2 recognized the airplane and the meter independently as two different object using f1 and qm.
6. Time in MCSV file (H(UT) M S field of the record) of the meteor's record was 00 11 00.
This can happen only the airplane does not move so much and the separation of two objects 5. was not succeeded.
Is it so?


Hi SonotaCo,

Your comments 1 to 5 are correct, but for comment 6 the values of H(UT) M S in the M*.csv file are always 00:10:52, the time of the airplane capture, not the time of the meteor (00:11:00).

For comment 5, UA2 detected the 'plane, then I used 'qm' or 'f1 and f2' to post-analyse the meteor. It always records the time as 00:10:52 in the M*.csv file.

We use 2-station meteors to estimate the meteor radiant - and the meteor orbit, if the data are good quality. If there is a big time difference in M*.csv, such as 8 seconds or more caused by an airplane, when we know that the real difference is <1 second, how reliable is this data?

A difference of 30 seconds is not significant for measuring a meteor radiant, but is it too large for an orbit determination?

I will ask my colleague to analyse one of his captures, where a meteor has appeared during a capture triggered by an areoplane.

Best wishes,

Alex.
トップに戻る
ユーザーのプロフィールを表示  
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 10025
所在地: 139.67E 35.65N

記事日時: Sat Sep 22, 2012 9:10 am    記事の件名: Re: I captured a 'plane and a meteor. Can I analyse the mete 引用付きで返信

Alex Pratt wrote:
For comment 5, UA2 detected the 'plane, then I used 'qm' or 'f1 and f2' to post-analyse the meteor. It always records the time as 00:10:52 in the M*.csv file.


Oh!! you are right.
I checked on my long meteor sample setting f1 as 200, now I realized, the MCSV time was not changed Exclamation
Its a shock Shocked . It is not a behavior that I was thinking, sorry.
Originally f1 is used to detect the faint part before trigger, so I tested f1=10, but I have not tested setting very big value of f1.

Well, it means there is no prepared method that corrects the beginning time on the situation like this.
So, back to the first question, I agree to change MCSV time manually.

---
Yes 8 seconds time error is very big for orbit or trajectory determination.
Earth rotates 4km(Japanese lat) and moves 240km on orbit in 8 seconds.
UO2 is using the smallest time among multiple observations to determine the start position on orbit computation.
トップに戻る
ユーザーのプロフィールを表示   投稿者のウェブサイトに移動
Alex Pratt



登録日: 2012.01.17
記事: 29

記事日時: Sun Sep 23, 2012 7:11 am    記事の件名: Re: I captured a 'plane and a meteor. Can I analyse the mete 引用付きで返信

Quote:

Well, it means there is no prepared method that corrects the beginning time on the situation like this.
So, back to the first question, I agree to change MCSV time manually.

Yes 8 seconds time error is very big for orbit or trajectory determination.
Earth rotates 4km(Japanese lat) and moves 240km on orbit in 8 seconds.
UO2 is using the smallest time among multiple observations to determine the start position on orbit computation.


Hi SonotaCo,

Thank you for investigating this situation.

I will take care in using such a meteor event for radiant or orbital work.

Many thanks,

Alex.
トップに戻る
ユーザーのプロフィールを表示  
William Stewart



登録日: 2010.08.11
記事: 13

記事日時: Mon Sep 24, 2012 7:42 pm    記事の件名: "Head" Value in UFO Capture and its use in UFO Ana 引用付きで返信

Dear SonotaCo,

This is my first post here - my name is William Stewart and I am a dual station collaborator with Alex. This is a follow up to the thread titled "I captured a 'plane and a meteor. Can I analyse the meteor?"

Looking at the [Frame Shift(time shift) settings] section of your instructions located at http://sonotaco.com/soft/UFO2/help/english/3-2.html it would appear that it is possible to modify the "Head" value in UFO Capture.

The recommendation is 25 - 30 in order to match the number of frames that would typically be captured by a camera in a time of one second.

Does the UFO Analyser software take account of this "Head" value and thus apply a correction before writing the timestamp in the M*.CSV file?

So for example, if a meteor trail began at 20120920_231215, was recorded on a camera at 29fps and the "Head" value was set to 30, the M*.CSV timestamp would be 20120920_231215, even though the recording would have started one second earlier at 20120920_231214?

Or in the case that if a meteor trail began at 20120920_231215, was recorded on a camera at 29fps and the "Head" value was set to 90, the M*.CSV timestamp would still be 20120920_231215, even though the recording would have started three seconds earlier at 20120920_231212?


Alex and I would like to introduce a "Quality Check" into our analysis procedure when using UFO Analyser. Our current proposal is that in the event that the trigger is NOT a meteor (eg is an aeroplane) and that this trigger occurs some time before the meteor appears, that we manually correct the timestamp in the M*.CSV file to the exact time of the start of the meteor trail.

Alex and I both have concerns about this approach, specifically what is the maximum permissible manual time correction to the timestamp in the M*.CSV file? Is up to 3 seconds OK for trajectory / orbital work and is up to 30 seconds OK for radiant measures? We would appreciate your thoughts / guidance on this matter. I'm at 53 degrees north, whereas Alex is at 53.8 degrees north, about 100km to my north-east. And unfortunately we both live close to airports Sad

Best regards

William
トップに戻る
ユーザーのプロフィールを表示  
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 10025
所在地: 139.67E 35.65N

記事日時: Tue Sep 25, 2012 4:37 pm    記事の件名: Re: "Head" Value in UFO Capture and its use in UFO 引用付きで返信

Hi William, welcome here
William Stewart wrote:
Does the UFO Analyser software take account of this "Head" value and thus apply a correction before writing the timestamp in the M*.CSV file?

Time in M*.CSV is the triggering time, not the first frame time. Therefore "head" value does not concern time in M*.csv or filename.
May be you can confirm this by yourself, like images below...

William Stewart wrote:
Alex and I would like to introduce a "Quality Check" into our analysis procedure when using UFO Analyser. Our current proposal is that in the event that the trigger is NOT a meteor (eg is an aeroplane) and that this trigger occurs some time before the meteor appears, that we manually correct the timestamp in the M*.CSV file to the exact time of the start of the meteor trail.
Alex and I both have concerns about this approach, specifically what is the maximum permissible manual time correction to the timestamp in the M*.CSV file? Is up to 3 seconds OK for trajectory / orbital work and is up to 30 seconds OK for radiant measures? We would appreciate your thoughts / guidance on this matter. I'm at 53 degrees north, whereas Alex is at 53.8 degrees north, about 100km to my north-east. And unfortunately we both live close to airports


Well, it is very hard to answer.
Because the final error depends so many factors of each case, such as cross angle between simultaneous observations.
So the maximum admittance cannot be decided generally even if the final error admittance was decided.
So, I am saying , "less than one second of time" is a good target that we should aim.
One second of time corresponds to 0.004 degree of earth's rotation angle, while our typical direction measurement error on video is 0.03 degree.
(0.03 degree is the value on 60degree fov lens with 640x480 resolution and the system can decide the center of the luminescence 0.3pixel accuracy)
So 0.004 degree can be said as safe and negligible on direction measurement for most of the systems.
But if there is 10 seconds of time error, it may lead 0.03 degree of direction measurement and leads 5km error of geocentric position,
it many be bad for most of the cases.

By the way, the case like that happens so often? SlowObject mask does not work? Could you let me see same sample videos?
I hate manual corrections, so I've never done it before. I usually discard those badly detected clips, because it was rare.



M20120924_023900_TK1_S9P.jpg
 説明:
Peak hold of the event
 ファイルサイズ:  25.89 KB
 閲覧数:  6415 回

M20120924_023900_TK1_S9P.jpg



z20120924_023900_TK1_S9_030s.jpg
 説明:
Triggering frame
 ファイルサイズ:  126.53 KB
 閲覧数:  6415 回

z20120924_023900_TK1_S9_030s.jpg



z20120924_023900_TK1_S9_000s.jpg
 説明:
The first frame of stored video
 ファイルサイズ:  116.27 KB
 閲覧数:  6415 回

z20120924_023900_TK1_S9_000s.jpg


トップに戻る
ユーザーのプロフィールを表示   投稿者のウェブサイトに移動
特定期間内の記事を表示:   
新しいトピックを投稿   トピックに返信    SonotaCo.JP Forum Index -> UFOCapture BBS in English All times are GMT + 9 Hours
Page 1 of 1

 
移動先:  
新規投稿: 不可
返信投稿: 不可
記事編集: 不可
記事削除: 不可
投票参加: 不可
このフォーラムで添付ファイルを投稿 できません
このフォーラムでファイルをダウンロード できます


Powered by phpBB © 2001, 2005 phpBB Group
Copyright ©2004 SonotaCo Network. All Rights Reserved.