Adding Pentax K-3 Support

twang2218 commented 8 years ago

I'm creating this issue, so we can centralize the related discussions here.

While K-3 inherits a lot from K-5 series, the internal has some differences. K-3 has a new image processor, PRIME III, which might be the reason why there is a byte order changes in the communication between computer and camera.

I forked the master branch and created a 'k3' branch, targeting on K-3 porting, at here: https://github.com/twang2218/pktriggercord/tree/k3

Porting are not finished yet. Here are some findings.

Byte Order

This is the example of communication different between K-5 and K-3:

 [C]            read_result(0x3, size=28)
 [S]                     >>> [F0 49 00 00  1C 00 00 00]
-[S]                     <<< [00 00 00 01  00 00 00 00  01 00 01 00  03 E0 00 00 
+[S]                     <<< [01 00 00 00  00 00 00 00  00 01 00 01  00 00 00 00 
                          00 00 00 00  00 00 00 00  00 00 00 00]

[C] is function call, [R] is what returned from the call, and [S] are the SCSI command communications.

As you can see, the cmd of scsi_read() and scsi_write() is still Little-Endian, however, the payload, buf, are in Big-Endian on K-3.

That is the reason why using ipslr_identify() read the camera id, it will get the reverse order of the ID of K-3.

 [C]            read_result(0x3, size=8)
 [S]                     >>> [F0 49 00 00  08 00 00 00]
-[S]                     <<< [00 01 2E 76  00 00 01 F9]
-[R]                 => [00 01 2E 76  00 00 01 F9]
-   id of the camera: 12e76
+[S]                     <<< [C0 2F 01 00  F6 01 00 00]
+[R]                 => [C0 2F 01 00  F6 01 00 00]
+   id of the camera: 12fc0

However, this is only true for read_status() and _ipslr_write_args(), not for get_result(), which still be the same byte-order of cmd, Little-Endian.

 [C]            get_result(0x3)
 [S]                     >>> [F0 26 00 00  00 00 00 00]
-[S]                     <<< [BC 01 00 00  00 00 01 00]
-[R]                 => [BC 01 00 00]
-   read 444 bytes
-   expected_bufsize: 444
+[S]                     <<< [C4 01 00 00  00 00 01 00]
+[R]                 => [C4 01 00 00]
+   read 452 bytes
+   expected_bufsize: 452

Lomo Effect

For some reason, when I use pktriggercord-cli, I have to turn off and on of the camera between shoots, otherwise, I will retrieve the same photo, but with more lomo effect on it.

http://imgur.com/19rRiQl

I tried the GUI interface pktriggercord, it looks fine. Thomas Lehmann said he didn't have this issue. I don't know, maybe it's just my camera, or there are some differences between CLI and GUI interface internally.

Some of X10 Subcommands are not working

Thanks to Thomas Lehmann, he found X10_BULB, X10_GREEN and X10_CONTINOUSare not working anymore. I looked into the problem, and found that, for those 3 X10 subcommands, camera will return 0x81 error code, which might be 'Invalid Command', and the rest X10 subcommands seems ok. As the error code has been returned, the program will keep trying until it returns 0, or it loops forever.

cont: 0
bulb
[C] pslr_bulb(1)
[C]         _ipslr_write_args(cmd_2 = 0x0, {0x1})
[S]                  >>> [F0 4F 00 00  04 00 00 00]
[S]                  >>> [01 00 00 00]
[C]         command(fd=3, 10, d, 4)
[S]                  >>> [F0 24 10 0D  04 00 00 00]
[C]         get_status(0x3)
[S]                  >>> [F0 26 00 00  00 00 00 00]
[S]                  <<< [00 00 00 00  00 00 00 81]
[R]              => ERROR: 0x81
[S]                  >>> [F0 26 00 00  00 00 00 00]
[S]                  <<< [00 00 00 00  00 00 00 81]
[R]              => ERROR: 0x81
[S]                  >>> [F0 26 00 00  00 00 00 00]
[S]                  <<< [00 00 00 00  00 00 00 81]
[R]              => ERROR: 0x81
...

I don't know what should I do next. Could you tell me how to dig further? How to find the right subcommand for Bulb, Green and Continuous shooting? Thanks.

Regards, Tao

asalamon74 commented 8 years ago

Lomo effect

The GUI and the command line calls the same methods but there are a few differences. The GUI uses a more complex way to delete the buffer. Please check the preview_delete_button_clicked_cb method and the autodelete part of the auto_save_check method. The GUI refreshes the status buffer till the camera reports back the delete, and sometimes it even calls the delete multiple times. Maybe this part should be added to the command line.

twang2218 commented 8 years ago

I wrote a Pentax SCSI communication protocol documentation based on bootcoder's (@PentaxForum.com) discovery in the firmware, and my understanding of the pktriggercord code. The document is not finished yet, I will keep update it as more findings come up. I hope this discovery journey can help us understand the problem of K-3's X10 commands issue.

https://github.com/twang2218/pktriggercord/blob/protocol/pentax_scsi_protocol.md

Could you have a look on the protocol document? Just let me know if you found anything need to be changed/added before I send a pull request of it. Thanks.

asalamon74 commented 8 years ago

Great documentation. I'd be happy to add it to the project. A few suggestions:

An intro sentence would be great to mention that their is no official Pentax documentation. I've been asked for it quite a few times.
1.1 It seems to me 0x49 0x4f codes are mixed here.
2 I think 49 should be replaced by 4F.
Maybe it worth mentioning that X1 and Y1 are always 0 (because the buffer is very small).
3.1 This is really useful list of the commands. There are a few new ones I'll test. I also realize that I might clean up my code a bit. Maybe you could emphasize that 0x18 commands can be used for changing the attributes. It is not clear from the current version of the documentation if it's for writing or reading the arguments.
I think [00 08] is one of the most important command since it returns the status buffer (a few hundred bytes) representing the settings of the camera. Maybe one or two sentence could emphasize it.

I think I add a link to this file from the homepage just to help other developers.

twang2218 commented 8 years ago

Done, I added those information in the document, and sorry for mixed up with 0x49 and 0x4F command in the first place.

For [00 08], I may add more details later, I haven't summarized the status data, offsets/type/fields, across different cameras, but I think it's very useful.

We located [10 07] Green(), [10 0C] Continuous() and [10 0D] Bulb() functions in the firmware, the initial analysis shows those functions maybe not exist anymore, those commands may be for other purpose now. But more analysis need to be done later to make sure.

lgm-k3 commented 8 years ago

Hello First an introduction as this is my first post. I have been fiddling with and using Pentax cameras for years. Currently my attention is occupied with a K-3, early first version with 1.21 OS.

When I used to work before Father Time said I had to stop I worked with scientific imaging and had a lot to do with expensive instruments for image analysis, customer user interfaces and numerous logic problems with control software. When this job was done I had to teach customers how everything worked perfectly.............

I just ran up pktriggercord and had all sorts of problems. So, Raspberry pi 3, Debian or Windows 7 home 32bit. Results were, as far as I can guess, the same across all three. The programme kept locking and camera writes were failing. In some cases both the computer and the camera software crashed. My K-10D behaved similarly and we all know this works well with previous tether software.

Trying to find some answers I started randomly clicking the interface. No help there. Next I started swapping lenses and cameras modes so Takumar, M, K, AF and DA and most of the photography modes that the cameras have. It was clear, the software only works almost properly but reliably with a DA lens. AF lenses partly work and the rest do not although they may produce an odd picture.

It is clear that a lot of solid work has gone into cracking Pentax's code of secrecy about this camera. Can I help some more please? I think this camera is worth the effort. I do not want to ( and probably can not) start a new fork.

My current thinking is that the software GUI is not reacting to the lens type which the camera reports. This is resulting in failed, inappropriate communication and software hang ups at both ends of the triggercord. The DA lenses work because they have an answer for everything so no hang ups.

Best wishes,

Laurence

asalamon74 commented 8 years ago

Hi,

Do you have the same problem using K-3 and K-10D? It indicates that it's not a K-3 specific problem.

If you suspect a GUI problem I suggest trying the command line interface. Does it work?

The GUI uses the min. and max. aperture info read from the camera, it might cause problems if these values are incorrect. What is the output of the following command for a working DA and for a non-working K lens?

pktriggercord-cli --debug --status_hex

lgm-k3 commented 8 years ago

Hi, ok. Pls Give me a few days to work through this in full. Laurence

asalamon74 / pktriggercord