Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This is my informal daily notes and story. See milestones for official progress.

Day 1: June 13 2022

  • I met Professor Stubbs for the first time in person. He was very tall.
  • Based on Elana's suggestion I tried to download Canon Eos Utility to my computer for remote shooting. It turns out the software for 5d Mark IV was not compatible with M1 computers unless a lot of adjustments are made to the camera in a way that it would only work with M1 computers. It is sad that Canon and Apple still did not figure this out. That was quarter of my day.
  • I set the wireless triggering system up. However, the documentation and Youtube videos were all showing a different transmitter and receiver combination which made it way harder than it is supposed to be. 
  • I looked at the manual of the Xenon light and tried to figure out what RTN and Vref meant. Learned it at the end of the day. 
  • Made a small dummy drawing of a possible circuit that combines the camera trigger system and the flashlight.
  • I found a solution for the circuit in which I had to cut a lot of wires.
  • Professor Stubbs told me that I did not need to cut a lot of wires and I could use connector. 
  • After trying to figure out how the connectors would be useful and failing, I decided to call it a day at 6pm.

Day 2: June 14 2022

  • Gave up trying to connect my computer to camera and used the IPAD instead. Did the first successful shooting which triggers everything.
  • Elana sent me three papers to read about Adaptive Optics and Dome Seeing. Most of my day was reading the review paper. I feel like I learned a lot about the subject and what this group is doing in general.
  • Suddenly it struct me how I could make the Xenon light circuit without cutting too many wires. I asked Sasha for help to find the necessary tools in the lab and start the process. 
  • I learned that I could see Professor Stubbs next day at 8AM. To make this precious time worthy and have a concise presentation, I accidentally stayed in the lab until around 8pm and built up the essentials of the trigger circuit using a breadboard.

Day 3: June 15 2022

  • Came to lab an hour early (8AM) to meet with Professor Stubbs.
  • Figured out I needed to keep a lab log. I hope this will go well! If it doesn't, I think I am at least funny.
  • I learned that breadboards cannot take a current as high as 1 Amp so my grind from day 2 turned out to be kind of useless. 
  • Professor Stubbs and Elana talked me through how to setup the trigger circuit like explaining it to a five year old. It was an intense 30 minute period that I learned a lot. 
  • Professor introduced me to Jim. He is legendary. After I had an idea (on a white board) how to make the circuit, I proceeded to put a physical plan to make it. I went to Jim with my physical plan and found out literally everything I was intending on doing has a better way of doing it. He did it with the better way of doing and my circuit worked for the first time.
  • Tomorrow, I will combine the camera trigger system and the circuit itself and try to take a picture of the Xenon flashlight. Elana showed me how to make that light a point source and how to make a mechanical setup to adjust its height for easier photography. Once again, thank you for that!

Day 4: June 16 2022

  • Completed lab safety training.
  • Figured out taking the picture of the flash. Initial circuit is now complete.

Some notes from Stubbs- 1) Bravo!. 2) see Xe-F_TLS1022E.pdf. It turns out the trigger input is opto-isolated inside the Hamamatsu box. Also some other good information on their FAQs at the end of that document. 

Task List For Days After

  •  Change the DC supply of the circuit
  •  Figure out how to take multiple photos with Canon 5d mark iv
  •  Figure out taking the picture of the flash from 7 meters
  •  Try again to setup Canon Eos Utility On My Computer
    •  If works, setup other image processing software
    •  Else, setup one of the mac Minis from scratch
  •  Figure out a way to put the Xenon circuit in a box

Canon 5d Mark IV Frame Rate

The camera can take a maximum of (approximately) 7 frames per second when everything is optimal (enough battery, memory space, no automatic correction for the exposure time). However, based on my scratch work it can only take up to 20 photos in 7 frames per second. Then the frame rate significantly slows down. This can be fixed by waiting some time between taking photo burst. Again, based on my calculations, a 20 second waiting time is sufficient to take another 20 photos in 7 fps.

On the other hand, when used with flash triggering system, the maximum frame rate significantly drops. As far as I observed, it was barely more than 1 frame per second. This is happening despite the fact that camera can shoot the flash with a shutter speed of 1/8000 seconds.

