I don't have a K3-II for testing. I wouldn't object to having one, of course, but my wife thinks the money would be better spent elsewhere
I think someone else was having some issues with the K3-II as well. I can't recall where that conversation ended up, but I think the issue was related to this thread: github.com/asalamon74/pktriggercord/issues/25 . So perhaps try astrotracer mode instead of bulb, and make sure that bulb mode is in press-hold mode? Oh, and just in case, make sure you're in MSC/MFT, because I suspect PTP does not support bulb on any camera.
Just FYI, it is also possible to connect over wifi *if* you get the INDI server on the same network as the PMC8. There's several different ways of doing this, though it's probably not any easier than connecting over serial.
No. There are not enough hours in the day, unfortunately. I did respond to the pixel size issue on GitHub. I think it's technically a KStars/Ekos issue, not a driver issue, but the driver could probably be enhanced to supply the values for the K70 so as to avoid the issue in the future.
I had done some initial profiling a while back to see how much time FITs conversion was taking on the Pi4. I was surprised to find it taking less than a second, which is a big improvement over the Pi3 and probably attributable to having more memory available. Unfortunately, this means that clipping and/or downsampling before FITs conversion is unlikely to help much--the bottleneck right now appears to be the transfer from the camera to the Pi4. I'm going to look into it one more time just to double check, though.
Were there any other loose ends?
Were you using a lens, or doing prime focus? For the K-70 at least, the SDK provided by Ricoh does not expose certain settings unless it detects a lens on the camera that supports those settings. I'm sure whoever decided on this limitation thought they were doing the user a favor by only exposing settings supported by the lens, but obviously they were not thinking about prime focus. Anyway, this means that PTP mode is severely handicapped if you're doing prime focus. Much to my frustration, I did not discover this until after I had already developed the PTP driver, as I probably would have started with MSC mode only had I been aware of the limitation.
The Ricoh SDK does not support bulb mode for PTP with the K-70 (or any camera, I suspect).
Last I remember, StellarMate was using Ubuntu Mate. Is that still the case? Also, did you install from the package, or compile it yourself? This may be the issue where the toolchain on Ubuntu Mate doesn't compile libricohcamerasdk correctly. (One of the many frustrations that could be solved if Ricoh would just open up the SDK, or even just recompile it).
@Noideaforanae - As far as the 64 bit question, is StellarMate actually running on a 64 bit OS? I'm using a 32 bit OS (Raspberry Pi OS / Raspbian) since I didn't see an improvement when I tried 64 bit Ubuntu Mate. Long story short, PTP mode should work on the Rpi4, if you're using a 32 bit OS.
However, if you are in fact using a 64bit OS, that would rule out PTP mode removal as being a possible solution to your car charger problem, since the 64bit version of the driver already builds without it.
(I have debated removing PTP mode support to make things less confusing. I decided against that path originally because I wanted to provide the maximum possible support. But as more people provide feedback, if the possible scenarios in which PTP mode could be useful keeps dwindling, perhaps that is a decision to revisit. I could, after all, make a separate driver that supported PTP mode available to those who wanted to compile it themselves).
I hadn't thought of sum stacking the live view video for planets--just assumed it wouldn't work because it was too bright. That'd be an interesting use case.
I am surprised ISO is working in MSC mode for you guys. For me, it says it changes, but when I go to the images, they're reporting the original ISO. The camera will change to the ISO if I unplug it and plug it back in, but that's kind of pointless. There's an old ISO issue in pktriggercord that they could never resolve, and I just assumed it was manifesting itself here.
The Ekos autofocuser routine relies on getting FITs images from the driver. Because the driver takes a long time to convert the image to FITs, the autofocuser routine is unbearably slow on anything less than a RPi4 (which makes it annoying slow instead of unbearably slow). So live view is nice for at least getting close. As is the ability to take a lower resolution picture in PTP mode, since that speeds up the FITs conversion.
(Hmmm, I did just have an idea though--I wonder if I can could add an option for the driver to downsample or clip the original image before FITs conversion, to speed things up. I'll add that to my list of things to look into).
Awesome. How long were your exposures? It makes me want to get out there and see what I can get. I've never had the patience to stack more than about fifteen minutes of light frames. Between coma and focus problems, it was just too frustrating. But I recently acquired a coma corrector and just bought a more powerful stepper motor yesterday, so hopefully I'll be up to the task soon (if I can figure out how to get the motor attached to the focuser).
Live view should be available for the K70 in PTP mode, but there's not much control over exposure/framerate, and I'm not sure whether Polaris would even be visible.
Aside from Bias frames, I'm not sure the updated driver would give you any different results--the main fixes were with the short exposure settings, so really only for planetary imaging.
I'm pretty sure I figured out the Bias frame problem and low shutter speed problem. The changes are in my fork. I'll field test it tonight and if all goes well, I'll submit a pull request.
I really have no idea where to even start with your cigarette lighter adapter problem. Seems like some sort of noise, but then why is it only affecting the native driver? Did you say pktriggercord worked with the cigarette lighter adapter and Ubuntu? I wonder if it has something to do with the SDK for PTP mode. It's possible we could try to compile the indi_pentax driver without PTP mode support to test, but it'd be a bit time-consuming.
It seems like a permissions error. Just a thought, but do you know if the udev rules file ("95-pentax.rules") has been installed in the /lib/udev/rules.d directory? This should happen automatically during the install process, but it looks like perhaps you are building the driver manually and running it in a debugger. If you haven't done a "sudo make install" for libpktriggercord (and I think maybe rebooted for good measure), it might not have been installed properly, and that might be the source of the problem.
If it's not that, have you tried pktriggercord on your system? Just curious if that works.
I'm losing track of what i need to be testing. What exactly did the new cable fix? The error you were getting over DC power on your cigarette lighter? That would be great, because I have no leads on that.
I tested the bias frame issue, and I don't get a crash, but I also don't get a picture. It says something about the exposure needing to be greater than 0. Ekos must be doing something different that the driver's not handling yet. I'm looking into that right now, as well as the shutter speed problems for exposures less than a second.
Is this happening immediately after starting indi_pentax, or is there delay? The log shows that indi_pentax is dying, but doesn't really offer a hint as to why. Did you try pktriggercord by itself on the Pi and/or your Ubuntu desktop? If not, that would help narrow down the problem. You could also try running indiserver from a command prompt with camera on and plugged in: indiserver -v indi_pentax. That should give us a little more information.
Did the Pi4 solve the Bias frame problem?
I have no preference on github versus the INDI forum.
I was just thinking about the driver today. I think I'm almost caught up on work from my road trip and the kids are settling into online school finally, so I don't need to spend so much time on family IT issues. So I think I can look at it this weekend.
Which version of the Pi have you been using? Do you have any logs I can look at?
I'm not exactly sure why Bias frames would throw a problem. The driver itself doesn't do anything different for Bias frames versus other images. However, it *may* be related to requesting that the driver deliver the Bias frame in FITs format, or Kstars/Ekos (on the Pi) automatically converting to FITs, if that's applicable to your setup. It's possible that your Bias frames are inherently more computationally intensive for FITs conversion, which could cause the driver to run out of resources and crash, depending on the hardware you use. I think the Pi4 should be able to consistently handle it, but I know the Pi3 will often crash during FITs conversion, unless the camera is set to shoot low resolution JPEG images. The JPEG resolution can only be changed in PTP mode, so perhaps you have changed the resolution in PTP mode, and that is why BIAS frames work. This is all just a hypothesis, of course.
If you're upgrading from a Pi3 to a Pi4, you'll definitely see some improvement, though I don't think 5GHz Wlan will by itself make much of a difference. The main bottlenecks for me at least are 1) the transfer from the camera to the Pi; and 2) FITs conversion, if I'm doing it on the Pi (even with a Pi4). I would recommend turning off any setting that causes the driver to convert to FITs, and then set Kstars/Ekos on your local desktop to auto-convert to FITs instead.
Your bug with the AC adapter is very weird. I don't have the exact same setup to test, unfortunately. I honestly have no idea. Logs may offer some insight.
You mention having to switch to manual when you do short exposures. I was noticing some odd behavior myself when I was trying to capture Jupiter out in the middle of nowhere last week. I think this may have been the first time I had field-tested anything that needed less than a second with the Pentax driver, and it did not go as expected. Seems like there may have been two bugs. 1) I think anything less than a second may crash bulb mode; 2) it seems like MSC mode may not be requesting the right exposure time for short exposures. I was going to investigate these more when I had the time. But I'm just wondering if you observed similar problems.
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.