CHDK PTP interface - page 82 - General Discussion and Assistance - CHDK Forum
supplierdeeply
« previous next »
Pages: 1 ... 77 78 79 80 81 [82] 83 84 85 86 87 ... 125   Go Down

CHDK PTP interface

  • 1240 Replies
  • 449941 Views
*

Offline reyalp

  • ******
  • 14000
Re: CHDK PTP interface
« Reply #810 on: 03 / July / 2012, 01:00:34 »
Advertisements
Another thought: Can we reproduce the problem with ps_uploader mentioned here: http://chdk.setepontos.com/index.php/topic,1632.msg14806.html#msg14806

File is available in ps_uploader at https://www.box.com/chdk#/chdk/1/55270403

edit:
We don't know the canon protocol of course, a range of files sizes near one of the magic numbers might be worthwhile.

edit:
I can't seem to get it to recognize my a540 though...
« Last Edit: 03 / July / 2012, 01:08:29 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14000
Re: CHDK PTP interface
« Reply #811 on: 03 / July / 2012, 01:45:27 »
« Last Edit: 03 / July / 2012, 01:54:20 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3449
    • Photos
Re: CHDK PTP interface
« Reply #812 on: 03 / July / 2012, 05:36:52 »
Quote from: reyalp on 03 / July / 2012, 01:45:27
Other ideas
http://biot.com/blog/usb-sniffing-on-linux
http://lxr.linux.no/#linux+v2.6.28.8/Documentation/usb/usbmon.txt

edit:
http://wiki.wireshark.org/CaptureSetup/USB

Found it :)

While researching how USB PTP transfers work I came across this:
A bulk transfer is considered complete when it has transferred the exact amount of data requested, transferred a packet less than the maximum endpoint size, or transferred a zero-length packet.

When the chdkptp code sends a file/message that is exactly a multiple of the maximum end point size (512) the camera is still waiting for the bulk transfer to be completed. In this case it is necessary to send another 0 length packet to terminate the transfer.

The modified ptp_usb_senddata code below works on my cameras.

Code: [Select]
uint16_t
ptp_usb_senddata (PTPParams* params, PTPContainer* ptp,
unsigned char *data, unsigned int size)
{
static uint16_t ret;
static PTPUSBBulkContainer usbdata;

/* build appropriate USB container */
usbdata.length=htod32(PTP_USB_BULK_HDR_LEN+size);
usbdata.type=htod16(PTP_USB_CONTAINER_DATA);
usbdata.code=htod16(ptp->Code);
usbdata.trans_id=htod32(ptp->Transaction_ID);
memcpy(usbdata.payload.data,data,
(size<PTP_USB_BULK_PAYLOAD_LEN)?size:PTP_USB_BULK_PAYLOAD_LEN);
/* send first part of data */
ret=params->write_func((unsigned char *)&usbdata, PTP_USB_BULK_HDR_LEN+
((size<PTP_USB_BULK_PAYLOAD_LEN)?size:PTP_USB_BULK_PAYLOAD_LEN),
params->data);
if (ret!=PTP_RC_OK) {
ret = PTP_ERROR_IO;
/* ptp_error (params,
"PTP: request code 0x%04x sending data error 0x%04x",
ptp->Code,ret);*/
return ret;
}
    if (size > PTP_USB_BULK_PAYLOAD_LEN)
    {
        /* if everything OK send the rest */
        ret=params->write_func (data+PTP_USB_BULK_PAYLOAD_LEN,
                    size-PTP_USB_BULK_PAYLOAD_LEN, params->data);
        if (ret!=PTP_RC_OK) {
            ret = PTP_ERROR_IO;
    /* ptp_error (params,
            "PTP: request code 0x%04x sending data error 0x%04x",
                ptp->Code,ret); */
        }
    }
    if ((usbdata.length & 0x1FF) == 0)
        params->write_func(data, 0, params->data);
    return ret;
}

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #813 on: 03 / July / 2012, 09:19:28 »
Quote from: philmoz on 03 / July / 2012, 05:36:52
Found it :)

While researching how USB PTP transfers work I came across this:
A bulk transfer is considered complete when it has transferred the exact amount of data requested, transferred a packet less than the maximum endpoint size, or transferred a zero-length packet.

When the chdkptp code sends a file/message that is exactly a multiple of the maximum end point size (512) the camera is still waiting for the bulk transfer to be completed. In this case it is necessary to send another 0 length packet to terminate the transfer.

Nice find.  :)

I've tested it with 0x3f as the magic value (still testing with a USB1.1 (or full speed ?) camera), and it really fixes the issue in question. (I now get "unexpected msg type" sporadically while running reyalp's msgtest)
Am I correct that the current implementation assumes "high speed" connection? I've found a define named PTP_USB_BULK_HS_MAX_PACKET_LEN in ptp.h . According to my web search this originates from some libgphoto related code(?). I've also found PTP_USB_BULK_FS_MAX_PACKET_LEN on the web in a project named arducam-osd which assumes full speed instead (which is understandable since it's Arduino-related).

I guess the connection speed could be detected somehow, and that magic value could be based on the connection type. I do not know the libusb code enough to tell how to do that...
Logged
*

Offline reyalp

  • ******
  • 14000
Re: CHDK PTP interface
« Reply #814 on: 03 / July / 2012, 13:16:03 »
Quote from: philmoz on 03 / July / 2012, 05:36:52
Found it :)

