USB Remote Switch in CHDK - version 2 implementation thread - page 15 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 10 11 12 13 14 [15] 16 17 18 19 20 ... 23   Go Down

USB Remote Switch in CHDK - version 2 implementation thread

  • 220 Replies
  • 63869 Views
*

Offline waterwingz

  • ******
  • 12132
    • Waterwingz
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #140 on: 28 / January / 2014, 09:06:00 »
Advertisements
Quote from: Andre-K on 28 / January / 2014, 09:00:36
I will do do more testing today, and also make a video, that will illustrate the problem properly, and let us read more of the values that fly by.  - we could go for writing a log, but I think causing more load might be the wrong thing to do now.
Please test on your other Canon camera(s) too ?  The fact that it seems to work on four different cameras for me says we are either doing something different with how the pulses are generated, how we are testing, or there is something borked on your S110.   Having you test on your S95 might answer many of these questions.

If the pulse widths always get longer once this starts, its possible that something else is getting activated when the shoot occurs and its making the camera - or at least the keyboard task where the script engine lives - very busy on the S110.  Something stuck in the action_stack for example, although that code is common to all camera and mine don't exhibit the problem.   I suppose a look at kbd.c for the S110 is in order - once I know if the S95 works or not (ignoring that the S110 might be a C&P from the S95).
« Last Edit: 28 / January / 2014, 09:19:58 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Andre-K

  • **
  • 55
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #141 on: 28 / January / 2014, 09:16:54 »
Will test on one S110  , two S95.
Logged
*

Offline Andre-K

  • **
  • 55
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #142 on: 28 / January / 2014, 13:15:44 »
before making this video, I increased the sleep time before sampling to 200ms , hoping that could increase precision.  - it did:

http://youtu.be/wqh4Fodx76g   is made with this code:

Code: [Select]
--[[
@title USB Tester
 
@param m Mode
   @default m 0
   @values  m State Width Pulses Count Key
 
--]]
 
function printf(...)
    local tic = get_day_seconds()
    print (string.format("%02d:%02d:%02d %s", tic/3600, tic%3600/60, tic%60, ...))
end
 
 
function StartStopVideo()
    local rec, vid = get_mode()
    local vid_button = get_video_button()
    if rec == true and vid == true  and vid_button == 0 then
        press("shoot_full")
        sleep(300)
        release("shoot_full")
    elseif rec == true and vid_button == 1 then
        click("video")
    end
end


function Shoot()
press("shoot_half")
repeat sleep(50) until get_shooting() == true
press("shoot_full")
sleep(500)
release("shoot_full")
repeat sleep(50) until get_shooting() == false
release("shoot_half")
end

mode = m
set_console_layout(1, 1, 44, 10)   --console position x1,y1,x2,y2
last=2  -- 1=low 2=med 3=high
 
print("PWM remote")
 
set_config_value(121,1) -- make sure USB remote is enabled
 

scount=0
usb_state=-1
rkey=0
 
repeat
    sleep(200) 
    x=get_usb_power(0)
--[[
        if ( x == 0)  --nothing new since last time
then
if (last==1)
then
printf("REPEAT, width ="..(x*10).." mSec")
--Shoot()   --repeat until switch centered
sleep(50)
end
        end
--]]   
       
        if ( x > 1 and x < 9 )  --looking for 20ms "low/shoot"
--         if ( x > 1 and x < 9 and last ~= 1)  --looking for 20ms "low/shoot"
then
last=1
printf("shooting, "..(x*10).." mSec")
Shoot()
end

-- if ( x > 10 and x < 19 and last ~= 2)  --looking for 70ms "neutral/center"
if ( x > 10 and x < 19 )  --looking for 70ms "neutral/center"
then
last=2
printf("center, "..(x*10).." mSec")
end

if ( x > 20 and x < 30 )  --looking for 50ms "high/mode"
-- if ( x > 20 and x < 30 and last ~= 3)  --looking for 50ms "high/mode"
then
last=3
printf("mode, ="..(x*10).." mSec")
--StartStopVideo()
end
 