Day 5: June 17 2022

  • Although it was a staff holiday for Harvard, everyone was at the lab.
  • Decided a small power supply would be enough to supply 5 Watts.
  • Changed the circuit in a way that both the trigger and lamp is powered through the same dc power supply.
  • To address the previous point, modified to circuit in a way there would be a voltage divider to not over load the trigger.

Day 6: June 20 2022

  • It was an observed Harvard holiday but everyone was in the lab.
  • We cleaned the lab and put everything useless in a storage. Lab looks way bigger now.
  • I setup a new MacMini identical to MacMinis in Chile to connect my computer via ssh or screen share to take data from the camera
  • Important note: Apple does not let you deactivate two factor authentication once activated. The apple id stubbs@g.harvard.edu requires additional trusted phone numbers.

Day 7: June 21 2022

  • Tried to find a way around the limitation of frames per second of 5d Mark IV. We can take continuous burst if we take JPEGs. However, we need RAW.
  • The trigger system significantly slows down Cameras frame rate.
  • I was able to put the Xenon flashlight circuit in a box that lets me still get wireless signal. 
  • I will attempt to illuminate the mock star survey Professor Stubbs brought to lab. That would probably the hardest challenge.
  • Skills acquired: Using a drill

Day 8: June 22 2022

  • Decided to try a different setup with a possibility of continuous lighting.
  • The Godox Strip box combined with the mock star survey made by aluminum foil shields light output and may be dim enough for continuous lighting while the telescope is running.
  • The previous setup was the combination of a xenon lamp and optical fibers.
  • I did my own mock star sample.
  • Couldn't illuminate it because I thought light was a little unsafe and I was alone in the lab (the negative connection did not really tighten)
  • I spent around half a day learning how optical fibers work and how many photons from the xenon light will reach to camera in visible light wavelength.
  • Figured out screen sharing with a closed computer and fully setup the mac mini. I will also try to install Eos Utility and use it via screen sharing!

...


Stubbs notes June 23, 2022:

One option for illuminating the back of the pinholes in the Al foil is to use a high power LED. We have some 50 Watt LEDs but I've never wired one up.

Link to what we have: https://www.amazon.com/gp/product/B07BLQ81GS/ref=ppx_yo_dt_b_asin_title_o08_s00?ie=UTF8&psc=1 

They look like this, with this polarity: 

Image Added


It's actually an array of individual LEDs in series and parallel configuration.
The current we supply determines the brightness. Here's a table of what to expect: 


Image Added

Also have a housing that includes a heat sink, which we'll need if it runs continuously. Need to be able to provide around 2 Amps of current at 34 volts, that's more than 60 Watts ! Suggest we start with lower currents 

At full power it presents an impedance of Z=V/I = 32/2 = 16 Ohms or so. 

This would work as a drive unit: https://www.amazon.com/Constant-110V-240V-Waterproof-Transformer-Aluminium/dp/B01N374QPE/ref=sr_1_7?crid=XC5FZZYUXCD8&keywords=32%2Bvolt%2Bled%2Bdriver&qid=1655976284&s=hi&sprefix=32%2Bvolt%2Bled%2Bdriver%2Ctools%2C58&sr=1-7&th=1 

But let's try it out with a 50W continuous LED first- Bought this:

Image Added

from https://www.amazon.com/gp/product/B073RJWFSF/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&th=1

Plugs into 110V outlet, easy to use.

Day 9: June 23 2022

  • Was able to build the setup with the camera being 7 meters away from the light source.
  • Was able to focus the camera on multiple sources, only 2 at this time, more sources will be available with incoming material.
  • Connected the camera to a mac mini and screen shared my way to take photos with the camera remotely.
  • In addition to the macbook setup in this wiki, I downloaded Canon Eos Utility. I have to note that the website detected the operating system wrong, if downloading for canon 5d mark iv, just get the version that states OS12.
  • Figured out necessary updates to logging in and screen sharing procedures.

