¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: More on Flash Timing - Some testing...


 

Good stuff, George.
?
My comments:
?
  • I think this is a good data set for demonstrating the performance of your flasher and PyMovie/PyOTE.? The next step would be to repeat the test using a realistic camera (I'll call it a "planetary camera", meaning a fast framing camera that isn't GPS-disciplined like the Astrid) to see what happens when you use a camera that is more likely to drift when exposures are started/stopped.? Of course this would be another sample of one, and there are seemingly infinite cameras that would be available to a user.? But if the sample of one produced bad results, that would be very telling.? For that test, I'd suggest using a dichroic (for example, an Innovations Foresight ONAG) to split the telescope output, directing one leg into one of the accepted timing cameras (like your Astrid) and the other into a flash timed planetary camera like a new user might have.
    • With a realistic system, likely we'd want to test short (few tenths of a second) and long (10 second) blinks--so we'd have to come up with a way to get around the problem you point out.
  • I think it doesn't make the slightest difference, but how step-like were your D's and R's?? Could you see a slope on either?
  • How would a new user with a flasher and a planetary test their complete system?
  • What happens to one of Aart's flashers if they have dicey GPS reception?? I think he logs such things, but is a new user going to understand they have to check the log and (perhaps) just discard the entire observation if there are GPS issues?? I guess most of the time this would produce obvious bad results (for example, no flash)...
  • Do you know what GPS receiver is on your Adafruit shield board?? The "better" one I built (first) has the latest/greatest (released in August 23), and requires a different "Sketch" for the Arduino.? The second I built has an intermediate odd-ball version that is between all the older ones that Aart had and my better one.? So I think there is a lot more testing that could be done.?
  • Any idea what testing Aart has done?? Likely he has that in his files area of the IOTA groups.io site, but I haven't taken the time to look.
  • If useful, I can send you my SEXTA box for additional testing.
  • Are you planning to present your results at the IOTA meeting in September
?
?
Steve C
?


From: George <georvisc@...>
To: OccultNEUS <[email protected]>
Date: Tuesday, 11 June 2024 9:44 PM EDT
Subject: Re: [OccultNEUS] More on Flash Timing - Some testing...

NEUS Folks:

An overabundance of cloudy, rainy skies lately so I thought I'd complete the analysis/tests I started a little while ago using my "Aart's Flasher".?

Why am I dong these tests?....
I've heard/read several discussions about timing with flashers - with some folks liking the devices and some folks being critical of them. But in all discussions, I can't recall anyone who has ever backed up their statements with actual test results. Well, here's some test results...

Mainly I'm doing this to satisfy my own curiosity, ....and sharing the results.

Purpose of the Test:
To compare D & R times obtained first by using (GPS-based) Timestamps (on every frame of video) as the reference source, and then comparing the D & R times obtained by using two (GPS-based) "Bookend" Flashes as the reference source -- using the same .CSV file.

Conditions:
As with all flasher tests I've done the "bookend" flashes were put on a video that also contained GPS timestamps (on every video frame). A single .CSV file was generated and that file was used to measure a "simulated occultation" -- first by using the timestamps, and then by using the two flasher "bookends". The tests were conducted under "real sky" (outdoor) conditions by very quickly waving a piece of cardboard in front of the telescope (the simulated occultations probably averaged about 3/4 of a second in duration). The simulated occultation was near the mid-point between the two flashes. A typical time between the 1st flash and the simulated occultation was 45 seconds, and also 45 seconds between the simulated occultation and the 2nd flash. The D & R of the simulated occultation was measured using PyMovie/PyOTE. PyOTE reported a GPS Timestamp error of 0.00% for every test.

For the 12 tests listed here, I used my Astrid camera -- so the flash-derived times are a comparison against Astrid's GPS timestamps.
The flasher used was a unit made for me and based on Aart Olsen's Arduino-based design.

Summary of some numbers for this series of tests (GPS-based flasher against GPS-based timestamps)....
* The Average difference between the calculated D & Rs - between timestamps vs flasher was 0.0015 seconds ? (about 1/666th of a second).
* The Minimum difference was 0.0001 seconds
* The Maximum difference was 0.0034 seconds (1/294th of a second)
* In 11 out of 12 tests, the flasher yielded D/R times a minuscule fraction of a second before times via timestamps.

I'm attaching scans of the 12 test results. The important number are in the yellow boxes.

Conclusions:
With these results (and many earlier ones), I would feel confident to record an occultation solely based on _MY_ flasher unit -- as I consider it "proven". I also know how my cameras (RunCam, QHY, Astrid) perform, and they nearly always produced 0.00% timestamp errors.
That said, I do feel that any flasher unit must first be tested (numerous times) against timestamped video before any assumed accuracy should be inferred. The camera & recording system used should be proven to not be susceptible to dropped or duplicate frames.

Of course, I would always prefer using a system that placed GPS timestamps on EVERY frame of video, and would only resort to using "flash timing" as a last resort (or perhaps for unmannned stations).

Just a word of note for anyone attempting their own tests.... Keep the simulated occultation short in duration (1 second or under). Since you will be very briefly covering the entire front of the telescope, ALL stars in the FOV will be gone during the simulated event. Thus you can't use a "Tracking Star" to keep the PyMovie aperture locked on the Target Star during the "occultation". In using a simulated occultation of 1 second or under, the PyMovie aperture will not have time to wander off the Target Star. (And even if it did, it often won't matter since you will be using the same .CSV file in measuring times via both Flasher vs Timestamps. In a worse case, any "wander" may simply introduce an unwanted "fade" in the "R").

Maybe this is of interest... maybe not.

George

Join [email protected] to automatically receive all group messages.