until is_pressed("menu")
 
set_config_value(121,0) -- make sure USB remote is disabled
fed with 20ms , 150ms , 250ms.

same thing,  except one "minor" change:
I removed the pause before get_usb_power, things got worse.

Code: [Select]
repeat
    --sleep(200)
    x=get_usb_power(0)
at(logtime) 20:01:31  - it even trigged, I did not send the 20ms pulse.
150ms seems to be detected as ~110 (-40ms off)  , 250ms seems to  be 170ms  (-80ms off)
after log 20:02:22 - I stopped feeding it pulses, to see if a pause helped.. no it did not.

http://youtu.be/6Fg7DAJLoQc
Code: [Select]
repeat
    --sleep(200)
    x=get_usb_power(0)


----
now S95 (x2)

S95 does not seem to have a bigger problem after picture.  But it's less accurate before picture as well.
Running the script with no delay, produces the same, lower measurement phenomenon :)

 http://youtu.be/4kp5FWsAZqs


Firmware used was: s95-100k-1.2.0-3338-full_BETA  and s100-102a-1.2.0-3338-full_BETA

Regarding workload, I disabled GPS, no change.

Update of the S100 research, there's no difference in 200ms delay, and 50ms delay  both delays give at mostly an error of "only" 20ms , - except the big difference with no delay.
both 200ms and 50 ms results
« Last Edit: 28 / January / 2014, 14:54:44 by Andre-K »
Logged
*

Offline waterwingz

  • ******
  • 12132
    • Waterwingz
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #143 on: 28 / January / 2014, 16:33:09 »
Quote from: Andre-K on 28 / January / 2014, 13:15:44
before making this video, I increased the sleep time before sampling to 200ms , hoping that could increase precision.  - it did:
Interesting.   I'll look more closely at that tonight and see what happens with no sleep() on my cameras.
Quote
Update of the S100 research, there's no difference in 200ms delay, and 50ms delay  both delays give at mostly an error of "only" 20ms , - except the big difference with no delay.both 200ms and 50 ms results
The polling function that measures pulse width runs every 10 mSec,  so you could have an error of 20 msec if you just miss one the start of pulse and then just miss the end of pulse.  Typically you will get the correct pulse width most of the time but occasionally you will be out by 10 mSec.  20 mSec errors should be very rare.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Andre-K

  • **
  • 55
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #144 on: 28 / January / 2014, 16:47:53 »
I achieved reliable detection of three "commands" , by narrowing down the detected min/max limits to "pulsetime -/+ 20ms". Hooray, the project can move on.  :)
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #145 on: 28 / January / 2014, 17:25:15 »
@WW
If you'd like to try something that is likely to be more accurate than SleepTask() based timing, take a look at this: http://chdk.setepontos.com/index.php?topic=10114.msg109695#msg109695
Note that the required fw addresses are available in funcs_by_address.csv / funcs_by_name.csv.

About the keyboard task's timing:
The cycle time in task_PhySw depends on a variable in newer cameras, example:
Code: [Select]
static void __attribute__((noinline)) mykbd_task_proceed()
{
while (physw_run){
_SleepTask(physw_sleep_delay);

if (wrap_kbd_p1_f() == 1){ // autorepeat ?
_kbd_p2_f();
}
}
}
Logged
*

Offline waterwingz

  • ******
  • 12132
    • Waterwingz
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #146 on: 28 / January / 2014, 18:54:01 »
Quote from: srsa_4c on 28 / January / 2014, 17:25:15
@WW
If you'd like to try something that is likely to be more accurate than SleepTask() based timing, take a look at this: http://chdk.setepontos.com/index.php?topic=10114.msg109695#msg109695
Note that the required fw addresses are available in funcs_by_address.csv / funcs_by_name.csv.
I saw that earlier today.  Its not clear to me how you would use it to time USB pulse widths though. Without some sort of interrupt,  you are stuck with polling for the 0V->5V and 5V->0V transistions.  Having an accurate timer function (even with callbacks) does not help much with the polling process.  Or am I (again) missing something?

