So what was the exact sequence of events? I'm assuming you booted up Astroberry, and it auto-started indiserver with the PMC8 and SkySafari drivers, and then you connected to it and started slewing in SkySafari?
Assuming that's the case, the only thing that immediately comes to mind is that perhaps when you started Ekos in KStars, you used a local profile instead of remote profile, which killed the background indiserver instance and started a new one. If that were the case, the mount may have seen this as a client disconnect, which, depending on which firmware you have installed, causes the mount to enter into a safe mode and kill the tracking. But then that still doesn't make sense, as the mount should still have told the driver its position again when it connected to the new indiserver instance. At least that's my recollection of how the original firmware worked.
Was it just the Astroberry desktop showing the wrong position, or SkySafari too? How is the mount connected to the Astroberry? Serial connection? Not that I can think of any difference between wifi and serial, but just trying to get a full picture.
I would think it would be a while before this fully replaced the gphoto driver for Pentax--it needs a lot of testing by people with different equipment than I have. I think in the long run that people will find this driver to work better than gphoto for Pentax cameras, but who knows. (And the existing indi_pentax_ccd driver is just a redirect to indi_gphoto anyway, so the gphoto driver would never really be gone). In the meantime, it does leave open a question of naming conventions. I proposed in my code naming one driver "Pentax (Gphoto)" and the other "Pentax (Native)", but I'm open to suggestions.
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.
I've tried using the joystick with the PMC8 every now and then. I think my observations were generally the same as yours. It seemed like it was one axis at a time only, and I would sometimes need to go and re-enable the joystick in the PMC8 driver (though oddly enough I don't think it was something I always needed to do). I can't really comment on the speeds. I was using it for minor corrections after a goto, so I didn't want the mount to move quickly anyway.
It bugged me a bit at the time, but I filed it away as something to look at later, as I had other priorities and I'm usually away from the mount when I'm using Indi anyway. But I might be willing to look into it when I get a break from work projects again in a week or so. Or test anything you come up with .
I'm a bit surprised telnetting into the PMC8 and querying it would have bricked the mount. I've done a lot of dumb things with mine and it keeps on ticking. On the other hand, it does take a little while to understand the Indi architecture. If it's any encouragement, I think the real reason why something is not implemented by a more competent person is not that it can't be done, but rather a shortage of competent people who are interested enough in using Indi to control the PMC8. I mean, I'm a lawyer for crying out loud--I shouldn't be allowed to touch the driver .
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:
. 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?).
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.