First of all, thanks for the great effort. I wish to know whether K5IIs, K-01, and K-3 supported as well?

I have a K-1 that I would like to run under INDI, so this will be something I can test when I get some time.

I'll give it a go - I have a K-70.
The deal breaker for me is the lack of bulb exposures for the K-70. It works with PKTrigger, but for some reason it's not working when using kStars/INDI (adapted from PKTrigger).

@TomAstro - The only cameras that Ricoh lists as "officially supported" by the SDK list are those in my first post. Obviously, the list is incomplete, but I only have the K-70 to test with. Frankly, I can't even verify that the officially supported cameras work. I'd be happy to test any cameras that anyone wants to buy for me, though .

@DrawsACircle - I totally understand the need for bulb. Right now I'm doing the User Mode 3 trick with the gphoto2 driver, where I set the exposure time in User Mode 3 and then set the Ekos exposure time to match it. But my biggest frustration with that (aside from having to go to the camera to change the exposure time) has been that it takes forever to get images back from the camera just for focusing. So Live View and lower resolution photos help out tremendously in that respect. And 30 seconds isn't too bad for stacking. I find that by the time I'm ready to try exposures longer than 30 seconds, I won't be changing the exposure length much more for the evening, so it's not too much of a hassle to go and do it manually on the camera.

But I'm still trying to find a way to get bulb to work, and pktriggercord is the only way that shows any promise. The problem with the INDI drivers is that they use gphoto2 as the middle-man. Even though gphoto2 is "adapted" from pktriggercord, something was lost in the translation, at least when it comes to the K-70. I'm looking at it more closely and seeing if I can bypass gphoto2. I can just call pktriggercord_cli and get an image, but I think a more reliable solution would be to call pktriggercord as a shared library or even just incorporate the code directly into the driver. Right now, I'm working on the shared library approach, as it would be easier to incorporate updates down the road.

My process is the same Karl, except from the focusing. I adjust focus with the camera disconnected from the RPi: bright star, liveview, bahtinov mask or just full zoom and adjust, set exposure time and ISO, connect.
I have been in contact with Andras (PKTrigger) and Marcus Meissner (gphoto2) with regards to the K-70, Andras has a K-70 - would be nice if the two of them could work together to make it work.
Or even better, if you could make it work with the Ricoh SDK
A user asked for a bulb mode fix for his K-70 and Oly OM-D E-5, a solution was created for the Olympus, the same could be made for the K-70: www.indilib.org/forum/development/4640-r...mark-ii.html?start=0
There's no problem with 1min+ exposures with the K-70, I usually keep the ISO at 800, no long exposure noise reduction etc. (everything turned off).

I was hoping if I dug deep enough into the SDK, I would figure out how to make bulb work, but I think that's a dead end unless we Ricoh updates the SDK.

But for good news, I have been playing with pktriggercord the last few days. Last night, I managed to wrap it into a shared library and got arbitrary bulb exposures to work in Indi as sort of a proof of concept. It's a bit more technical and finicky than the SDK--I'm constantly getting the camera into a bad state and having to power cycle it. And it's about twice as slow, both in changing settings and in downloading, though there may be a way to optimize that still. Anyway, I'll try to get something useable to test in the upcoming week or so.

Agree, I wouldn’t rely on Ricoh fixing a bug in the SDK or K-70 firmware.
Getting PKtriggercord merged with INDI would be fantastic, Andras Salamon is actively working on it from time to time.
I got this from him when I asked him about the bulb mode in PKtriggercord:

