Battery drains due to polling on USB?

Post Reply
konrad
Posts: 4
Joined: Sat Jun 27, 2015 11:39 pm

Battery drains due to polling on USB?

Post by konrad » Sun Jun 28, 2015 1:03 am

Hi Istvan,great tool first - many thanks :-)I own a Nikon D5100, for this I have an Eyefi card which transfers the data wirelessly to a local server on my NAS, that fine, works most the time. But I would like to control my cam, not just uploading JPGs (only).As you see D5100, I do not have a chance for a WU adapter, so what next?Took a small Intel Edison board and dreamed to put it somewhere inside a extra battery grip, for a first view, these thigs should have enough space.Compiled DslrDashboardServer and moved it to the Edison, works fine, I can access the camera from my PC via my intranet and WiFi.But I noticed that my cam run out of battery unexpectedly fast (few hour without may shots). I noticed further the raw transfer starts, but for WiFi delivers broken files, local USB is OK. hmm ... Picked the CLI of gphoto2 on the Edison and could transfer the NEFs correcty. Conclusion, there must be something in the DigiCamControl transfer or with the interaction to ddserver which causes this.So, I saw the USB PTP Wireshark work at Nikonhacker, but this is limited to USB recording (tcpdump to usbmon on edison, transfer to PC) and it is hardly changeable, even based on an old Wireshark version.So I started to create a Wireshark lua dissector for the DCAM = DigiCamControl WiFi protocol and another one for the PTP of D5100, found some document at Nikonhacker for D5000 which seems to fit quit well. I did the script dissectors to the level I need, as it is a simple text file it can be easily extended, performance is somewhat reasonable, I expect not as fast as a compiled dissector, but fast enough to follow what is goind on.Now when running the DCC to my D5100 via ddserver on Edison (same for local USB) I saw the DCC polling the camera quite frequently, so disallowing the cam to go to sleepThe sequence is alwaysTransmission Control Protocol, Src Port: 58688 (58688), Dst Port: 4757 (4757), Seq: 3002, Ack: 5972, Len: 16DigiCamControl WiFi Protocol    Total length: 16    DigiCamControl Message        PTP Protocol for Nikon D5100            Length: 12            Type: Command (0x0001)            Code: GetEvent (0x90c7)            TransactionID: 0Transmission Control Protocol, Src Port: 4757 (4757), Dst Port: 58688 (58688), Seq: 5972, Ack: 3018, Len: 30DigiCamControl WiFi Protocol    Total length: 30    DigiCamControl Message        PTP Protocol for Nikon D5100            Length: 14            Type: Data (0x0002)            Code: GetEvent (0x90c7)            TransactionID: 0            Event Count:  0    DigiCamControl Message        PTP Protocol for Nikon D5100            Length: 12            Type: Response (0x0003)            Response: OK (0x2001)            TransactionID: 0 I had some headache to understand the concatenation of messages, first my impression was about the length that is is not set correctly, there are some bugs yes (extra bytes by ddserver, also ddserver is a bit weak in handling errors), but in general it is OK.The sequence above is almost everytime returning 0 events, when I press at camera release button for focus, I get events for exposure and shutter, but no Event frame (in opposite to Data frame)Transmission Control Protocol, Src Port: 4757 (4757), Dst Port: 58688 (58688), Seq: 8806, Ack: 4526, Len: 42DigiCamControl WiFi Protocol    Total length: 42    DigiCamControl Message        PTP Protocol for Nikon D5100            Length: 26            Type: Data (0x0002)            Code: GetEvent (0x90c7)            TransactionID: 0            Event Count:  2            Event: DevicePropChanged (0x4006)            Device property: ExposureTime (0x500d)            Event: DevicePropChanged (0x4006)            Device property: ShutterSpeed (0xd100)    DigiCamControl Message        PTP Protocol for Nikon D5100            Length: 12            Type: Response (0x0003)            Response: OK (0x2001)            TransactionID: 0When I do a shot, I also don't see an event frame. For local USB it is dfferent, here I see the same polling, but in case of a shot I get an Interrupt URBUSB URB    USBPcap pseudoheader length: 27    IRP ID: 0xffffe001591814f0    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)    URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009)    IRP information: 0x01, Direction: PDO -> FDO    URB bus id: 1    Device address: 1    Endpoint: 0x83, Direction: IN    URB transfer type: URB_INTERRUPT (0x01)    Packet Data Length: 16    [Request in: 3117]    [Time from request: 0.002001000 seconds]    [bInterfaceClass: Imaging (0x06)]PTP Protocol for Nikon D5100    Length: 16    Type: Event (0x0004)    Event: ObjectAdded (0x4002)    TransactionID: 4294967295    SD Card Object handle: 0x29190006For USB on Edison I also don't see the Interrupt URB, looks like the respective endpoint is not opened.When I check the viewfinder in case local USB connected I see the display of exposure time etc always on, same I see when there is just USB connection without a tool connected, but in this case there is no polling.Can you comment on the power consumption topic, whether you expect this to be due to the active polling or whether you expect this to be just because of the connection. In first case it might be an option to better deal with the Interrupt/Event handling, so saving battery for a longer standby time, especially in case of a WiFi connection.A second question out of my initial research on transferring RAW images, I see that the transfer is started, a file of correct size is transferred, just the content is corrupt in case of WiFi, local USB is fine. Do you have an idea why this is like that? Technically I do not see a reason. I see the big write operation to the WiFi, so the ddserver seems to assemble the URBs correctly. Next step for me now will be to check what is really going to be transferred. I could iamgine that there is some loss in the depth of USB on the Edison for these high volume transfers, then why is gphoto2 behaving correctly.For your reference I have attached the two dissectors.  . 

