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, except for bulb mode, which is significantly slower on the K-70 at least.
- 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.
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.
@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.
There's a software toggle between TCP and UDP on the EXOS2. I've just been using TCP.
With the EXOS2, the driver would receive an unexpected and nonsensical response every now and then while slewing. That threw the driver off, and the driver would timeout. Packet sniffing seemed to indicate that it was coming from the mount, but it never happened using ExploreStars, so we couldn't figure out what the deal was. Anyway, I modified the code to just discard the response and then it worked fine. I wonder if the iEXOS-100 is doing something similar, but at a different time, such as during the initial handshake.
When I need a good physical polar alignment, the only thing I do is use the polar scope along with the PolarisView app on my phone to figure out the appropriate rotation of the alignment guide in the polar scope. I often end up resyncing after the first slew and every now and then after that, but it at least gets me within a few degrees, so my target is typically at least within the field of view of my low-power lenses. I think part of the problem is just that I'm pushing the weight limit. Most of the time, though, I'm plate solving, so I'm not really needing pinpoint accuracy, and I keep my Pi powered and connected throughout the night anyway.
I was reading your first posts more closely, and slewing to the entirely wrong part of the sky sounds like a problem with the time or location. That could happen for a number of reasons, such as a misconfiguration of the mount driver. I ended up having a lot of sporadic problems with slewing to below the horizon and other very wrong positions with an older GPS dongle (circa 2009). I eventually realized that, depending on when the GPS signal was initially acquired, the GPS daemon was returning the right location but the wrong year (more specifically, the Pi wasn't figuring out what the right epoch was). Even though KStars would eventually show the right time, that initial wrong timestamp from the GPS was taking priority somehow. Those problems went away with the new dongle, so I never did figure the problem out exactly. Of course, your problem was probably something completely different and equally random.
The mount/PMC8 controller itself doesn't actually know much beyond its rotation (relative to where it started when you powered up), declination (ditto), and each axis' tracking rate. All of the smarts to translate that into where the mount is actually pointing in the sky are in the client. So the PMC8 itself would never see, for instance, the time or GPS. But the client needs to know this so that it can figure out where to tell the PMC8 to move. As far as polar alignment goes, this means that you'll lose all of the data that the client is using to compensate for polar alignment if you cut the power to the Astroberry. So unless you have a good polar alignment physically to start with (e.g. using the polar scope), then yes you'd have to start over again once you restored power to the Astroberry.
What kind of problems were you experiencing when you were working with the wireless connection? Was the mount just not slewing at all, or was it slewing to wrong places?
For what it's worth, I have actually been quite surprised to find that I can switch between ExploreStars and Indi in the field quite nicely if I have a good physical polar alignment and am sure to disconnect the other client first. This is using my Pi as an AP. I'm not sure there's too many reasons to actually switch in the field, though. Now, if both could be connected simultaneously, that might be more interesting.
Sorry I didn't reply sooner--I don't come to the boards as often as I should. Anyway, about 3 months ago I made a few changes to the PMC8 driver to make it more reliable for TCP connections, and I've been using the EXOS2 PMC8 exclusively over TCP ever since. I have found it very reliable. I'm not sure whether there would be any difference for iEXOS100--I know the firmware is different, but I was under the impression that it's all pretty much the same.
Just to check, you might want to verify that you have the latest version of the driver (0.3). I think it should be in the latest kstars/indi builds.
Perhaps a difference is that I am running in infrastructure mode using my LAN or a hotspot instead of a direct ad-hoc connection to the mount? See espmc-eight.groups.io/g/WikiSubmissions/topic/37662303#8
I used to have lots of problems with the time, but I don't think that had anything to do with the mount, as I don't think recall there being a way for the driver to even tell the mount what time it is. Anyway, I bought a cheap GPS dongle (HiLetgo VK172) and started using the GPSD driver. That seems to have cleared everything up.
Since the current Pentax (gphoto2) driver in Indi is almost entirely useless (at least for my camera), I've been working on a new Pentax driver using the Ricoh Camera SDK. I think I'm at a point where it's ready for testing.
Here's the highlights:
- The SDK *officially* supports the Pentax K-1, Pentax K-1 Mark II, Pentax KP, and Pentax 645Z. However, it also supports other unlisted cameras, such as the Pentax K-70 I have been testing with. Please let me know if it works for other models as well.
- The camera must be in PTP mode (i.e. opposite of gphoto2).
- Live View works, at least for the K-70.
- Driver supports whatever pre-defined shutter speeds, ISO settings, etc. are available in your current Exposure Program (so typically set to Manual).
- Allows selection of image resolution (by changing the quality).
- Bulb mode does not work, at least not for the K-70. So the maximum exposure is 30 seconds.
Code is in my fork:
The driver is indi-pentax, and you need to build/install libpentax as well. This is my first original driver for Indi, and quite frankly the most coding I've done in a long time. So I'm bound to be doing something wrong, and I appreciate any feedback.
Also, I'm curious to see what the demand is for bringing in pktriggercord into the mix. The basic idea is that the driver would use the Ricoh SDK if the camera is in PTP mode, and switch to pktriggercord when the camera is in MSC. The main advantages to the pktriggercord mode would be (theoretically): 1) bulb mode / arbitrary exposure length support; and 2) possibly wider camera support. However, pktriggercord does not support live view, and from my initial testing appears to be somewhat slower and perhaps a bit less reliable.
I updated the tutorial. Looking back at the readme, I think that's probably valid, and I was just confused about the repository split at the time. A Wiki would be great, much simpler to update, which of course means it'd be much more likely that people would take the time to contribute.
Trusting, aren't you I made changes to reflect what I had to do. Hopefully they're universally applicable. The tutorial needs updating as well:
, but I don't have access. I'll have a quick look at the README too, since I remember that not working either.
I'd be happy to contribute where I can. The page I was looking at was:
. What's the best way for me to propose changes?
Any chance someone could update the instructions on the setting the development environment? I set up a development environment a long time ago and recently came back to it, and was having all sorts of trouble trying to figure out what changed, until I found this post.