The new bulb mode is defined in the (creatively named) bulb_new method: github.com/asalamon74/pktriggercord/blob...cord-cli.c#L335-L352
The k_70 line in the pslr_model.c ( github.com/asalamon74/pktriggercord/blob...er/pslr_model.c#L980 ) defines which mode should be used.

The new bulb mode requires settings buffer (not status!) reading/writing. Camera specific field addresses can be found in this file: github.com/asalamon74/pktriggercord/blob...pentax_settings.json

I just pushed pktriggercord support to my fork. Building requires two libraries I also added to the fork: libricohcamerasdk and libpktriggercord.

I should probably test it myself on a different system before anyone else gets too involved in testing it, but I need to do a brain dump on what works and what doesn't before I forget.

For PTP mode (Ricoh SDK) with the K-70:
- Live View works
- All SDK supported settings (ISO, shutter, EC, WB, aperture, quality/resolution, image format, write to SD) work for all capture modes work except for bulb capture.
- Bulb capture does not work at all.

Similar results are expected for any other SDK-supported camera.

For MSC mode (pktriggercord) with the K-70:
- Bulb mode works with arbitrary shutter speeds
- Other modes work with their pre-defined shutter speeds
- Aperture, white balance, image format, and image quality work
- ISO and EC are implemented, but do not appear to work with the K-70
- There are some additional settings that could be implemented, but either they seemed like too much effort for too little reward, or did not work on the K-70 (e.g. resolution).
- Capture/download speed is about the same as the SDK. However, bulb mode captures are significantly slower than equivalent exposures in other modes (on the K-70 at least).
- Live View does not work. I'm not saying it's impossible, but even if I did get it to work, it'd be pretty slow (a frame every 4-5 seconds, perhaps).
- Countdown timer in Ekos doesn't really work at all right now, as the save_buffer method in pktriggercord has a while loop that's blocking everything. I need to explore the possibility of capturing in a different thread.

The MSC mode should support a wider variety of cameras than the PTP mode, and different cameras may perform better (or worse) than the K-70.

Well, there were a few unexpected bumps when I tried things out on various machines, but I think I've caught the major issues now. I wrote installation and operation instructions here: github.com/karlrees/indi-3rdparty/blob/m...ndi-pentax/README.md. Please let me know if you have any feedback.

I'm not sure if anything else is needed before I submit a pull request. Perhaps @knro could chime in. Perhaps something for debian packaging? I have no idea how that works.

Also, I had a few technical issues, and perhaps some enlightened mind out there with more experience than myself can advise me on them:

1) The Ricoh Camera SDK depends upon a custom version of libmtp with a version number of 9.3.0. Not surprisingly, this can and does cause problems if the standard version of libmtp is installed. To avoid these problems, I configured the requisite libraries to be installed in the "indipentax" subdirectory of CMAKE_INSTALL_LIBDIR. That subdirectory is then listed in the RPATH of the indi_pentax binary (not the RUNPATH, since libmtp is an indirect dependency). I'm sure this negatively affects the modularity of indi-pentax. I'm happy to take suggestions if there's a better way to deal with this issue. I also wonder if it would be better to install the libraries in /usr/local/lib/indipentax?

2) When compiled on Ubuntu Mate 18.0.4 (Raspberry Pi 3B), PTP mode does not work. I can't pinpoint exactly why, but based on my observations thus far, I suspect it's because the indi_pentax binary generated by the compiler on Ubuntu Mate is targeting armv7, whereas the library files provided by Ricoh are for armv6. Yet, I cannot figure out how to get indi-pentax to compile if I force the compiler on Ubuntu Mate to target armv6 (errors--something about thumb1--can't remember off the top of my head). A workaround is to use a binary generated on Raspbian, since those are for armv6 by default. However, not being familiar with how packages are generated, I am slightly worried about what binary StellarMate users will get (they're Ubuntu Mate, right?).

Hi Karl! That's pretty awesome! I've thought about getting a K1 but knew the drivers were going to be a hassle so I've waited. Marcus(gphoto) said the SDK WAS using closed drivers and would be difficult to work with. Starting from scratch is a daunting task too. BRAVO for you efforts!

This probably doesn't matter too much, but I just thought a little history might help.
I helped Marcus get the gphoto pentax driver going a while back and Marcus ended up wrapping to pktriggercord at that time.(so much testing!) Marcus bought himself a k10d to play with and between that and my k-50 he bashed out the current working driver, but we couldn't get past the wanky firmware issue with bulb in later models. Later Andras came up with that bulb fix for the k-70 for pktriggercord (a trick with the dual/single press menu) and we tried to get the k-50 to bulb using that new fix also without success. In the end I wound up buying a used K5(same exmor imx071 sensor) and have been using it with up to 20 minute exposures. You might get with Marcus over at libgphoto and let him know the pktriggercord k70 bulb fix isn't working with gphoto. he might also have some tips if he already got around it/updated it to pkt's new code.

Hey! There's an AP group at PF?

So when things move along a bit I'll for sure be able to give it a try with a K5 and a k50 --though probably on cloudy nights...which we've had plenty of lately.

Thanks for the insight. It would be nice if the SDK were open, but it works, and fills in some gaps that pktriggercord doesn't. It really wasn't too complicated--Andras already did the hard work reverse-engineering pktriggercord. Learning how to use the SDK was a piece of cake compared to that.

I had a little bit of time to pick this up again, and so I spent some time revisiting the driver today. I think I've reached a point on development where there's not really anything for me to add or fix for my personal usage, and I haven't had any feedback from anyone else, so I've decided to submit a pull request. Guess we'll see how it goes.

Right now there's an issue with the gphoto Pentax driver Indi does detect the camera, but you cannot connect.
I have created a ticket, Marcus has seen it, but I guess he's on vacation
github.com/gphoto/libgphoto2/issues/478