USB Remote Switch in CHDK - version 2 implementation thread - page 14 - General Discussion and Assistance

Andre-K

Re: USB PWM measurement loses precision after photo(s) - a bug, or bad code ?

« Reply #130 on: 27 / January / 2014, 16:31:44 »

Advertisements

Nice, I failed to find anything related when searching forum.
Maybe I am wrong, but I don't expect the get_usb_power to do anything while the script is in function Shoot() - I see that as an call, not as an separate thread.
After the picture is taken, the measurement of pulsewidth is messed up. and time does not seem to heal it.

I will try a lot lower precision, waste some responsiveness on making it respond to 1..99 100-199 and 200m-300ms

I guess it can't that bad, that 50ms, 150ms , and 250 ms pulses will be confused.

Is there a way to see CPU load ? - I'd like to verify that this script/method is not making the problem worse for each picture.

Logged

Andre-K

Re: USB PWM measurement loses precision after photo(s) - a bug, or bad code ?

« Reply #131 on: 27 / January / 2014, 17:03:15 »

Additional info, I switched to sending 150ms , accepting (100-190ms).
Detected pulsewidth (after first picture) vary between 150-240ms.

BTW: after each pulse (high) - I have a 100ms low period.

Logged

Andre-K

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #132 on: 27 / January / 2014, 17:08:26 »

Anyone found a solution, or a workaround?
I started out sending 20ms , and accepting 1..50 , then 51...90 and so on,
but even 150 ms gets detected as 150..240 after the first picture have been taken. Before that, the detection is very reliable.

Is counting pulses more reliable ? (provided that I do not prefer that any command takes >200ms) , and need at least three different commands.

Logged

waterwingz

12121

Re: USB PWM measurement loses precision after photo(s) - a bug, or bad code ?

« Reply #133 on: 27 / January / 2014, 17:09:16 »

Quote from: Andre-K on 27 / January / 2014, 16:31:44

Is there a way to see CPU load ? - I'd like to verify that this script/method is not making the problem worse for each picture.

There is actually a pretty detailed debugging mode built into the USB remote code. I left that in when I did the V2 stuff but it's not built into the standard releases. I'll test this tonight and see if I can reproduce what you see on my cameras (now that I know shooting messes things up on your camera) and then figure out what's wrong.

@reyalp / philmoz : would you mind moving this thread to the end of the v2 remote thread ?

« Last Edit: 27 / January / 2014, 18:35:46 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

13621

Re: USB PWM measurement loses precision after photo(s) - a bug, or bad code ?

« Reply #134 on: 27 / January / 2014, 17:19:05 »

Quote from: waterwingz on 27 / January / 2014, 17:09:16

would you mind moving this thread to the end of the v2 remote thread ?

Merged. It just goes by date order of the posts.

Logged

Don't forget what the H stands for.

waterwingz

12121

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #135 on: 27 / January / 2014, 17:49:25 »

Quote from: Andre-K on 27 / January / 2014, 17:08:26

Is counting pulses more reliable ? (provided that I do not prefer that any command takes >200ms) , and need at least three different commands.

The mechanism that counts pulses is basically part of the same code that measures pulse width. When the 5V to 0 V transition occurs, the length of the pulse width is calculated and the pulse count is incremented. I need to discover why the pulse width is wrong before I can comment on the reliability of pulse counting.

Logged

Ported : A1200 SD940 G10 Powershot N G16

waterwingz

12121

Re: USB PWM measurement loses precision after photo(s) - a bug, or bad code ?

« Reply #136 on: 27 / January / 2014, 19:16:39 »

Quote from: Andre-K on 27 / January / 2014, 17:03:15

Additional info, I switched to sending 150ms , accepting (100-190ms).
Detected pulsewidth (after first picture) vary between 150-240ms.
BTW: after each pulse (high) - I have a 100ms low period.

Are you sending a single pulse? Or a continuous waveform of pulses?

I just tried this simplified version of your script on my A1200. I feed it single pulses from my Arduino that I can set in 10 mSec increments. In every case, the camera reports the pulse width correctly (+/- 10 mSec).

Code: [Select]

--[[
@title PWM Tester
--]]

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

set_console_layout(1, 1, 44, 10)
print("USB pwm test started")
set_config_value(121,1) -- make sure USB remote is enabled
count=0
repeat
    x=get_usb_power(0)
    if ( x > 0 ) then 
        print("width ="..(x*10).." mSec") 
        count=count+1
        if (count == 5 ) then 
            Shoot() 
            count=0
        end
    end
    wait_click(100)