Updates for the Remote Access Procedures For Mac OS 12

  1. Any operating system that is above Mac Os Mojave does not initially let terminal application full disk access. That significantly limits what one can do with ssh.
    1. Pull down the  Apple menu and choose ‘System Preferences’
    2. Choose “Security & Privacy” control panel
    3. Select the “Privacy” tab, then from the left-side menu select “Full Disk Access”
    4. Click the lock icon in the lower left corner of the preference panel and authenticate with an admin level login (enter password)
    5. Click the [+] plus button to add an application with full disk access
    6. Navigate to the /Applications/Utilities/ folder and choose “Terminal” to grant Terminal with Full Disk Access privilegesOriginal article that explains the reasoning to do this is here: https://osxdaily.com/2018/10/09/fix-operation-not-permitted-terminal-error-macos/
  2. MacMinis require local login after power shutdown for Mac Os12, I do not know which patch did this necessarily start. To solve this issue autologin must be enabled to MacMini. Some old threads suggest that this was cause by the FireVault. That is not the case anymore. At Mac OS 12 FireVault is just an additional security. The procedure below is the correct way to go!
    1. Pull down the  Apple menu and choose ‘System Preferences’
    2. Go to "Users and Groups"
    3. Choose Login Options
    4. Turn Auto Login On
    5. Extra Information: You may need an app that automatically starts to start the sharing process. Canon Eos Utility is such a software. As far as I am concerned, steps until d should be enough.
    6.  

Day 10: June 24 2022

  • Discussed the principles of writing a paper with Professor Stubbs
  • .Debugging gphoto2. I am still currently stuck on this
    • The initial was a permission problem. Eos Utility was invading the usb port camera was connected. Quit Eos Utility to use gphoto2.
    • The scripts presented Mac Os setup are shell scripts that run a set of commands. Once creating the file, make sure to give permission to execute.
    • Currently first two lines of takeimage.sh is working, debugging third line.
  • New flasholder and mount arrived.

Day 11: June 27 2022

  • Figured out debugging gphoto2,  updated the MacMini setup wikipage.
  • Tested whether taking 100 photographs overheat the Xenon flash lamp.
  • Photographs ended up being saturated. I have to find a way to fix that.

Day 12: June 28 2022

  • Optimal setup to take the pictures: ISO 100, White Balance 5200 K.
  • Letting light reach to lens only through a 1 inch diameter aperture significantly helps with saturation. 
  • Used a filter decrease the amount of light. Was able to avoid saturation. Going to check with python tomorrow.

Day 13-14: June 29-30

  • Finished python analysis and figured out there was a focusing problem. The unfocused light source has a significantly larger area compared to focused one.
  • Professor Stubbs told me about the physics of focus but I still need to further understand what does it mean to be focused on something.
  • Ordered a pegboard and made a setup where it is possible to take pictures of 7 light sources.
  • Going to work on creating a shot that makes it possible to make none of the light sources too "blurry".
  • Professor Stubbs gave me an aperture that slightly modifies the angle of incoming light to map on different spaces on the lens. I will assemble the aperture after the long weekend.

Day 15: July 5 2022

  • Looked for SMA barrel connectors in the lab. Could not find them. Tried to use an alternative approach for the pegboard.
  • Thorlabs lens ring remover is not compatible with Edmund Optics rings. Found a tool move the rings regardless of the brand.
  • I noticed some defect while taking the lenses apart:
  • Set up the setup outlined in Milestone5.
  • Plan for the week: Get the hardware done by the end of the week no matter what (smile)

Day 16-17: July 6-7 2022

  • Tried to understand what was going on with the picture shown in Milestone5.
  • Actually every source results in 4 images, however some of the pictures out of the frame.
  • Tried to figure out how each prism wedge affect the light. Was able to figure it out.
  • Studied the astropy, photutils libraries to do automatic data analysis. Gaussian fitting is problematic.
  • Saturation started to be a problem again. It gets better with OD=1 ND filters. We need to order more of those.
  • Found the barrel connectors but ended up not using them because of ghost source effects.
  • Made a theoretical calculation of much the wedge should affect the image. My calculations do not explain the data.

Day 18: July 8 2022:

  • Figured out the mistake in the calculations and found out how the incident angle affect the image in terms of pixels. 


Results are summarized in the table below:

Incident Angle Variation (Degrees)

Shift In Detector Space (cm)

Shift In Image (Pixels)

0.250.21392
1.51.3092443
2.52.1814071
3.53.0545693
  • The weird shaped light sources in the picture of Milestone 5 were actually ghosting effects.

Day 19: July 11 2022:

  • Wrote and submitted my Midterm Report to HCRP to get the remaining portion of my summer funding.
  • Tested out bunch of ND filters to see which one would be the best.
  • Tried to decrease the output intensity of the Xenon flash lamp. I managed to decrease it from 600 to 400 Volts but that did not end up fixing the saturation.
    • This makes sense because output energy is E = C x V^2 so decreasing to ⅔ of the value does not create a difference as strong as an ND filter.

Day 20: July 12 2022:

  • By combining two wedge prisms of 0.25 degrees I made 0.5 degree wedge prism.
  • I also found a 1 degree wedge prism by Edmund Optics. I will update setup in a way that the angles I would be using would be 0, 0.25, 0.5, and 1.
  • Had a meeting with Professor Stubbs and asked why don't I get similar behavior with prisms. He reminded me the fact that they were prisms and dispersed the light.
  • I am going to try to take photos with Narrowband filters.

Day 21: July 13 2022

  • Narrowband filters ended up decreasing the flux too much. I can't currently tell whether they have fixed the odd shape issue. It may be better work with filters with a greater FWHM.
  • It may be better do it with some long pass or shortpass filters. I am trying to find a suitable one in lab.

Week 5.5-6: July 14-July 21

  • Disregarded addition of deflecting incident angles of light. 
  • Was able to take data and fit sources into Gaussians after that.
  • Wrote a code that takes a path of fits files and returns rms distance between sources and differential motion for that distance.
  • Updated the image taking script in a way it would communicate with a system that indicates when telescope is taking data.

July 22:

  • Wrote a code to find the configuration of N sources in a way that would maximize the number of unique distances among sources. It takes the grid dimensions (n x m) and number of sources N and gives out integer coordinates that would maximize the unique distances. In general, for N sources, there should be (N,2) unique distances.
  • I used a Monte Carlo like approach and it works very efficiently for any grid larger than 7 x 7 for 7 sources. 7 x 7 takes a long time. A 6 x 7 has less than 21 unique distances.
  • I tried to come up with a theoretical formula or a prettier number theoretic or graph theoretic solution. I couldn't find one. Euclidian distance is a hard aspect to detect uniqueness.

July 25:

  • After finding the configuration I installed it on the peg board.
  • Did the necessary data analysis.

