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

USB Remote Switch in CHDK - version 2 implementation thread

  • 220 Replies
  • 83484 Views
*

Offline koshy

  • *****
  • 1096
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #200 on: 06 / August / 2014, 07:52:01 »
Advertisements
These very neat switches are my favourite, and not just because I was given a development sample :-

https://www.flickr.com/photos/fvdk3d/sets/72157624151791739/
Thanks. They look good. I think I'll get in touch with the fellow.
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)

Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #201 on: 07 / August / 2014, 09:56:37 »
Just for fun ... or deep ignorance
could it be possible to sync an external flash via usb?

Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #202 on: 07 / August / 2014, 10:58:53 »
Just for fun ... or deep ignorance
could it be possible to sync an external flash via usb?
The simple answer is "no".  USB is a" master-slave " protocol and the camera always acts as the slave. So in simple terms it can't originate communications, it can only answer. The flash unit is in that sense a slave too and two slaves can't talk to each other.

If you want to fire a remote flash from your Powershot you can use the camera's built-in flash with the power set to low via CHDK to fire a remote optical trigger attached to the remote flash unit.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 4451
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #203 on: 01 / January / 2015, 11:17:47 »
I have a question: how is USB remote set to "onepush, normal" supposed to behave on a camera with dedicated video button? I'm getting the same result on the sx280 and the ixus115: when the camera is in one of the movie modes, applying power to USB starts a recording which then can't be stopped with buttons or the remote. Is this a camera specific bug or am I missing something?

edit:
All buttons become unresponsive except for the "ON/OFF" button (which is not in KEYS_MASKx).
CHDK 1.3 r3449 on the sx280, 1.4 r3863 on the ixus115.
« Last Edit: 01 / January / 2015, 11:34:34 by srsa_4c »

*

Offline reyalp

  • ******
  • 14125
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #204 on: 01 / January / 2015, 17:21:30 »
Don't forget what the H stands for.

Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #205 on: 08 / February / 2015, 17:02:01 »
I've spent the last couple of days looking at how sync shooting with multiple cameras is currently implemented in CHDK Remote V2 code.

It looks like a few complications have slipped into the code as hacks to allow things like multicam and ptp shooting have been added.  And these hacks only work when things in the CHDK menus (like sync) are enabled.  While menu values can be bypassed via set_config_value(), this should probably not be required when shooting via a script.

So after a bit of refactoring and some testing, I have a patch file with a few cleanups that should help.  Basically,  the changes remove some unnecessary interlocks and delete code in action_stack.c that never should have interacted with the sync logic in the first place.  It also adds a new script function usb_sync_wait( ) for Lua and uBASIC that can be called before each shot to enable sync on that shot when used in conjuction with usb_force_active( ).  This will allow full script control of sync'd shooting without any CHDK menu settings necessary.   This was briefly discussed here : Faster Sync Triggering?

A revised test version of the script originally posted here Faster Sync Triggering? is also attached.

tl;dr : new sync code for using two or more cameras

Update : script removed - see later posts
« Last Edit: 09 / February / 2015, 19:33:08 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14125
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #206 on: 08 / February / 2015, 20:31:07 »
Looks good to me. Haven't tested actual sync, just the usual cable plug/unplug.

Only one tiny issue:
Code: [Select]
+static int luaCB_usb_sync_wait( lua_State* L )
+{
+  usb_sync_wait_flag = on_off_value_from_lua_arg(L,1);
+  return 1;
+}
Return is the number of values returned to Lua, so should return 0 since the function does not provide any return values with lua_push*.
Don't forget what the H stands for.

Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #207 on: 08 / February / 2015, 20:40:22 »
Return is the number of values returned to Lua, so should return 0 since the function does not provide any return values with lua_push*.
Thanks.  Thought briefly about returning the current value prior to applying the new value ( as it's basically free ) but then could not find a reason to think that would actually matter.
Ported :   A1200    SD940   G10    Powershot N    G16

Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #208 on: 09 / February / 2015, 19:38:00 »
Using the new patch turned out to be slightly harder than I thought.  I rewrote the test script to remove all the set_config_value() calls and ran smack into the issue where the camera switches from shooting mode to playback mode automatically when the USB 5V's is asserted (and USB Remote mode is not enabled).

After a brief panic,  I remembered the switch_mode_usb(1) function was a better choice than set_record(1) for this application,

Updated script attached.

Edit : struck out the incorrect sentence
« Last Edit: 09 / February / 2015, 22:47:18 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14125
Re: USB Remote Switch in CHDK - version 2 implementation thread
« Reply #209 on: 09 / February / 2015, 22:09:41 »
After a brief panic,  I remembered the switch_mode_usb(1) function was a better choice than set_record(1) for this application,
set_record actually does the same thing as switch_mode_usb if usb power is present when it is called.

I wouldn't assume you get correct behavior by using switch_mode_usb and than toggling USB power later. switch_mode_usb has some side effects too, so it would probably be better to mask the USB power completely.
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal