chdkptp - alternative ptp client - page 4 - General Discussion and Assistance

reyalp

13301

Re: alternative ptp client

« Reply #30 on: 18 / August / 2011, 23:24:26 »

Advertisements

Quote from: djdaugherty612 on 18 / August / 2011, 16:37:15

I finally got things to work, however. It seems the camera is sensitive to when you plug it into the usb port. If we plug in before chdk is loaded, bad things happen Thanks for your help.

Glad you got it working. That sounds like a bug, or at least something that could potentially be improved.

Does it have the problem if you power on the camera with the cable plugged in ? That's usually what I do, and I haven't noticed the kind of problem you describe.

Logged

Don't forget what the H stands for.

djdaugherty612

Re: alternative ptp client

« Reply #31 on: 22 / August / 2011, 18:08:35 »

Hmm...now I am not so sure what the cause of the problem was. It seems to work regardless of whether I power it on plugged in or wait to plug it in. I'll keep fiddling with it.

-drew

Logged

ntstatic

Re: alternative ptp client

« Reply #32 on: 14 / September / 2011, 08:26:19 »

hello dj,
i have been using ptp with the SX 130 and have never found any problems i have currently around 25 pcs and none have given the problem.
however if your camera is sensitive and hangs if you rapidly zoom in zoom out and capure from the ptp interface, turn off the continous auto focus. i have noticed that turning off the continous autofocus solves most of the hanging problems during a ptp session not only in the SX 130 but even in the 5 pieces of SX 120 that i used.

Logged

reyalp

13301

Re: alternative ptp client

« Reply #33 on: 27 / December / 2011, 14:57:38 »

From the ELF thread:

Quote from: waterwingz on 27 / December / 2011, 13:05:40

Quote from: reyalp on 26 / December / 2011, 20:46:01
Code: [Select]
.. ) | chdkptp -c -i ..

Should that be :

Code: [Select]
.. ) | chdkptp -c -e ..

No, the -i is correct. Even though it's taking input from a pipe, it's taking a sequence of "interactive" commands. -e executes a single command, so you could generate a -e"u ..." for each file.

Quote

In any case, there might be a problem with bombarding the ptp interface with repeated transfers ?

I found that there are problems if you invoke chdkptp multiple times in succession, it can fail to connect. Sending multiple commands to the input of one session should be fine.

My previous script worked like this:

Code: [Select]

#!/bin/bash
chdkptp -ec -e"u bin/DISKBOOT.BIN"
sleep 1
pushd core/modules
for f in *.flt ; do
 chdkptp -ec -e"u $f CHDK/modules/"
 sleep 1
done
popd

the sleep 1 was enough on my system, but YMMV

Logged

Don't forget what the H stands for.

waterwingz

12084

Re: alternative ptp client

« Reply #34 on: 27 / December / 2011, 17:23:12 »

Quote from: reyalp on 26 / December / 2011, 20:46:01

Code: [Select]
.. ) | chdkptp -c -i ..

changed it to

Code: [Select]

..
) | ./chdkptp -c -i
..

so that it would find chdkptp in the current directory. Once I did that it ran fine in the CHDK-Shell bash command shell environment.

Quote

I found that there are problems if you invoke chdkptp multiple times in succession, it can fail to connect.

That's what I found too - 3 to 5 invocations in a row is about all it will do. Putting a short or long sleep between calls did not help.

Logged

Ported : A1200 SD940 G10 Powershot N G16

051r15

21
SX40 HS

Re: alternative ptp client

« Reply #35 on: 08 / January / 2012, 22:55:03 »

Awesome reyalp! Can we expect a Mac port? Can I be of some assistance? I'd love to get ptp working with onlocation cs5 for Mac. Let me know if there is anything I can do. I'll be watching this and may start tinkering but two heads (or more) are always better than one!

Logged

reyalp

13301

Re: alternative ptp client

« Reply #36 on: 29 / January / 2012, 20:01:29 »

I've posted a new binary snapshot. An overview of the changes, along with links to binaries can be found at
http://www.assembla.com/spaces/chdkptp/wiki/Changelog

The main user-visible changes are
* Multiple file uploads / downloads, in both gui and CLI.
* Multiple camera support. Select which camera to control, and from the script api, control multiple cameras simultaneously.
* Improved performance functions that execute code on the camera.

The multi-file command options are somewhat clunky at the moment. They probably won't behave exactly what you'd expect if you are used to windows or linux command lines.

The build upload shell scripts discussed earlier can be replaced by
chdkptp -c -e"mup bin/DISKBOOT.BIN A/" -e"mup core/modules -fmatch=%.flt$ CHDK/MODULES"

