Reading camera clock / more accurate timer? - page 2 - Script Writing - CHDK Forum  

Reading camera clock / more accurate timer?

  • 12 Replies
  • 5307 Views
*

Offline reyalp

  • ******
  • 13449
Re: Reading camera clock / more accurate timer?
« Reply #10 on: 06 / August / 2013, 16:26:51 »
Advertisements
From your later post it sounds like you might have figured most of this out, but just in case...
none of my delays will be very long... I was only testing it with long delays to see if the math was working right. I will probably never have any more than 200mS delay.. in fact most of them would me much less, like around 60mS... so I'm wondering.. could I perhaps use set_yield as suggested?  I can't really tell what the min/max values are for this.. but could I set it for say 400000 instructions or push the time out to 200mS?
You can use -1,-1 if you want to control all yielding yourself. Note that if you don't yield periodically using sleep or one of the other functions that implicitly yields, camera function may be impaired. The exact limits are not well explored, and probably depend on the camera and what it is doing.
Quote
also is there any way to know how long until the next yield, or if just came back from one?  that way I could start my entire procedure at just the right time and be done before any yielding happens..
Anything that yields should reset both the counters, so a sleep(10) prior to starting your procedure would make sure you were starting at the beginning.
Quote
these questions could be irrelevant however... because my intention is to use the motion detector, then light some leds in sequence with specific delays after motion is detected, and I suspect the motion detector will be depending on things happening during the yield such as reading the sensor.
md_detect_motion yields from script, since the actual motion detection is done in C code. It will return control when motion is detected, or there is a timeout. However, the reaction time of MD is likely to be 100ms or more with significant variation since it's based on reading and comparing values from the viewfinder framebuffer.
Don't forget what the H stands for.

Re: Reading camera clock / more accurate timer?
« Reply #11 on: 06 / August / 2013, 16:39:47 »
thanks for the info.. just for fun I increased my yielding numbers and it did work, and was even faster, however after about 4 or 5 cycles through my program, the camera just shut off, presumably because as you mentioned something that it needed to happen didn't happen... I changed it to reset for 1 full second between re-starts and it ran over 100 cycles without the unexpected shutdown problem. 

I'll try it with the -1,-1 as you suggest for the timing part of my script then turn it back on when it's done and see how that work.. that seems like it would be better than trying to guess how many instructions I will need.

I'm wondering if there is something I can do besides motion detection for my water drop detector... perhaps I could aim a red laser pointer at my camera, but instead of just hitting the lens with it, put a diffuser over the lens.. then just monitor the red intensity of just the relevant part of the sensor, and the instant it falls below some threshold because the water drop got in the way, make it exit immediately and continue the script. seems like that would react pretty fast, although I have no clue on how to implement that..   Anyone have any input on this idea?


*

Offline reyalp

  • ******
  • 13449
Re: Reading camera clock / more accurate timer?
« Reply #12 on: 06 / August / 2013, 17:11:58 »
I'm wondering if there is something I can do besides motion detection for my water drop detector... perhaps I could aim a red laser pointer at my camera, but instead of just hitting the lens with it, put a diffuser over the lens.. then just monitor the red intensity of just the relevant part of the sensor, and the instant it falls below some threshold because the water drop got in the way, make it exit immediately and continue the script. seems like that would react pretty fast, although I have no clue on how to implement that..   Anyone have any input on this idea?
You can set up the MD code to only monitor a specific area of the frame buffer. If it's a small region, the over head of the actual detection should be negligible. You can also control what channels are monitored, but the default (Y, luminance) will be more efficient than an RGB color.

However the sensor is only read out at some fixed frame rate for live view. This is probably something like 30 FPS under normal conditions (just guessing, I've never tried to measure it), and likely less in low light.

The MD code runs in the same task as script, so it can only check every 10ms at most. This isn't synchronized with sensor readout, so there will be additional uncertainty. I think an additional iteration is required before control returns to script.
Don't forget what the H stands for.

 

Related Topics