July 26:

  • The gphoto2 software is too slow to take photos. I have been trying to debug it. Current script properties are:

    Script or style to take photo

    How many seconds taking a photo takes

    TakeImageDownloadnDelete (no flash circuit)

    8.65 seconds per shot

    TakeImage.sh

    8.62 seconds per shot

    Manually pressing without flash

    0.34 seconds per shot, varies between 7fps and 0.5 fps

    Manually pressing with the flash circuit

    0.51 seconds per shot (approximately 2 fps)

    Manually Pressing Eos Utility

    1.33 seconds per shot but not synced with flash

    gphoto2 TakeImageCommunicate.sh

    8.67 seconds per shot, synched with the flash

  • I have checked line by line for which line causes an error.
  • The error is caused by the command: gphoto2 --set-config /main/actions/eosremoterelease='5'
  • Because of the error the script pauses and it takes a long time to take a picture. In Image Collection Instructions it is stated that error should be ignored. That is right, pictures are taken despite the error and image collection is problematic without that line.
  • Setting the remote release to other configurations gphoto2 --set-config /main/actions/eosremoterelease='2' does not create an error. In fact, running the command gphoto2 --set-config /main/actions/eosremoterelease='5'  after setting the configuration to another setup makes the command run with errors.
  • However, when  the remote release setup is run without errors, camera can't take picture.
  • Both the failure to set the remote release to 5 or "immediate" and camera unable to take picture results in an error: 

    *** Error (-110: 'I/O in progress') ***

      • In addition, --set-config command does not do what its supposed to do. After the set config command, when configurations are asked, it is again the previous configuration. The output below explains it:


    (base) stubbslab@dhcp-10-250-142-126 code % gphoto2 --set-config /main/actions/eosremoterelease='2'                                                                          
     
    *** Error ***              
     
    Failed to set new configuration value 2 for configuration entry /main/actions/eosremoterelease.
     
    *** Error (-110: 'I/O in progress') ***       
     
     
     
     
    For debugging messages, please use the --debug option.
     
    Debugging messages may help finding a solution to your problem.
     
    If you intend to send any error or debug messages to the gphoto
     
    developer mailing list <gphoto-devel@lists.sourceforge.net>, please run
     
    gphoto2 as follows:
     
     
     
     
        env LANG=C gphoto2 --debug --debug-logfile=my-logfile.txt --set-config /main/actions/eosremoterelease=2
     
     
     
     
    Please make sure there is sufficient quoting around the arguments.
     
     
     
     
    (base) stubbslab@dhcp-10-250-142-126 code % gphoto2 --set-config /main/actions/eosremoterelease='2'
     
    (base) stubbslab@dhcp-10-250-142-126 code % gphoto2 --get-config /main/actions/eosremoterelease
     
    Label: Canon EOS Remote Release                                                
     
    Readonly: 0
     
    Type: RADIO
     
    Current: None
     
    Choice: 0 None
     
    Choice: 1 Press Half
     
    Choice: 2 Press Full
     
    Choice: 3 Release Half
     
    Choice: 4 Release Full
     
    Choice: 5 Immediate
     
    Choice: 6 Press 1
     
    Choice: 7 Press 2
     
    Choice: 8 Press 3
     
    Choice: 9 Release 1
     
    Choice: 10 Release 2
     
    Choice: 11 Release 3
     
    END
     
    (base) stubbslab@dhcp-10-250-142-126 code %

  • First time running a set configuration command it fails. The second time it doesn't. Then when get config is run it does not get updated.
  • When the --set-config command is in a state that it doesn't pull out an error the code block:

    gphoto2 --auto-detect --set-config /main/imgsettings/imageformat=32 && gphoto2 --set-config /main/actions/eosremoterelease='5' && gphoto2 --set-config /main/actions/cancelautofocus='0' && gphoto2 --set-config capturetarget='1'

    does not output an error. This is the entire script of image taking minus the command to actually take the image. Then, one would assume that addition of the picture taking command should not be a problem. However, when the same command is run as:

    gphoto2 --auto-detect --set-config /main/imgsettings/imageformat=32 && gphoto2 --set-config /main/actions/eosremoterelease='5' && gphoto2 --set-config /main/actions/cancelautofocus='0' && gphoto2 --set-config capturetarget='1' && gphoto2 --capture-image-and-download --no-keep

    it results in an error of:


    *** Error ***              
     
    Canon EOS Full-Press failed (0x2019: PTP Device Busy)
     
    ERROR: Could not capture image.
     
    ERROR: Could not capture.
     
    *** Error (-110: 'I/O in progress') ***  

  • Then when run as a shell script, it either gives could not capture image error or could not set remote configuration to 5 error.
  • Configuration errors still let me take the picture.
  • Other people are having this problem too in different contexts.
  • I will read more github threads tomorrow. So far I think it is a problem between EOS and gphoto2.

July 27:

July 28:

  • Compared all the aspects of 5d Mark IV and 6d Mark II including with what type of USB they are connected with.
  • Noticed the difference of mirror lock up.
  • Disabled the mirror lock up in 5d Mark IV and was able to get shots as fast as manually pressing.
  • Fast shots work with rapid shooting drive mode and are synchronized with flash.
  • The script to take the pictures takes as around 10 shots in 7fps before it starts the write the files to the computer.
  • Image collection part of the script is way shorter than writing them to computer.
  • Precise count of pictures vary based on the state of camera. That is, if you run repeat 5 ./TakeImageCommunicate.sh the first run gives 10, the second run gives 8, third one gives 11, etc. It is randomized between 7 and 12.
  • A sample data collection:
    Image AddedIMG_9221.mp4
  • I tried running the camera for a long time. It is okay running for a long time. I will take a look at the time dependence of dimms.
  • The times are in a weird format when stored in MacMini.
  • The entire repeat process terminates when the file can_take_images is removed. I should update in a way that it continues running.

July 29:

  • Left the Xenon flash, the signal receiver,  the trigger, and the camera on for the entire night to see whether the batteries would last or the Xenon flash would get too hot. Nothing happened.
  • Although it appears weird on MacMini, the get info window of the image shows correct times.
  • The converted fits files have dates of the conversion times.
  • To keep the dates I should somehow get the dates from the CR2 files and store it. Keeping both the fits and CR2 files would be redundant.
  • I did a differential image motion analysis in which I put a hot air gun in front of the sources. The differential motion increased by half an order of magnitude. This means the setup can successfully characterize airflow disturbances.

August 1:

  • Checked whether time dependence of seeing was an issue.
  • The data is in the form of successive burst of photos. I was not convinced that we could just aggregate different sets of bursts and get more data. That would make us lose the entire time dimensionality.
  • I had taken the data in a span of an hour with burst with an average of 11 photos.
  • I separated bursts with each other and did a differential image motion analysis for every burst.
  • Time of the burst did not have a clear effect on the magnitude of differential image motion.
  • In fact, standard variation of differential motion of two sources within a photo burst was usually higher than the standard deviation of all the rms values of different bursts.
  • To figure out whether that was a unique problem regarding the burst photos or standard deviation of 10 random shots being larger than the standard deviation of rms's of groups of 11 shots, I chose 11 arbitrary shots from the list of files. I randomly chose 10 set of 11 shots from the directory and ran the same analysis. The results were similar which showed that shots coming from different bursts could be aggregated and time is not a dominating factor.
  • Of course, this conclusion is valid for an hour.
  • I currently separated burst using the fact camera saves photos coming from different burst 3 labels apart. For example, if the first end of first burst is image5, the start of second burst is image8.
  • I will try to get actual time data from the pictures as well.
  • I do the current time separation using:

    "Takes a file name that was output by the camera and returns image number"
    def extract_number(file_name):
        return int(file_name.split('A')[1].split('.')[0])
     
    "Takes a sorted file list and returns a list of list. Each list is one burst of shots."
    def time_divider(file_list):
        # take the numbers, make an np array for easy indexing
        image_numbers = np.array(list(map(extract_number, files)))
        # find the indexes of the gaps between photos (where difference is more than 1)
        indexer = np.where(np.diff(c) != 1)[0]
        # create an empty list for the divided
        divided = []
        for i in range(len(indexer)):
            # take the burst as a list
            if i == 0:
                burst = file_list[i:indexer[i] + 1]
            else:
                burst = file_list[indexer[i-1] + 1: indexer[i]+1]
            divided.append(burst)
             
        return divided

    I can answer questions about the process offline.

August 2:

  • Went back to threads I used to debug the camera problem and shared my solution.
  • Cut the necessary pieces for my Green Training Project In The Machine Shop.
  • Fixed the timing issue of the pictures taken.  Simply, time settings of the camera were wrong.  I set the time UTC and fixed it there. 
  • I wrote a script that takes a directory as input and outputs a csv of the name of the files and their dates.
  • That is the only script that is currently running in Mac Mini itself. It uses pandas, ExifRead, and OS.
  • Here is the script:

    import os
    import exifread
    import pandas as pd
    import sys
     
    """Takes a directory of files and returns a data frame of files and the time
    of their creation"""
     
    def extract_times(input_path):
        path = input_path
        file_list = sorted(os.listdir(path))
        dates = []
        for file in file_list:
            path_name = path + '/' + file
            f = open(path_name, 'rb')
            # Return Exif tags
            tags = exifread.process_file(f)
            dates.append(tags['EXIF DateTimeOriginal'])
     
        time_frame = pd.DataFrame({'files': file_list, 'dates': dates})
        return time_frame
     
    path = sys.argv[1]
     
    time_frame = extract_times(path)
     
    time_frame.to_csv(path + '_file_times.csv')

  • I had setup Miniconda in the MacMini and created a python3.10 environment called 'strobed'.
  • Today I installed pandas and ExifRead using conda install.
  • IMPORTANT NOTES:
    • If you would like to install packages to the 'strobed' environment, use conda install, not pip install.
    • If you would like to use the MacMini to analyze other projects, create a conda environment with the names of the project and install the required packages.

August 3:

  • Spent all day in the machine shop for Green Training.