While researching how USB PTP transfers work I came across this:
A bulk transfer is considered complete when it has transferred the exact amount of data requested, transferred a packet less than the maximum endpoint size, or transferred a zero-length packet.
Excellent :)

My impression (not knowing much about USB...) is that the ptpcam code is pretty rough if a number of ways.
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3449
    • Photos
Re: CHDK PTP interface
« Reply #815 on: 03 / July / 2012, 20:24:18 »
Quote from: srsa_4c on 03 / July / 2012, 09:19:28
Quote from: philmoz on 03 / July / 2012, 05:36:52
Found it :)

While researching how USB PTP transfers work I came across this:
A bulk transfer is considered complete when it has transferred the exact amount of data requested, transferred a packet less than the maximum endpoint size, or transferred a zero-length packet.

When the chdkptp code sends a file/message that is exactly a multiple of the maximum end point size (512) the camera is still waiting for the bulk transfer to be completed. In this case it is necessary to send another 0 length packet to terminate the transfer.

Nice find.  :)

I've tested it with 0x3f as the magic value (still testing with a USB1.1 (or full speed ?) camera), and it really fixes the issue in question. (I now get "unexpected msg type" sporadically while running reyalp's msgtest)
Am I correct that the current implementation assumes "high speed" connection? I've found a define named PTP_USB_BULK_HS_MAX_PACKET_LEN in ptp.h . According to my web search this originates from some libgphoto related code(?). I've also found PTP_USB_BULK_FS_MAX_PACKET_LEN on the web in a project named arducam-osd which assumes full speed instead (which is understandable since it's Arduino-related).

I guess the connection speed could be detected somehow, and that magic value could be based on the connection type. I do not know the libusb code enough to tell how to do that...

Attached is a patch to the current chdkptp trunk that attempts to get the maximum endpoint size from the libusb data and use that to determine if the dummy packet needs to be sent.

Can you try this with your camera and see what happens.

I have no idea if this is the right way to do this sort if thing -  I'm still trying to understand the whole USB PTP interface stuff.


Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #816 on: 03 / July / 2012, 22:07:30 »
Quote from: philmoz on 03 / July / 2012, 20:24:18
Attached is a patch to the current chdkptp trunk that attempts to get the maximum endpoint size from the libusb data and use that to determine if the dummy packet needs to be sent.

Can you try this with your camera and see what happens.
The recognition of the max packet size works well for the two "full speed" cameras I tried.
After testing them with reyalp's msgtest, the results are:
A410 (DIGIC II, full speed)
Fails at length=0x34 (camera does not become unstable), works with any other length (tried up to 520). Note that as I reported earlier, length=0x34 was not problematic on this camera. (Hmmm, looks like a need for special casing some models...)
A420 (DIGIC II, full speed)
Max packet size recognition correct, msgtest runs correctly with any length.
A470 (DIGIC III, full speed)
Works with any length, but I get random "unexpected msg type" showstoppers while running msgtest. These start to be an issue over length>200. Camera does not become unstable, the test can be restarted. Previously, all lengths of (n*0x40)-0xc were problematic.
Ixus65 (DIGIC II, high speed)
Max packet size recognition correct, msgtest runs correctly with any length.

edit: host controller USB2.0, OS Linux 32bit

A separate note: the test with msgtest runs much slower on DIGIC II cameras, no matter full or high speed.

Quote
I have no idea if this is the right way to do this sort if thing -  I'm still trying to understand the whole USB PTP interface stuff.
Looks good enough to me.
« Last Edit: 03 / July / 2012, 23:28:18 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 14000
Re: CHDK PTP interface
« Reply #817 on: 04 / July / 2012, 01:14:45 »
Great work.

One thing I noticed, PTP_USB_BULK_PAYLOAD_LEN was based on the old hard coded max_packet_size. I'm not clear if this actually matters anywhere, the first send in send_data might send more than one packet, but I'm not sure there's anything wrong with that.

ptp_usb_getdata looks similar.

I think the "unexpected msg type" error is an unrelated problem. I get it on D10 as well. That is probably the something failing in the msgtest script, which returns an error rather than user message, which msgtest doesn't understand.

edit:
I checked in philmoz patch in chdkptp changeset 258. Leaving the debug print in for now so people can see what size it's detecting. I think getting wMaxPacketSize is correct.

edit:
the "unexpected" message I get is "not enough memory"

edit:
Fixed in trunk 1950/release 1951. This should make anything that relies on sending ptp messages a lot more stable  :-X

edit:
with this change, a540 runs msgtest from 1 to 10000 with no problems
d10 died with a lost ptp connection after over 9000, not clear why
sending 9204 (0x23f4)...unexpected return code 0x2ff
« Last Edit: 04 / July / 2012, 03:19:05 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline cgott4242

  • *
  • 17
Re: CHDK PTP interface
« Reply #818 on: 04 / July / 2012, 15:53:15 »
I have 2 SD1100IS cameras and have ptpgui working.  It enables me to shoot photos (remote shutter release) and d/l files.
I don't see a live view function
or a way to control multiple cameras

Does the PTPcam do these things?  if not, which software does?

thx
Logged
*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: CHDK PTP interface
« Reply #819 on: 04 / July / 2012, 16:04:46 »
« Last Edit: 04 / July / 2012, 16:06:30 by msl »
Logged
CHDK-DE:  CHDK-DE links
Pages: 1 ... 77 78 79 80 81 [82] 83 84 85 86 87 ... 125   Go Up
« previous next »
 

Related Topics