In the specs for the ASI183MM camera, different frames per second rates are given for both 10 bit ADC and 12 bit ADC. But it seems there is not a corresponding switch in Ekos, not under the streaming tab nor under the control tab.

What is more, using Python Imageio Pyav plugin, it appears that the data contained in the .ser file when streaming is saved contains only 8 bit data. Well, sort of. Each pixel is assigned 3 unsigned 8 bit integers, but since the ASI183MM is monochrome, those integers are all the same.

Is there a way to save 10 or 12 bit data in Ekos?

Is this a FAQ? Are there any relevant docs?

Thanks.

Read More...

Mark Copper created a new topic ' Fast exposure support?' in the forum. 2 months ago

The INDI Library 1.9.3 release lists as its first highlight
"Fast Exposure support. Capture next frame in camera immediately to avoid any delays."

Where can I find out more about this? I'm not sure what it means exactly or what cameras it might apply to.

Thanks.

Read More...

Thanks for responding.

A quick write speed test (dd if=/dev/zero of=tempfile bs=1M count=1024) results in 2.6 GB/s.

This test is performed on the computer to which the camera is attached; that is, "local" in the Ekos tab.

Read More...

Hello all,

I realize there are a myriad different setups out there, but does anyone have a sense how many frames per second can be achieved under the Ekos CCD tab?

For example, I have a series of 2000 x 2000 px photos taken at .02" exposure with an ASI183MM written locally to a solid state drive. The capture rate was just under 100 per minute or 1.7 per second, bandwidth set at 76.

An impossible question to be sure, but I'm wondering what other people might be experiencing.

Thanks.

Read More...

Current setup: ZWO ASI183MM connected to scope computer (itx ASRock MB + intel core i3) running indiserver. EKOS running on laptop connects remotely.

If EKOS connects to computer via router placed inside observatory, then camera functions as expected.

However, if EKOS laptop is placed further away, inside house, with slower network connection. Camera images, no matter how small, are not transported. Images are written to local drive without difficulty, but, say, preview images don't make it back to the EKOS client. I mean like 400 pixel images.

Kind of a strange all-or-nothing performance from the ASI camera, something I've complained about previously. If anyone has dealt with this issue, I'd love to hear about it. Otherwise, I'll just keep working on improving house-to-observatory network speeds.

Thanks for reading.

Read More...

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. 9 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. 9 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. 10 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. 10 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...