supplierdeeply

CHDK PTP interface

  • 1136 Replies
  • 148538 Views
*

Offline reyalp

  • ******
  • 9879
  • Publish
    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 »
    Don't forget what the H stands for.

    *

    Offline reyalp

    • ******
    • 9879
    « Last Edit: 03 / July / 2012, 01:54:20 by reyalp »
    Don't forget what the H stands for.

    *

    Offline philmoz

    • *****
    • 2936
      • Photos
  • Publish
    Re: CHDK PTP interface
    « Reply #812 on: 03 / July / 2012, 05:36:52 »
    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.
    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)

    *

    Offline srsa_4c

    • ******
    • 3118
  • Publish
    Re: CHDK PTP interface
    « Reply #813 on: 03 / July / 2012, 09:19:28 »
    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...


    *

    Offline reyalp

    • ******
    • 9879
  • Publish
    Re: CHDK PTP interface
    « Reply #814 on: 03 / July / 2012, 13:16:03 »
    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.
    Don't forget what the H stands for.

    *

    Offline philmoz

    • *****
    • 2936
      • Photos
  • Publish
    Re: CHDK PTP interface
    « Reply #815 on: 03 / July / 2012, 20:24:18 »
    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.
    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)

    *

    Offline srsa_4c

    • ******
    • 3118
  • Publish
    Re: CHDK PTP interface
    « Reply #816 on: 03 / July / 2012, 22:07:30 »
    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 »

    *

    Offline reyalp

    • ******
    • 9879
  • Publish
    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 »
    Don't forget what the H stands for.


  • Publish
    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

    *

    Offline msl

    • *****
    • 1173
    • A720 IS, SX220 HS 1.01a
      • CHDK inside
  • Publish
    Re: CHDK PTP interface
    « Reply #819 on: 04 / July / 2012, 16:04:46 »
    « Last Edit: 04 / July / 2012, 16:06:30 by msl »
    German CHDK pages:  CHDK forum | CHDK inside | CHDK Twitter News by msl | Download CHDK-DE (Autobuild)
    Note: SDM violates the GPL rules!

     

    Related Topics