[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gphoto-kodak
Subject:    [gphoto-kodak] DC215 problems
From:       Mats Eriksson eraemmm () ki ! ericsson ! se
Date:       1999-12-17 8:23:06
[Download RAW message or body]

Hi !


I tried to use gphoto 0.4.2 with my Kodak DC215 and I got a lot of problems
with serial read timeouts.

When I looked in the Host Interface Specification and the source code
I noticed a few things.


* kodak_dc210_open_camera uses CRTSCTS in tcsetattr. However, the RTS
  and CTS signals are not connected to the camera.

* The Host Interface Specification says you should wait 100ms before
  sending further commands after a baudrate change.

* When a byte is lost during reception of a packet kodak_dc210_read
  times out and kodak_dc210_read_packet returns without sending a
  DC_CORRECT_PACKET or DC_ILLEGAL_PACKET to the camera.
  I believe this will cause the host to wait for the next packet while
  the camera still waits for a the acceptance or rejection of the corrupted
  packet.
  The Host Interface Specification says that if the camera receives a
  DC_ILLEGAL_PACKET after sending a packet the camera will resend the
  rejected packet.
  It seems more correct to send a DC_ILLEGAL_PACKET to the camera when
  kodak_dc210_read times out and then try to reread the corrupted packet.


It also seems a couple of things can be done to reduce the number of lost
bytes.

When the camera is sending a packet it is up to the host to keep up with
the cameras pace. When the camera is done with a packet it waits for the
host to accept or reject that packet. If the host has to deal with other
things during the reception of a picture it seems sensible to do that after
the reception of a packet but before sending the DC_CORRECT_PACKET to the
camera.
update_progress, however, is called immediately after sending
DC_CORRECT_PACKET.

The memory space in which a picture will be stored is mallocated just before
the picture is received. Using mlock or just accessing the pages in that
memory space before requesting packets could reduce paging activities during
the packet reception.


I have messed around with the source code and fixed the things above and it
works much more stable now. A few packets have to be resent if you start
resource demanding activities during picture reception, but the pictures
always arrive uncorrupted sooner or later.
Since I just want a line command to just download all the pictures from the
camera in one go, without any questions asked, my messy source code no longer
fits into gphoto so I haven't tried these fixes together with gphoto.


Mats Eriksson  (eraemmm@ki.ericsson.se)

[prev in list] [next in list] [prev in thread] [next in thread]