My CEM25P has a pretty good polar scope, but the Polar Alignment Assistant invariably does a better job than I can with the scope. Well worth the five minutes IMHO.
My workflow is close to those above; since I do a lot of narrowband these days, I'll note that I usually do a rough focus using the scale on the Stellarvue's focuser and rough polar align with the scope. Then, using one of the broadband filters so that short exposures suffice, I'll focus by eye on the stars around Polaris enough that plate solving is reliable. Then the Polar Alignment Assistant to really dial the alignment in (usually to within a few tens of arcseconds).
Next is Capture & Solve/slew to target on a bright star such as Vega. Once I've got that centered, I switch to the taking filter, slap on the Bahtinov mask, and compose my soul in patience for frames to download.
That flow lets me do most of the plate-solving and get close to the focusing mark using short exposures through the R, G, or B filter, and get centered on something bright enough that the diffraction pattern will be usable with only sort-of-long exposures through Ha or OIII.
Polar aligned and focused, I'll either do Load & Slew, if I have a previous FITS of the target, or select the target in KStars and do Capture & Solve. (The former is excellent when I'm pointing elsewhere than the officially accepted center of a target, e.g. my Pelican/N.A. of last night). Might have to use longer exposures to ensure a solution, but that's OK, usually it only takes 2 or 3 frames and it's all automated -- not like sitting there watching the screen with your hand on the focusing knob, waiting for the next frame to finish so you can see whether to turn the knob or not.
I'm tempted, but the AP/join-local-wifi automatic behavior is awfully hard to give up for someone who images both with and without WiFi access.
And I'd have to use two USB slots for BT (focuser) and WiFi. But perhaps the ODroid would see the GPS dongle and mount when plugged into my powered hub. The Pi does not.
I'll give that a whack if I see the problem again. When I set everything up on the bench to test it the day after, I got the Software Updater prompt and figured "Oh, what the heck". So new versions of KStars and a bunch of other stuff have been installed. I know that sucks for debugging but if it made the system reliable, I'd be satisfied.
Tried to break it after that. Nothing doing. Worked like a charm. Like a champ. Heck, even my Mac (which I hadn't touched) was suddenly able to run and connect to the internal INDI server again! So I think I'll try some longer-term tests, running kstars under gdb, and see if anything breaks.
The exposures were all 180 or 120 seconds. I've run flats at less than a second (which worked fine out in the field, actually). I'll try turning that notification off, obviously it's not going to help me much on the Pi anyway!
I've seen the thread on issues with StellarMate OS 1.4.0 and 1.4.1, some of which sounded like showstoppers. Has the release gotten to a "happy place"?
I'm asking because Ekos on my Pi kept crashing over and over last night, losing most of a night's imaging time. No error messages or anything interesting in the logs, just the application doing a wingover into the dirt in mid-sequence. Was thinking I'd wipe and reinstall StellarMate OS, but was wondering whether to just reinstall the original or go for the new version.
Alternatively, I might just update KStars/Ekos, hoping to get back to the kind of reliability I got out of this thing when I first started using it. Any advice welcome.
OK, seems to be working now. For the record, if anyone else is in this jam, here's how I got it to work:
1) Turned off all the options in the "solver options" panel besides "downsample", which I had set to 8. (That's the Alignment tab, Options button, Solver Options).
2) Copied all the index files I'd downloaded to an external drive, so that I could play around with deleting them without fear of Eternal Download Times.
3) Unclicked all the "recommended" index files on either end of the range of the "required" range. (There was one "recommended" *inside* that range, which I elected to leave alone.) I also ensured that the required files were there for both the Tycho2 and 2Mass catalogs.
I haven't tried it in the field, but it's now solving with the "Load and Slew" button, so I'm reasonably confident. Both the simulator (63' wide) and my images (125' wide) are solving with the 4110 index, for whatever that's worth.
Rob, Jasem, thanks for the suggestions. I might very well try binning when I get to the field, if the 183 driver allows that.
NOW I can start debugging the internal-INDI-server problem!
Thanks guys. I did manage to get Ekos running using the INDIGO Control Panel, and I can connect to and run my actual equipment using my Stellarmate appliance. So I'll table the INDI Server connection problem for right now -- if the weather ever clears, I know I can get images, but I'll be pretty lost without plate-solving!
Using the entire simulator stack, I could easily do a "live" plate solve. And when I saved an image to disk, slewed the telescope simulator elsewhere, and then tried "Load and Slew" on the saved image, that worked perfectly too. So it's just my actual live 183MM images that it's failing on. Any suggestions for the next step?
Index files, maybe? According to the guidelines for the index files, the simulator (63.3' x 50.6') should need index files down to 5.0', right? That would be 4203 or even 4202, and I only have 4205 installed right now and it worked fine. ??? Unless I've done the math wrong my 183MM on my scope is 125' x 83'. So, um, get rid of 4205 and try again? That seems crazy, but this is a pretty crazy problem.
Nope. 3.2.2 running now. The "Simulators" profile fails to start with "Connection to INDI server locally on port 7624 failed." That's a different problem that I've also posted about here. But if I run things with, say, INDIGO Control Panel so that I can bring up the Alignment tab, I get the identical result.
Used to plate-solve just fine on my Mac; now it doesn't. Running it out of KStars 3.1.1 (i.e. I'm using what KStars installed, not a freestanding install). Signs & symptoms:
- Solving works fine for my ASI120MC-S
- Used to work for the 183MM, but on the Night of Disasters, it totally didn't
- Spins endlessly with "failed to solve" messages going by, times out after 3 minutes. Used to work in 5-30 seconds.
- I tried downloading some smaller-footprint index files, which may have been the issue. But removing them (I have autoindexing on) makes no diff.
- Turning up downsampling (e.g. from 2 to 16) makes no difference.
FOV with my SV70t-IS, FF/R, and 183MM is 125' x 84'; I have 4205 up through 4215 index files, and tried 4203 and 4204.
Lacking access to stars, I have been mucking around with Ekos's "Load and Slew" function, loading a previously-shot sub to solve. Same FITS files solve just fine at nova.astrometry.net, of course.
At one point, I thought I had it narrowed down to "working with visual filter, broken with Ha", which seemed like progress, even though I know for a fact that it worked fine through the Ha filter in the field. I wondered if the amp glow from the 183 was causing a problem, so I tried it with a dark-calibrated sub. Yay, it worked! Then it stopped working. I changed nothing -- honest! But now I can't solve a sub with the blue filter, the Ha, or the dark-calibrated Ha. It was literally "I'll run that again just to make sure" and it stopped solving.
Any ideas at all? Something broken with how the index files are set up? If so, how on earth would I fix that? If anyone has confronted a similar problem, I'd love to hear about it.
In my wackadoodle setup, the guidescope isn't collimated with the main, so having Ekos zero in on the target with the guidescope doesn't help me too much. But if I have to, I guess I'll collimate as best I can and calibrate the difference, then try manually nudging with the hand paddle.
BUT IT USED TO WORK!
Tia (sigh. AGAIN.)
Now working on the Stellarmate-imaged Pi as well. A lot of it was just getting the ports sorted out; the Serial Port Assistant actually helped here, even though it shouldn't have (i.e. this is not USB-serial, just USB). But it found the wheel and named a device for it anyway. Good enough.
Had it happen again last night. Carefully checked the options -- all was set to "local". I happened to have the INDIGO Control Panel installed, ran that, and (after changing the profile to use "remote") had the same error. But when I changed the hostname in the options dialog from "localhost" to the hostname that appears when I run hostname in a Terminal window, Ekos was able to connect.
Last few lines from the failed connection log:
[2019-05-26T22:26:02.905 CDT DEBG ][ org.kde.kstars] - Daylight Saving Time active
[2019-05-26T22:26:02.905 CDT DEBG ][ org.kde.kstars] - Next Daylight Savings Time change (Local Time): "Sun Nov 3 02:00:00 2019 GMT"
[2019-05-26T22:26:02.906 CDT DEBG ][ org.kde.kstars] - Next Daylight Savings Time change (UTC): "Sun Nov 3 06:59:59 2019 GMT"
[2019-05-26T22:26:02.906 CDT DEBG ][ org.kde.kstars] - Starting the timer
[2019-05-26T22:26:02.987 CDT DEBG ][ org.kde.kstars.ekos] - Resetting Ekos Manager...
[2019-05-26T22:26:03.019 CDT INFO ][ org.kde.kstars.ekos] - "Starting INDI services..."
[2019-05-26T22:26:24.103 CDT DEBG ][ org.kde.kstars.ekos] - Resetting Ekos Manager...
[2019-05-26T22:26:24.104 CDT WARN ][ default] - QSqlDatabasePrivate::removeDatabase: connection 'filter_db' is still in use, all queries will cease to work.
[2019-05-26T22:26:24.104 CDT WARN ][ default] - QSqlDatabasePrivate::addDatabase: duplicate connection name 'filter_db', old connection removed.
[2019-05-26T22:26:26.646 CDT INFO ][ org.kde.kstars.ekos] - "Starting INDI services..."