I try to get time stamps from a Canon S100 with CHDK, KAP script and a photo resistor. It works, but there are always 2 instead of one time stamps created, always some 1/10 of a second apart.
Thx, Tobias
Tobias,
What is the update rate on your Reach? How often do you trigger the camera?
I use the 5Hz settings you recommend for time marks in the documents.
I tried different trigger speeds, subsecond, 2, 3, and 5 seconds.
ok. Is that possible that your camera does some kind of a double flash? That might be an option.
I would think that the rising as well as the falling edge is counted as shutter release.
What happens if the time mark pin is pulled down longer than one epoche?
Well, the receiver will react to a either a falling or rising edge, so the pin being pulled down will not create more time marks. Also, the receiver will output only one time mark per navigation epoch. This points toward me thinking you actually have a double flash.
But the navigation epoche would be 200ms at 5Hz, right? What happens if the pin is pulled down 300ms?
I might need to double check this to make sure, but it should not produce an event as no edge will be detected.
I feel like checking what’s actually going on with an oscilloscope is the only way in this case.
I also thought about that and started searching for Arduino Oscilloscope.
Do you think that could work/help?
Could I probably “clean” the signal with the help of an Arduino which is watching for the trigger signal and is then pulling down a pin connected to the Reach module for e.g. 10ms? If it ignores further events for 2 seconds after the first event that should solve the problem and should not delay the timemark for a significant time periode? That yould be a workaround for “dirty” time mark signals?
What do you think?
1.8.3 Time mark
The NEO-M8T and LEA-M8T modules can be used for precise time measurements with sub-microsecond resolution using the external interrupt pins (EXTINT0 and EXTINT1). Rising and falling edges of these signals are time-stamped to GNSS or UTC time, counted and the results reported in message TIM-TM2. The reference time is the same as set for TIMEPULSE with CFG-TP5.
For more information see the u-blox 8 / u-blox M8 Receiver Description Including Protocol Specification [3].
I guess that describes the problem. A rising edge is timarked within the first epoche and a falling edge within the second epoche. The event must be extreamely short to avoid this behavior.
So, should he get an average of the two stamps?
No, there will be 2 timemarks. The a simple solution I would propose is to add an option to only process falling or rising edges.
Does those two timemarks have the same time? if the answer is no, which timemark is the one to chose? and why?
They do not have the same time. The second timemark is >200 ms (up to 2000 ms if the camera has some funny ideas) delayed.
In my case the first, falling edge is the right because the led fires the moment the shutter is released. Their might be cases where it is the other way round. So both options are necessary.
I’m curious, in which case the rising edge would be neccesary?
I use a Sony A6000, only one mark is recorded for a given event, so i don’t have eperience with this case of two marks.
E.g. if you have a system that releases the trigger after flashing an LED. Some Canon Kameras with CHDK have this behavior. Might be a very special case but since it is only some lines extra code I would include it anyhow.
How accurate do you need the timestamp to be (offset from the actual time picture is taken)?
Tobias,
Did you manage to find a workaround? I feel like maybe filtering the marks after the post-processing is done might be the best way to continue.
As accurate as possible with my cheap setup. I think it should be possible to get somewhere below 50 ms with a Canon S100. That would be 10 cm at 5 m/s.