Battery drains due to polling on USB?

Advertisment
 

konrad
Posts: 4
Joined: Sat Jun 27, 2015 11:39 pm

Transfer RAW

Post by konrad » Sun Jun 28, 2015 5:31 pm

made a next try, recorded what is given to WiFi, this is exactly the PTP:DATA:RAW data|PTP:RESPONSE:OK. Extracting the RAW data from this message gives a valid NEF file, so the USB transfer is correct and also correctly forwarded.

Duka Istvan
Posts: 867
Joined: Tue Mar 26, 2013 9:52 pm

The Nikon don't fire any

Post by Duka Istvan » Sun Jun 28, 2015 9:30 pm

The Nikon don't fire any event when capture set to transfer PC, so required time to time (20 time in one seconds) to execute  getEvent command but this command return data not trigger any event. Maybe there some error when data reading is executed in DCC side. If you know some C# you can check this code : https://github.com/dukus/digiCamControl ... ntainer.cs

konrad
Posts: 4
Joined: Sat Jun 27, 2015 11:39 pm

RAW Transfer by WiFi up!

Post by konrad » Fri Jul 03, 2015 1:45 am

Some progress... the raw transfer via WiFi is working now. My solution was with ddserver on the Edison. First I had to understand what was going wrong, from kernel the libusb_bulk_transfer got an E_NO_MEM error which then aborted the transfer, which resulted in DigiCamControl ddserver client to read FFFFFFF for length which is going to an error in the transfer, so RAW transfer aborted, some data remained within the camera which againg made further conenction requests to the cam also failing as teh command seems to get some corrupt data.When tarcing the traffic I could see that teh second half of packets on the WiFi link was filled by 0 ... could see in random cases running DCC under c# debugger.From the NOMEM I concluded first that kernel memory on the Edison is configured to small, but /proc/slabinfo did not show any anormalities.Remembering that libusb is using usbfs made me searching for configuration for size of the "file system". After some journey there was a note about "usbfs_memory_mb" which is the size in MegaByte of the USB FS. the parameter is available from sysfs/sys/module/usbcore/parameters/usbfs_memory_mbChecking it on Edsion revealed 16, so 16 MB which is sufficient for JPGs (8MB with D5100) but for RAW it does not fit (20 MB D5100).Now the lucky part, I could change this on the fly, so setting to a maximum of 48 MB, and imemdiately I could transfer RAW shots.As I saw the same issue on a laptop (which I did not check yet) and a lot of discussions around on Internet, I think this info is valueable for others.This was the error for ddserver / dslrdashboardserver by the called libusb (set debug to 4 for libusb)libusb: 0.000000 error [submit_bulk_transfer] submiturb failed error -1 errno=12libusb: 0.153825 warning [do_sync_bulk_transfer] unrecognised status code 1  . 

Post Reply