Would I be right in assuming this is just the fault of the OSD and not something more serious?
No it's not a UFO sighting, it's an average of 300 photos taken of the oscilloscope screen. Each division represents 0.1ms (scope set to 5ms per division (5 mini-divisions per larger division) and 10x magnification on). Test was conducted like last time, but with a 555 oscillator controlling the trigger to prevent switch bounce and so I didn't have to sit there doing it manually. Images have been overlayed with Gimp's additive mode, so the brightness should be a linear representation of how often each delay time occurred.
It would seem most of the photos have a sync better than 0.5ms. But then there's the faint representation of a significant number of photos taken about 1.5ms too late, any idea of what could be causing that to happen occasionally?
I tried using the sync option with GetAdChValue, but unfortunately as soon as the trigger is activated, the camera seems to freeze up, wait about 10 seconds (same each time), and then take a photo photo regardless of what I do with the trigger.
QuoteI tried using the sync option with GetAdChValue, but unfortunately as soon as the trigger is activated, the camera seems to freeze up, wait about 10 seconds (same each time), and then take a photo photo regardless of what I do with the trigger.Can you tell me more about how you to implement this? Modified source code or CHDK script? The 10 sec timeout usually means the USB remote code is waiting at _wait_until_remote_button_is_released() for the USB signal to go to 0V. If it waits too long, then it times out.
if ( conf.remote_input == 0 ) { remote_key = get_usb_bit() ; } if ( conf.remote_input == 1 ) { if (*(short*)0xc090004a < 555) { remote_key = 1 ; } else { remote_key = 0 ; } } if ( conf.remote_input == 2 ) { if (GetAdChValue(5) < 555) { remote_key = 1 ; } else { remote_key = 0 ; } }
if ( conf.remote_input == 0 ) { do { } while( get_usb_bit() && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); } if ( conf.remote_input == 1 ) { do { } while( (*(short*)0xc090004a < 555) && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); } if ( conf.remote_input == 2 ) { do { } while( (GetAdChValue(5) < 555) && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); }
Did some sync tests on the D20, and I'm having some problems unfortunately. Without sync, everything functions as expected, and there's about at least 20ms of uncertainty in the delay times. However, when using sync, there's also at least 20ms of uncertainty aswell.
The delay time is shortened considerably, and the screen goes dark, so I'm pretty sure the sync is properly enabled, but it's not working properly for some reason.
I have also turned off pretty much every option that can be disabled in the Canon menu, and it's set to manual focus.
Interestingly, the delay time seems to vary predictably each time. It starts off at about 50ms, then works it's way down to about 25ms in about 6 to 10 steps, before jumping back to around 50ms and repeating the cycle.
Do does this occur when testing with conf.remote_input == 0 instead of conf.remote_input == 1 ? (i.e. using regular USB remote sync)If so, you probably need to try the new USB precision sync code now included in the 1.3.0 trunk.
Interestingly, the delay time seems to vary predictably each time. It starts off at about 50ms, then works it's way down to about 25ms in about 6 to 10 steps, before jumping back to around 50ms and repeating the cycle.QuoteVery interesting but I have no idea what it's trying to tell us. Unless your 555 timer is close to some integer divisor of the vsync frequency and what you are seeing is the drift cause by not being exactly locked?
Very interesting but I have no idea what it's trying to tell us. Unless your 555 timer is close to some integer divisor of the vsync frequency and what you are seeing is the drift cause by not being exactly locked?
Is it possible that I have messed something important up by modifing it?
You probably want to read through this thread - http://chdk.setepontos.com/index.php?topic=8312 It starts to get interesting about half way through. The code discussed there is now in 1.3.0 but its not enable by default except for the A1200,
I'm thinking that since the live-preview disappears when using sync, I will probably make it just halfpress to get the focus and ev set, then when fullpressed, it starts the sync sequence and takes the photo about 200ms later (done with the microcontroller of course).
Started by PhyrePhoX General Chat
Started by PhyrePhoX Creative Uses of CHDK
Started by Microfunguy General Chat
Started by NN « 1 2 » Script Writing
Started by Pier92 RAW Shooting and Processing
