Were you using the Native driver when you set the ISO and aperture? As far as I know, the only way to get those to set are with the Native driver in PTP mode, and that's only if you have an actual lens attached to the camera (i.e. not prime focus). But then the shutter speed should have worked as well--unless of course you were in Bulb mode.
PTP mode does not support Bulb mode. You need to switch to MSC mode. Honestly, unless you need live video, you may just want to forget about PTP mode (though I welcome testing).
In either mode, the Native driver (I cannot speak for gPhoto/legacy) is highly untested, unfortunately. The most feedback I ever received on it was from people using older camera models that ultimately just wouldn't work. The K-70, on the other hand, should work well, ideally, so I really appreciate feedback like yours. Could you let me know which OS you're using, as well as the specific hardware you're running on?
The Native driver hasn't changed in a few months. I'm not sure how far behind Astroberry is, but last time I tried it I think it was fairly up-to-date, so I doubt that an upgrade affected anything.
I need to investigate the SD card issue--I thought that worked, but it's not part of my normal process flow. I usually just save to the client. I'm on an extended road trip right now, so it may be a week or two before I have my equipment available to test.
Since you've already compiled pktriggermode and tested the change in pslr_model.c, perhaps it's easiest to keep working with pktriggermode directly to see if we can find the right solution. I think it'll be easier to mess around with the cli (pktriggermode_cli.c). My first thought is to try calling pslr_shutter again before calling pslr_bulb at the end of bulb_old. So to be more specific, try adding "pslr_shutter(camhandle);" between lines 339 and 340.
My next thought would be to force the K30 to use bulb_new instead of bulb_old.
If you can do either of those, let me know how it goes, or let me know if you need more direction.
I made some changes to the driver. They should be in the nightlies as of a few hours ago. I think they may solve the problem with non-bulb mode, and if we're lucky, maybe even make a difference with bulb mode. Let me know how it goes.
So, I spent a little time looking into this today, and found an old issue report for the K-30:
. Doesn't seem like good news for the K-30. I'm not sure if they ever found a fix for it. I saw your issue request there as well. Maybe someone will respond.
Meanwhile, based on the results so far, it seems like it may be possible to get something working for M mode at least. Are you capable of checking out my fork and compiling from that? It'd make the testing cycle go a lot faster and avoid unnecessary commits upstream.
Thanks. That's strange that it's not recognized in bulb mode, as the K-30 is listed as supported (as opposed to partially supported) on the pktriggercord website. I'll work on trying to get M mode to work for now, and then see what I can find out from pktriggercord about the bulb mode problem.
Okay, seems like it's not getting that initial image from the buffer correctly (it thinks its a 0 size image), and from that point on the buffer is lagging behind one exposure. That gives me a few ideas to test at least.
It might be helpful to at least see what you can do with pktriggercord on Windows. That will give us a baseline of what we should be shooting for with the K30 here.
I should mention that when the camera gets into a weird state, sometimes you have to pull all power (i.e. take out the battery) before it will behave normal again--turning it off is not enough. So for #2, what I'm looking to find out is what happens if you start totally clean with both the driver and the camera in M mode.
Thanks for testing it out, Lenny. It looks to me like it never recognized you were in bulb mode. And then the camera looks like it got into a weird state. I think we had a similar problem on K3II. I wish I had something besides the K-70 to test with.
I'm not sure how much additional testing you're up for, but if you have some time, it'd help to know:
1) Can you check to see if it downloaded any images to your device? The log seemed to indicate it did, but of course that doesn't necessarily mean anything.
2) If you start the driver in M mode, and never switch to another mode, what are the results?
3) If you haven't already, could you by chance download pktriggermode by itself and let me know how that works with your camera? The driver is just wrapping the code for pktriggermode, so if you've used pktriggermode before and it worked, then we're having a driver problem. Otherwise, there's a fundamental problem with pktriggermode, and there may not be much I can do.
If you can respond to those questions, I can spend some time this weekend updating the driver a bit so it can spit out more helpful debug information.
There is a missing dependency. All you should have to do to get it going is install the libricohcamerasdk library:
sudo apt install libricohcamerasdk
It should install now with the nightlies on Ubuntu Mate 32 bit. If by chance you were on a 64 bit, there was a problem with the 64 bit build, so maybe tomorrow for that.
FYI, as I was afraid of, the driver isn't working with PTP mode the way it was compiled, so stick with MSC mode for now. The main advantage of PTP mode so far appears to be live view, anyway. I'll have to see again if I can figure out what's different in the way it gets compiled on Raspbian versus Ubuntu Mate.
Let me know how it goes.
There's still something wrong with the build. It's outside of my direct control (I think), but I just submitted a bug report with the details. The fix should be pretty simple, so hopefully it will be updated soon.
lennyk wrote: Hi Folks,
Thanks for the replies, I have updated the nightly builds there, and it is still not showing up. Is there something else needed?
I'm not sure if its relevant but I updated to Ubuntu 18.04 LTS 2 nights previous.
Not sure. I think that's Jasem's call.
silver wrote: I have Pentax K-70. When Pentax native driver will be avaiable in Stellarmate OS ?
I don't think this has anything to do with the indi-3rdparty packages not building.
Just from a quick test, I think this is an incompatibility problem between the driver or the package and Ubuntu Mate. Ubuntu Mate *thinks* the indi-pentax package is installed, but the indi_pentax executable never ends up in the /usr/bin folder.
I don't think Raspbian or Ubuntu x86 have the same problem. I'll have to double-check with a clean install to make sure.
I wonder if this has something to do with the armv6-armv7 compatibility problems with the Ricoh SDK I was having when compiling on Ubuntu Mate. But, my recollection is that I still at least was able to compile, so I'm not sure why Indi_pentax isn't getting installed. I'll dig into it some more over the next few days.
I'm responsible for the new Pentax driver. As far as I know, there hasn't been a ton of testing yet (beyond me and my K70), and I'd be really interested in finding out how it performs with other cameras. Sorry for the late response. I don't poke my head around here very often.
From the logs, it does not appear that you are using the new driver yet. The logs show you using indi_pentax_ccd, which is the Gphoto-based driver, whereas the new/native driver would show simply indi_pentax.
If you've downloaded and installed the nightlies, when you are selecting the driver in Ekos, you should see an option for "Pentax DSLR (Native)." I've attached a screenshot. Let me know if that helps. I'll subscribe to the thread so I can respond more quickly if you have any questions.
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.