Another reason to make J2000 coordinates an (explicit) option in the alignment module is that the astrometry.net index files are keyed to J2000 and the WDS coordinates written to the FITS headers are therefore also J2000. And though other catalogs are available, astrometry.net is the system documented in the Ekos tutorial.

Or maybe coordinate conversion between systems could be a separate entry?

Or am I missing an option somewhere? The INDI written headers include the equinox as a separate field, indicating, perhaps, that it can be changed.

Read More...

Partial facepalm: The Ekos platesolve and mount modules and the telescope tab in the control panel both assume JNow coordinates.

In the mount module is a mount control button that launches a virtual handpad which contains a radio button that provides a choice of JNow and J2000 coordinates. But choosing J2000 on the handpad did not seem to propagate to the control panel or platesolver in my setup.

I think it would be helpful to include coordinate system options in the platesolver module. Conversion routines have already been written in the INDI library, libastro.

Read More...

This looks like a bug but it's so basic that I'm almost surely going to end up facepalm. Almost.

Repeated observed behavior: Ekos plate solve will claim the telescope is aimed at the requested coordinates (within, say, 30 arcseconds) when in fact it is not. This is a problem with Ekos and not the external solver, astrometry.net in my case, because the correct coordinates of the test shot are written to the FITS header.

Example from last night: requested slew to Rho Capricorni by coordinates, 20h20m57.52s, -17:48:49.43, in the control panel. After settle, requested "capture and sync". Repeated until "capture and sync" reported error less than 30 arcseconds. This was clearly in error because there was no mag 4.8 star in the field of view ever. Captured the field anyway and checked the FITS header; the header reported location of center at 20h27m32.81s, -17:49:33.17. That's 1182 arcseconds difference in RA and 44 arcseconds difference in Dec!

Additional notes: system field of view somewhat narrow at 21' x 14'. Aperture somewhat wide at 25" so plenty of stars were captured in 1 second exposures. In another example with bright star target, Eta Pegasi, the star was captured in the first test shot and Ekos homed in on the star without difficulty. So the problem only seems to occur when the test field lacks a bright star for Ekos to home in on even though the plate solver has no difficulty.

Thoughts? I'm happy to provide access to FITS files. I'll try turn on logging tonight to see if that helps.

Thanks for reading.

Read More...

Mark Copper replied to the topic 'optimizing plate solver' in the forum. 2 months ago

Thanks, Hy.

I'm wondering about ASTAP. Does one need the full suite to run the solver under Ekos/indiserver? I notice there is an ASTAP-CLI package in the Debian repository.

Also, I wonder how the ASTAP database, H18, gets by with less than 1 gigabyte when the astrometry.net data files for my setup take up 32 gigabytes. From the ASTAP website, H18 includes stars down to 18th magnitude.

Read More...

Mark Copper replied to the topic 'optimizing plate solver' in the forum. 2 months ago

Here is a plate solve from last night, start and finish, with Vega as target.
   drive.google.com/file/d/1srApvSVSOMpSmFh...SWZ/view?usp=sharing
   drive.google.com/file/d/1EUJQm-UtZ_oHj7X...AT-/view?usp=sharing

Solving was again on the order of 50-60 seconds per frame. These are the options I used:
   drive.google.com/file/d/1elON7vnWqCWEExg...5Ud/view?usp=sharing

Note that I trimmed the area when I captured an image but neglected to do reflect that in the scaling options. I don't know if that had a deleterious effect.

Also, I ran solve-field on the remote computer, blind, without any options at all. Although I didn't record how long it took to solve, it was quite rapid. So I wonder if running the solver remotely created some kind of bottleneck.

There also seemed to be a problem with solving to coordinates for which Ekos had no object. Thus, for example, I tried solving to a star dimmer than 8.4, but the solver solved to a near by brighter star. But I'll investigate further and post separately if it continues to be a problem.

Thanks for reading.

 

Read More...

Mark Copper replied to the topic 'optimizing plate solver' in the forum. 2 months ago

Thank you. Cloudy here tonight. I'll work through suggestions at first clearing.

Read More...

Mark Copper created a new topic ' optimizing plate solver' in the forum. 2 months ago

I was happy to get remote plate solving to work on my setup. However, each iteration of plate solving took between 50 and 60 seconds.

Is this to be expected? Or should it be faster? The illustration on the "Alignment Module" page shows 2 seconds.

There doesn't seem to be very much to change in the solver options window since the telescope coordinates and sensor size get read into the command line automatically. I tried reducing the size of the search field since the possible error seems to be far less than 30 degrees, but that had no effect.

Any suggestions would be appreciated.

Thanks.

Read More...

I am trying to get a telescope driver going. But it kills indiserver immediately on startup:


debian@beaglebone:~$ indiserver -r 1 -vv SiTech
2021-07-24T01:03:47: startup: indiserver -r 1 -vv SiTech
2021-07-24T01:03:47: Driver SiTech: pid=9743 rfd=3 wfd=6 efd=7
2021-07-24T01:03:47: listening to port 7624 on fd 4
2021-07-24T01:03:47: Driver SiTech: sending <getProperties version='1.7'/>

2021-07-24T01:03:47: Driver SiTech: stderr EOF
2021-07-24T01:03:47: Driver SiTech: restart #1
Child process 9743 died
2021-07-24T01:03:47: Driver SiTech: pid=9744 rfd=0 wfd=6 efd=7
2021-07-24T01:03:47: Driver SiTech: sending <getProperties version='1.7'/>

2021-07-24T01:03:48: Driver SiTech: stderr EOF
2021-07-24T01:03:48: Driver SiTech: Terminated after #1 restarts.
2021-07-24T01:03:48: good bye

Are there any debugging tools that help?

Thanks.

Read More...

Many thanks for responses.

I am running my ZWO ASI cameras on a Beaglebone Black (BBB). Besides a camera, I am running a Rigel Systems nStep focuser. When both devices are connected, I connect with a USB hub. However, the problem I am having persists when I connect just a camera directly to the BBB USB port. Namely that the ASI183MM fails to capture a full frame image and that the ASI290MM fails to capture a full frame image when the integration time is set less than 1 second.

I'm using just one camera, and using it for imaging. No ST4 in use. I have upgraded the USB cable that came with the cameras.

More details and the ZWO tech responses may be found on the ZWO forum:
   bbs.astronomy-imaging-camera.com/d/12623-asi-cameras-armv7/2

I don't seem to have an INDI driver panel. Perhaps I'm missing something?

Yes, I suspect this is all about the speed of the download as both cameras work fine with the BBB if I cut the ROI down to 256x256 (which, of course, is not something I would normally want to do...). That the SDK is not waiting long enough to call ASIGetExpStatus.

So back to the "change USB traffic" thing. It seems to be a phrase only ZWO uses and I am left wondering whether it refers to camera settings, Ekos settings, INDI settings, or OS settings.

Thanks for reading.

Read More...

I have been advised by ZWO tech support to "try to change USB traffic" starting from 40. 

But I don't know what that means. Apparently other software packages have such a setting but I don't see one in Ekos and don't know what it would mean in terms of Linux settings.

Does anyone here experience with this?

Thanks.

I'm still working on getting a Beaglebone Black to run ASI cameras 290 and 183. Hope it's no etiquette violation to start a new thread. Please advise if so.

Read More...

This is helpful. I'm running Ekos on a Beaglebone Black -- not quite as much computing power as the RPi4.

I've asked tech support at ZWO about this and they seem willing to look at it. I also have a Beaglebone AI with similar specs to the RPi4 at the ready.

Read More...

A new USB 3 cable arrived today. But no improvement, unfortunately...

Read More...