There have been extensive changes under the hood, if you used local lua scripts (! command, or your own .lua files running locally) they will probably not be compatible.

@051r15
Missed your post the first time around. I don't have a Mac, so I don't have any particular plan to make a Mac port, but if someone else did the code I'd be happy to include it. I plan to convert to autoconf eventually, which should make it easier to build on any vaguely unix-like system.

I've heard differing reports about using libusb for PTP on Mac, but apparently some people have got it to work. At present, the IUP GUI library does not natively support Mac, but is reported to work X. chdkptp can also be built without the GUI.

Logged

Don't forget what the H stands for.

reyalp

13301

Re: alternative ptp client

« Reply #37 on: 12 / February / 2012, 02:07:21 »

New snapshot, changes in http://www.assembla.com/spaces/chdkptp/wiki/Changelog

This includes a very experimental module for controlling multiple cameras simultaneously. This is not exposed in the cli or gui, but you can use it with ! commands.

To test the level synchronization, I made a function (mc:testshots() that schedules a shots 300ms in the future, and then prints the time difference from the scheduled shooting time every 20ms. Aiming the cameras at the output gives you an idea how close together they shot.

There's a lot of room for error here: monitor/display refresh latency, latency between printing in a cmd window and having it show up etc. All that said, I think the results are not too bad. Over 4 shots, the time values shown varied by 40ms at most. This is no substitute for the usb remote sync, but good enough for if you want pictures at approximately the same time.

I'm not sure how it will scale to lost of cameras, but the sync accuracy shouldn't change. The time required to prepare shoot will increase.

Interestingly the d10 (on the right) had a lot more trouble shooting at the screen, and was also generally later than the a540.

ptpsynctest.jpg (95.38 kB, 459x1206 - viewed 362 times.)

« Last Edit: 12 / February / 2012, 02:14:29 by reyalp »

Logged

Don't forget what the H stands for.

Microfunguy

4037

Re: alternative ptp client

« Reply #38 on: 12 / February / 2012, 06:29:55 »

Quote from: reyalp on 12 / February / 2012, 02:07:21

Over 4 shots, the time values shown varied by 40ms at most.

For tethered indoor work that is OK.
For outdoor work and action we typically need a fraction of a ms.
For general outdoor work with moving people, vehicles,water,foliage, etc just a few ms.

There are reasons to believe cameras newer than the S95 have very poor synch, for unknown reasons.

Incidentally, my A620 does not return a serial number.

When you broadcast a message to multiple cameras, how do you handle their replies ?

Quote

reboot and reconnect fail with an error if they connect to a different camera, as detected by model name, product id and serial number (if available)

So, it is not possible to connect to my two A620's (and maybe other cameras) as they do not return a serial number ?

« Last Edit: 12 / February / 2012, 13:47:55 by Microfunguy »

Logged

reyalp

13301

Re: alternative ptp client

« Reply #39 on: 12 / February / 2012, 13:53:59 »

Quote from: Microfunguy on 12 / February / 2012, 06:29:55

For outdoor work and action we typically need a fraction of a ms.

That would be very difficult if not impossible to do with PTP

Quote

For general outdoor work with moving people, vehicles,water,foliage, etc just a few ms.

Anything less than 10ms would be very difficult, since there is not (AFAIK) a clock with greater resolution available on the camera. Even 10ms would be very hard, since the clocks on each camera wouldn't be synchronized.

Out of curiosity, how do you measure the accuracy of sync ?

One thing that could help is a script controllable delay where the wait_for_remote code is called.

Quote

Incidentally, my A620 does not return a serial number.

Yes, it appears older cameras don't return it. D10 does, A540 does not. If you were using a lot of cameras without, it would probably be useful to store a unique camera ID on the SD card or something...

Quote

When you broadcast a message to multiple cameras, how do you handle their replies ?

Loop over all the cameras checking for messages. This doesn't need to happen right away. (mc:wait_status_msg, which is called if you use mc:cmdwait)
So when you do a mc:cmdwait('preshoot') it sends the pre-shoot command to all the cameras, then waits for each one to send a message that indicating that get_shooting is true (or something failed)

Quote

So, it is not possible to connect to my two A620's (and maybe other cameras) as they do not return a serial number ?

No, it just won't notice if it connects to a different camera when you use reconnect or reboot. The issue is that the usb dev/bus can change when the camera is (it's not tied to the physical USB port). So if you reboot and try to reconnect, you might end up connected to a different camera.

the mc lib doesn't really care about uniquely identifying the cameras, it just connects to them all and identifies them by the order in which they were connected.

« Last Edit: 12 / February / 2012, 13:57:58 by reyalp »

Logged

Don't forget what the H stands for.