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

USB Remote Switch in CHDK - version 2 implementation thread

  • 220 Replies
  • 80400 Views
*

Offline pigeonhill

  • *****
  • 1164
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #120 on: 16 / January / 2013, 16:32:28 »
Advertisements
Waterwingz

As usual thanks for the clarification. When I bracket I do so in manual focus mode.  As said before, no big deal in having to do a half press each time.

Thanks for the functionality!

Cheers

Garry
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #121 on: 16 / January / 2013, 17:41:04 »
Quote from: pigeonhill on 16 / January / 2013, 16:32:28
When I bracket I do so in manual focus mode.  As said before, no big deal in having to do a half press each time.
The half press isn't really for the focusing - I may have mislead you there. 

Its required because the camera needs to be set to shoot with its settings locked in  (valid half press) before  CHDK can override the Canon settings.  If you go straight to a full press, there is no chance for CHDK to insert the override.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline pigeonhill

  • *****
  • 1164
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #122 on: 16 / January / 2013, 18:03:25 »
Now I've got it! Fully understand and also you have helped me better understand some scripts I have been looking at.

Cheers

Garry
Logged
*

Offline hendrix

  • *
  • 15
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #123 on: 18 / March / 2013, 15:54:33 »
I have been trying chdk version 1.2 for a long time now and one thing i find consistent is the
get_usb_power() inconsistency.
I am not complaining i just want to report the problem i found with CHDK 1.2 (latest) in a SX230HS.
The input pulses are dead accurate but the measurements  are always short sometimes
as much as -10 for an input pulse width of 300ms (instead of 30 i get 20)
With the addition of a sleep(300) or more in the get_usb_power() loop things get much better.
I have spread out the window limits so this script works even without the sleep(300) command.
BTW i have disabled all chdk features like osd, zebra, histogram, temperature info etc, so essentially i use chdk
as a lua script interpreter only.
Here is the script:

z = get_zoom_steps()
s = z/6
h = z-s
a = 0

repeat

   repeat
      a = get_usb_power()
      sleep(300)
   until a>0

   if a <=7 then
     
--      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")
      a = 0

   elseif a <=19 then

          if get_zoom() <= h then set_zoom_rel(s) end
          a = 0

   elseif a <= 35 then
           if get_zoom() >= s then set_zoom_rel(-s) end
           a = 0

   elseif a <= 55 then
           click("video")
           a = 0

   end

until (false)

Chris

 
« Last Edit: 18 / March / 2013, 16:06:39 by hendrix »
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #124 on: 18 / March / 2013, 16:52:18 »
Curious.

Can you give me a better idea of the range of "a" when you are sending a 300 mSec pulse ? Both with and without the sleep(300).

Also, does the reading also get better if you use sleep(50)  ( like it does when you use sleep(300)  )?

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline hendrix

  • *
  • 15
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #125 on: 18 / March / 2013, 17:24:12 »
Hi.
Without any sleep(x) in the loop a vary from -5 to -10 for a 300ms pulse so sometimes (very rear) an input of 300ms will cause the code to perform a zoom in instead of a zoom out if i have a value of a = 20 instead of 19
"elseif a <=19 then ...."
With a=19 the code performs flawless.
With a sleep(50) things are better by -2 to -5 but i have to check this again as my memory is not that good any more.
I decide to use a sleep(300) as a precaution and i didn't measured the error since the camera control is flawless.
It looks like the error gets bigger as the input pulse gets longer.
I will perform some tests tomorrow because i need to connect the video output from the usb cable to a tv in order to see the printout of the a value ( print(a) ).
I use an 11 pin usb cable i made in order to feed video to a video transmitter and control the camera so when i plug the usb cable to the camera the lcd screen goes black and i can't see the printout.
Chris
« Last Edit: 18 / March / 2013, 17:31:01 by hendrix »
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #126 on: 18 / March / 2013, 18:09:01 »
Hmmm ... a much bigger variation than I would have expected just based on the pulse measurement being done at a 10 mSec sampling rate.   

And if the error gets bigger with longer pulses,  this also suggests that the keyboard task is not running every 10mSec as expected.

I'll do some testing on my cameras although first I'll need to figure out how to generate an accurate 300 mSec pulse.  I guess I can use the 150 mSec pulse from my CA-1 to start with.


Here's something you can do to avoid messing with the whole video feed thing.  Put the following statement at the start of your code and every print statement will be logged to a file on your SD card :

print_screen(1)

http://chdk.wikia.com/wiki/CHDK_scripting#print_screen


Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #127 on: 11 / May / 2013, 18:41:58 »
Quote from: hendrix on 18 / March / 2013, 15:54:33
I have been trying chdk version 1.2 for a long time now and one thing i find consistent is the get_usb_power() inconsistency.
Okay - I finally got enough gear together to get back to this question and actually test things out. 

I hooked up my raspberry pi and a piface extension board. 


A little bit of code turns this into a configurable pulse generator.
Code: [Select]
#include <stdio.h>
#include <unistd.h>
#include <libpiface-1.0/pfio.h>
#include <wiringPi.h>
#include <sys/time.h>