Quote
About the keyboard task's timing:
The cycle time in task_PhySw depends on a variable in newer cameras, example:
Code: [Select]
static void __attribute__((noinline)) mykbd_task_proceed()
{
while (physw_run){
_SleepTask(physw_sleep_delay);

if (wrap_kbd_p1_f() == 1){ // autorepeat ?
_kbd_p2_f();
}
}
}
Not just newer cameras - a quick grep shows that the A495 (from 2010) uses this.  On closer inspection, the other cameras just use a hard coded 10 msec instead of physw_sleep_delay for the call to _SleepTask.  The value of physw_sleep_delay seems to be available via the sigfinder for most cameras so this seem to just be a porting implementation issue.

Which leads us to the possible option of running the kbd task more frequently to increase precision.  For most of the things CHDK does,  +/- 10 mSec precision is probably adequate.  But it might still be an interesting even though it would add a small additional load to the processor and tend to make scripts run faster without fooling with the yield settings. 

Maybe a new Lua function :   kbd_task_speed( msec ) ?

« Last Edit: 28 / January / 2014, 18:56:16 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12132
    • Waterwingz
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #147 on: 28 / January / 2014, 19:47:09 »
Quote from: Andre-K on 28 / January / 2014, 16:47:53
I achieved reliable detection of three "commands" , by narrowing down the detected min/max limits to "pulsetime -/+ 20ms". Hooray, the project can move on.  :)
So my conclusion from all of this is as follows. 

If you pound away at get_usb_power() in a tight loop in Lua,  it's possible to add so much processor load that the underlying code in the kbd.c task does not actually monitor the USB power status every 10 mSec.   Different cameras seem to run scripts at different speeds so the magnitude of the error will change.

It's still a mystery to me why this only starts after the first shot taken by your script. Especially as your script has a 50 msec sleep in each loop iteration - which should have been plenty.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Online reyalp

  • ******
  • 13878
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #148 on: 28 / January / 2014, 23:52:44 »
Quote from: waterwingz on 28 / January / 2014, 18:54:01
Which leads us to the possible option of running the kbd task more frequently to increase precision.
It's not clear how you'd do this, since SleepTask() operates in 10ms increments. Also, kdb_task calls a bunch of the original canon keyboard code, so calling it more often might have unexpected side effects.

Quote
If you pound away at get_usb_power() in a tight loop in Lua,  it's possible to add so much processor load that the underlying code in the kbd.c task does not actually monitor the USB power status every 10 mSec. 
Unless you've fiddled with set_yield, this should be quite unlikely.
Quote
It's still a mystery to me why this only starts after the first shot taken by your script. Especially as your script has a 50 msec sleep in each loop iteration - which should have been plenty.
If the loop actually yields every iteration (I haven't traced through Andre's code to make sure) then there's really no chance that the Lua script is causing too much load.
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12132
    • Waterwingz
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #149 on: 29 / January / 2014, 00:12:51 »
Quote from: reyalp on 28 / January / 2014, 23:52:44
Quote
If you pound away at get_usb_power() in a tight loop in Lua,  it's possible to add so much processor load that the underlying code in the kbd.c task does not actually monitor the USB power status every 10 mSec. 
Unless you've fiddled with set_yield, this should be quite unlikely.
Quote
It's still a mystery to me why this only starts after the first shot taken by your script. Especially as your script has a 50 msec sleep in each loop iteration - which should have been plenty.
If the loop actually yields every iteration (I haven't traced through Andre's code to make sure) then there's really no chance that the Lua script is causing too much load.
I'm open to other avenues to explore.  His code works on my cameras but jittter increases when I remove the sleep command in the loop.  It does not work on his S110. 

I assume that get_usb_power() does not explicitly yield. 

After two nights of testing, I have nothing else to offer.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 ... 10 11 12 13 14 [15] 16 17 18 19 20 ... 23   Go Up
« previous next »
 

Related Topics