Neat! I configure mine to come straight to my file server but that could still come in handy. Also, pubkeys are the shiznit.
What has been working for me is to only run indiserver on the pi for control/usb hub(pi3b for now) and have it all sent directly to my main storage hard drive in the house. This way Kstars/ekos runs on the fast pc and I don't have to bulk move collected data out of the pi to process.
I read about your trouble with the journal log getting too big, I wonder if turning it off might help? -- or is that only turning off the display in the gui? :ponder:
I gave this a try the other night by simulating file drops with old data and found it does a wonderful job! I think it may be working better than my regular one even.(Siril)
I was wondering if you guys have considered making an option to use it as a regular stacker(load a file selection to be processes), or maybe a forked version to be developed into a processing app.
And all this time I thought "I" was the drama queen...or maybe I was just the progenitor of bug driven angst(ask Jasem how often I've lost it trying to fix stuff)
As I suggested in my other comment(and a forum thread a while back), mine stopped working recently too, then I updated the scope side indiserver, which is compiled once from git and not updated from ppa for max stability and to use the lighter faster Raspian. It was because the ekos side got out of sync and was incompatible until I updated it. It was latest git, but the point was that your mystery might be caused by the same changes and possible ppa lag between ubuntu and the stellarmate version, which all reports I've seen are using. Since I'm not using it I can't test that, but effected users might want to check versions.
Interesting. Mine was working on the K5 last weekend but I'm not following nightly right now so something could have happened in latest. A bit off topic for this thread so I'll follow it on PF and gphoto git to see if I can confuse anyone. ...er I mean help.
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.