until is_pressed("menu")
set_config_value(121,0) -- make sure USB remote is disabled

Update 1 : modified my Arduino script to sent a continuous pulse train of 150 msec ON, 100 msec OFF. The camera still correctly reports 150 mSec pulse width.
Update 2 : Repeat the test on my G10. Same result.

Update 3 : Tested your posted script on both my A1200, SD940, G10 and my SX50. Works perfectly on each of them. Arduino sends 20 mSec pulse, script reports 20 mSec pulse and takes a shot. No matter how often I repeat the process, same result. Sending a 50mSec pulse or 70mSec pulse causes the script to report 50 or 70 (respectively) every time.

Puzzling. It seems that either there is something strange about the CHDK port for your camera or maybe your pulse source is not doing what you expect?

« Last Edit: 27 / January / 2014, 21:09:12 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

Andre-K

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #137 on: 28 / January / 2014, 02:42:56 »

As long you only look for 20ms this does not surprise me,
please make it print detected pulse width continuously - it may be that you see 20ms hits, but not all the other numbers ?
I print them at a rate of ~8 /sec

(That's how I "discovered" this problem, I had 3 subs and 3 messages, "shoot, centre, mode" , and everything worked fine until I added the code to shoot)
BTW: I don't know if it's possible to restart lua completely, but it does *not* help to stop script, even run a .bas script, then restart this script - it will still be off, AFAIK until camera is rebooted.

waterwingz: I tried a single pulse on each mode change at first, some were missed, so I changed the code to repeat the pulse every 100ms, that is, this is not a true PWM with 100ms period. I just send 20ms, then 100 - or 70, then 100.
BTW: this is on a well working Powershot S100. - I can test this on S95 if you wish.

« Last Edit: 28 / January / 2014, 04:32:12 by Andre-K »

Logged

waterwingz

12121

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #138 on: 28 / January / 2014, 08:42:36 »

Quote from: Andre-K on 28 / January / 2014, 02:42:56

As long you only look for 20ms this does not surprise me, please make it print detected pulse width continuously - it may be that you see 20ms hits, but not all the other numbers ? I print them at a rate of ~8 /sec

I'm sorry if my updates were not clear. I also tested using your script (with the shoot code uncommented) and continuous pulses that changed between 20, 50, 70, 100 msec with a 100 msec gap between each pulse. Every time the camera received a 20 mSec pulse it would "shoot" and 50 or 70 mSec pulses would print the specified message on the camera LCD. There was no change in detected pulse width accuracy afterwards.

Quote

BTW: I don't know if it's possible to restart lua completely, but it does *not* help to stop script, even run a .bas script, then restart this script - it will still be off, AFAIK until camera is rebooted.

Do the measured pulse width change after each shoot, and does it stay consistent until the next time? For example, does a 50 mSec pulse that always report 50 mSec at first, then report 80 mSec every time after the shoot, then maybe 30 mSec after the following shoot? Or does the reported pulse time become random after the first shoot?

Also, does the error in reported pulse width always seem to make the pulse width longer than it is? Never shorter?

Its a long shot, but maybe on the S100 something is changing the Lua yield? As reported at the very last line of here, changing yield values will change reported pulse width. This is a serious bug if so.

Quote

waterwingz: I tried a single pulse on each mode change at first, some were missed, so I changed the code to repeat the pulse every 100ms, that is, this is not a true PWM with 100ms period. I just send 20ms, then 100 - or 70, then 100. BTW: this is on a well working Powershot S100. - I can test this on S95 if you wish.

As discussed above, I believe this is exactly what I also did - on four different cameras released at different dates over the last 5 years. And they all worked correctly.

It would be good to know if your S95 (or your other two Canon P&S cams?) work or not.

Logged

Ported : A1200 SD940 G10 Powershot N G16

Andre-K

Re: USB Remote Switch in CHDK - version 2 implementation thread

« Reply #139 on: 28 / January / 2014, 09:00:36 »

Quote from: waterwingz on 28 / January / 2014, 08:42:36

Do the measured pulse width change after each shoot, and does it stay consistent until the next time? For example, does a 50 mSec pulse that always report 50 mSec at first, then report 80 mSec every time after the shoot, then maybe 30 mSec after the following shoot? Or does the reported pulse time become random after the first shoot?

It seems like the pulse time is mostly becoming longer, not shorter.

Thank you again for looking into this, it's very important to me, as it's the only way for me to have a simple, yet powerful communication with the camera.

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.

Logged