Hi Karl! That's pretty awesome! I've thought about getting a K1 but knew the drivers were going to be a hassle so I've waited. Marcus(gphoto) said the SDK WAS using closed drivers and would be difficult to work with. Starting from scratch is a daunting task too. BRAVO for you efforts!
This probably doesn't matter too much, but I just thought a little history might help.
I helped Marcus get the gphoto pentax driver going a while back and Marcus ended up wrapping to pktriggercord at that time.(so much testing!) Marcus bought himself a k10d to play with and between that and my k-50 he bashed out the current working driver, but we couldn't get past the wanky firmware issue with bulb in later models. Later Andras came up with that bulb fix for the k-70 for pktriggercord (a trick with the dual/single press menu) and we tried to get the k-50 to bulb using that new fix also without success. In the end I wound up buying a used K5(same exmor imx071 sensor) and have been using it with up to 20 minute exposures. You might get with Marcus over at libgphoto and let him know the pktriggercord k70 bulb fix isn't working with gphoto. he might also have some tips if he already got around it/updated it to pkt's new code.
Hey! There's an AP group at PF?
So when things move along a bit I'll for sure be able to give it a try with a K5 and a k50 --though probably on cloudy nights...which we've had plenty of lately.
How do you set the position, by moving the motor to a defined step or you read the Hall sensor. It is possible to have more then 5 filter position?
When I was researching this project, I found many different routines to attempt to stop position creep and backlash, including multiple hall effects and mutiple magnets but I thought these seemed redundant and difficult to build/wire so I came up with this one.
The hall effect(or reed relay if you can still get them) sets a HOME position and then everything is a set number of steps from there. So from home, the first filter is offset nnn steps to run clockwise and line it up, then the rest are further along this line. My unit always runs CW so to get back to a filter that has already passed(lower offset), and prevent step creep from backlash or missed steps, when the unit sees the lower(cw) filter request, runs back around to home, and then steps off the new offset.
That sounds like a good project and your wheel is probably already better than what I started with, a noname ebay special from china. There are lots of motor options for friction edge drive if the fli has access and a round outer edge, I recommend edge mounting over the center shaft/gearhead I did because it gets in the way of extensions and cameras and has lots of backlash. The .ino should work for pretty much any stepper/wheel. You just need to tweak the offsets from the home position. to get more spots you'll need to edit the code and add more offsets to the array.
A way to select how many you have in setup might be a good trick to code in...:ponder: I used an arduino nano(cinese cheapduino) initially but rebuilt it using a newer model teensy since it has better usb identifiers for the udev rule. I also used the little uln2003 driver board that comes with the units.
I'll try to get my Github polished a bit more on this project, and update the ino file to my latest with the serial offset commands when I get some more time.
Hope this helps!
Neat! I'll check it out.
DSS live in Windows is an example of this, and why some some similar threads appear to have a bit of confusion. Whereas Indi's "live" is a session sharing, live stacking does a quick realtime denoise stack of a preview of stored images, reading them from a folder as they come in. It would require some reworking of the graphics preview system to use or wrap a stacker.
Siril, a Linux based stacker I've been using does have a few command line script options and could possibly be pressed into service with some work/collab with their devs. Another option would be to come up with a standalone live stacker for Linux, which might be a fun idea to approach the Siril guys with.
After the k50 failed to bulb, but we had gotten some pentax models working, I helped some with GPhoto testing for the eos-m1 that I've never gotten to tether. It's trapped out pretty well in that camera to the point of not even being able to use an arduino IR trigger I made while connected to the camera card. If you connect usb it fails to fire even locally. I read that some newer models were fairing a bit better but haven't checked in for a while. Development for models is usually done through Libgphoto2 issues tracker at github so you might get info doing a search there and reading the development threads.
OH yep. Missed that one. Glad you got it going.
Quick pass attempt to help. You might make a new thread for this to get more folks to see it.
Make sure you close the arduino IDE before trying to connect. it likes to hold the port open once opened. Make sure you are attaching the usb port it's on. Turn off scanning as handshake attemps can dork other ports until you get the order correct. I have the best results when I make a udev rule that identifies the arduino by vender code or serial#(if not 0). There's some info on that in the tutorials somewhere. I remember it does handshake on the 3.1.5 so if you get that from If in serial monitor then it should go, at least that far. Good luck!