I was just thinking, after seeing a mosaic on APOD this morning:
Hey wouldn't it be great if we could use gathered FOV info from plate solving to set up mosaic shots? I get the concept but doing it manually seems really hard. Maybe we could program for target position and add or subtract the fov stored by plate solving to get a position matrix for a mosaic?
IMO ~= à mon avis
We all value your opinion greatly @James_Lan. I read through the git discussion also.
Sync - (I knew it had a name ;-P)
tl;dr I think it's more of a machine thing than a program thing.
Very interesting discussion. One side effect of programming in short pants(opensource) is that it can be like herding cats when so many different bits of hardware come together. I'm not surprised there's already a negative going focus driver as it does seem likely to happen in normal use due to system startup favoring 0 unless an offset specifically loaded, but it tends to leave you with an unknown index. Some focuser developers may not have been working with repeatable indexes in mind, especially the DC motor ones.
In industrial robots, we "home" a traverse/arm/spindle etc. to get a calibrated position. "home" is always a 0 or 0,0 and locked to physical encoder indexes or mechanical/hall effect limit switches. Only robots that zero at a midpoint use negative numbers. Our gem mounts are one example of the latter, and we all know how picky alignment is from that variable location(viva la platesolving). Onstep is ahead of the curve on this btw, having inputs available for homing switches; nice touch Howard.
I see Jasem's point about setting this arbitrary home position(all the way in) at 0 because this means your known locations are always going to be "out/positive" from there. This gives you a repeatable and locked "home" point with which to base your movements and then all offsets are positive from there.
@KNRO: Storing the previous session's focus position to XML might be a nice option.
Hope this makes it easier.
Quick side note on focusers. my DIY focusers use the Moonlite_focuser driver which has a way to enter an offset. I've used it quite a bit as my diy focuser uses a byjxxx gearhead stepper and requires quite a few thousand steps for complete travel even though it's connected to the 1:1 shaft. Because of this it is sometimes necessary to enter an arbitrary value in the middle of the range (i.e. 0-60000 =30000) to allow in and out travel. Might be worth perusing that code for interfacing tips.
I ran across this issue recently and it looks it might like a great addition to our camera arsenal.
@geehalel would like somebody to try out his snap port wrapper with the EQ6-R here:
I wanted to help but I just haven't had the time or energy.
It may also be a good idea to look into a more direct coding into the eqmod driver at some point.
Thanks for helping!
I can add a little to that history. When I came on the scene a few years ago after choosing a k-50 and then finding it's tethering not working. After doing some research I realized that Gphoto, which had an indi driver, was not up to date with current PKtriggercord so I contacted Marcus Meissner at Libgphoto2 and suggested he might get some info from Pktriggercord code to get better Pentax support. Marcus took interest in the project and through much back and forth testing and fiddling(sometimes even while my k50 was on my desk at work) he made a wrapper for pktriggercord/gphoto. This is why some of the gphoto code looks foreign, as he had to use A.Salamon's labelling when he combined the two in order to make things work. Unfortunately, my camera was one of a few that we could not get to work in bulb mode, which made it less useful for AP. Something crashes in the newer firmware due to changes in the firmware command code. Marcus eventually bought himself a K10d and got the bulb functions tested. You can follow all that craziness at:
p.s. I've since bought a k5 which is working nicely in indi with nice long exposure times. The longest I've tried was 600sec.
@Calberts: Thanks for helping with testing!
I'd like to see other users camera settings and XML setups too, as well as any tips you might find working with this. I had a hard time getting this going so I'm hoping to do some sort of writeup we can put in documents for using Pentax with indi.
One tip I saw recently involved using the camera in mirrorlockup mode with multishot. I read that as long as your exposures are longer than storage time it will hold it up and keep shooting with an intervalometer, but I haven't tested it, and I'm not sure the driver will handle it correctly as is. Sounds like a neat trick that we might make use of somehow, MLU button perhaps?
Woot! (brandishes bug net)
I agree about the library. Since we're usually tied to planetarium software(kstars, ccdiel) it does seem unneeded.
It will be a while before I can test outside again. I have a long list of chores delayed by all the rain and snow we've had. Also waiting for parts as usual. I'll certainly put it on my schedule though. I may try to have it running as a secondary project in time for the lunar eclipse in a few weeks, which will be sure to uncover any bugs ten minutes before the good bit.
"When I connect to KStars, Indi automatically updates location, date and time"
There is a setting in Kstars/indi preferences that lets you choose which way updates go and we usually set it to update the mount time and position stored in the pc. You might check that setting if it's not updating the mount time.
Park position is stored in the xml file at ~/.indi/indi_OnStep_config.xml when you save the form and loaded at connect when the system is set to update the mount. Saving with park at the default (north) home position should fix that to a reasonable figure and is recommended for most portable mount users.
Hope this helps.
- Solved the I/o error. It was related to firmware. We'll need to note that in the tutorial. I had 1.11 and updated to 1.16 which solved the i/o error. Folks can find it at RICOH Japan
- A udev rule to properly assign the port when "pentax" is found might be nice too and might stop the port creep I found after I figured out that first error.
Could I get a copy of a working XML from ~/.indi?
Continuing to have difficulty getting the k5 connected to either Gphoto2 or indi drivers. I now have the latest Gphoto2 and LibGphoto compiled. When I try to connect I get no camera found, unless I set the camera to PTP mode, which won't do any controls or capture. I feel like I'm missing something. It shows up on lsusb as "pentax" and is not mounted as a drive. I've got clear sky for the first time this year. HALP!
@pentaxian23: Thanks. That's a good start and pretty much what I had. looks like I'm still struggling with out of date libgphoto stuff on this new notebook.
Some thoughts on that timing issue you're having: In the gphoto driver, "force bulb mode drops back to regular exposure for <1sec. That may be a clue. I'll know more once I get things working.