int main( int argc, char *argv[] )
{
    if (pfio_init() < 0)
        exit(-1);
    if ( argc != 4 )
    {
       printf(" usage :  pwm pulsewidth spacewidth pulsecount\n") ;
       exit(-1);
    }

    int i, pulse, space, count;

    pulse = atoi( argv[1] ) ;
    space = atoi( argv[2] ) ;
    count = atoi( argv[3] ) ;
   
    printf("Started... pulse=%d ms, space=%d, repeats=%d  \n", pulse, space, count);
   
    for (i = 0; i < count ; i++)
    {
        pfio_write_output(0x80);
        delay(pulse);
        pfio_write_output(0x00);
        delay(space);
    }
    printf("...done.\n");

    pfio_deinit();
    return 0;
}

Attached a butchered USB cable,  add an trusty old analog oscilloscope and voila - instant test setup.



With a simple Lua script running on the camera, I can generate pulses with the raspberry pi and monitor them from the camera screen.

Code: [Select]
--[[
@title USB Tester
--]]

function printf(...)
    print(string.format(...))
end

set_console_layout(1, 1, 44, 10)
pcount=0
scount=0

repeat
   x=get_usb_power(2)
   now = get_day_seconds()
   if (x ~= 0 ) then
       if ( x > 0 ) then
           printf("%02d:%02d  %d mark=%d", now/3600, now%3600/60, pcount, x)
           pcount = pcount+1
       else
           printf("%02d:%02d  %d space=%d", now/3600, now%3600/60, scount, -1*x)
           scount =  scount+1
       end
   end
   sleep(100)
until false

I then ran a variety of pulse width, pulse space, repeat patterns etc on my G10,  A1200 and IXUS120_SD940.

And the result was pretty boring.  All cameras worked exactly as expected.   If I gave them 50mSec pulses they reliably reported a pulse width of "5". Every time.   A 250 mSec pulse was always reported as 25 and a 1 sec pulse came out at 100.

Exactly as expected.

As I had everything setup anyway,  I ran the pulse width down to 10mSec.  All three cameras caught ever pulse and reported it as a "1".   So I changed the pulse width to 5 mSec.   At that point the cameras started missing pulse - which is to be expected given that the USB remote code only runs on a 10 mSec interval.

One final experiment .. I fed 25 mSec pulses to the cameras.   They reported 2 or 3 as the pulse width at about a 50% rate for each number.  Again, exactly as expected.

So I guess I'm not sure why hedricks is having problems but I'm sure its not the USB remote code.  That's rock solid.

Update : I loaded my A1200 with the script that hedricks posted and used the test setup to send single pulses over the specified range.  I added a print statement to hedrick's code to tell me what the script was seeing. Again - rock solid response and the print statement gave a value for each pulse that was exactly what was expected.

Pulse Width
Min   Max         Result
10     70           Camera shoots
80    190           Zoom out
200  350           Zoom in
360  550           Video mode
560   -              Ignored







« Last Edit: 11 / May / 2013, 19:22:52 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Andre-K

  • **
  • 55
USB PWM measurement loses precision after photo(s) - a bug, or bad code ?
« Reply #128 on: 27 / January / 2014, 14:38:24 »
I am feeding 3 different pulses to the camera, 20, 50 , 70ms.
The three work fine, reliable.

That is, until I uncomment the call "Shoot()" function - once it takes a photo, the pulse width feature goes bananas, detecting any of the modes randomly.

Two questions:
Is there something fishy with the "Shoot" function ?
Is LUA, or a bug within the script overloading the cameras CPU, (in case pulse width feature is software-based) ?



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(50) 
    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 < 3 )  --looking for 20ms "low/shoot"
--         if ( x > 1 and x < 3 and last ~= 1)  --looking for 20ms "low/shoot"
then
last=1
printf("shooting, "..(x*10).." mSec")
Shoot()
end

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

if ( x > 3 and x < 6 )  --looking for 50ms "high/mode"
-- if ( x > 3 and x < 6 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


Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: USB PWM measurement loses precision after photo(s) - a bug, or bad code ?
« Reply #129 on: 27 / January / 2014, 14:58:36 »
Quote from: Andre-K on 27 / January / 2014, 14:38:24
I am feeding 3 different pulses to the camera, 20, 50 , 70ms. The three work fine, reliable. That is, until I uncomment the call "Shoot()" function - once it takes a photo, the pulse width feature goes bananas, detecting any of the modes randomly.
There was a somewhat related conversation about this last year. 
http://chdk.setepontos.com/index.php?topic=7127.msg98003#msg98003
As discussed in that thread, I was never able to reproduce the issue in my testing.

Maybe this sheds some light on the issue.   
Quote
Two questions: Is there something fishy with the "Shoot" function ? Is LUA, or a bug within the script overloading the cameras CPU, (in case pulse width feature is software-based) ?
The pulse width measurement code is entirely software-based.  Even worse, it operates on a polling basis, checking the USB power state every 10 mSec when the keyboard task runs.    If the camera is busy with a shoot() then its quite possible that the measured pusle width of any pulse occurring just before, during, or right after a shoot() will be wrong.

Does the pulse width measurement settle down after the shoot or is it wrong forever after that?
« Last Edit: 27 / January / 2014, 15:00:30 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 ... 8 9 10 11 12 [13] 14 15 16 17 18 ... 23   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal