Thomas Stibor replied to the topic 'Plate solving giving wrong results' in the forum. 6 days ago

Hi kengs,

I believe this is good question for Dustin Lang (the author) of astrometry.net --- either as an github
issue or a astrometry.net forum post.

I am not mistaken, then the astrometry.net web engine uses this generic parameter for solving:

solve-field --downsample 2 --tweak-order 2 --scale-units degwidth --scale-low 0.1 --scale-high 180.0

This is what I get, when I solve the image locally under Linux with the latest astrometry.net (master)

Field 1: solved with index index-4205-07.fits.
Field 1 solved: writing to file /tmp/Barnard.solved to indicate this.
Field: Barnard.jpg
Field center: (RA,Dec) = (295.931792, -14.862427) deg.
Field center: (RA H:M:S, Dec D:M:S) = (19:43:43.630, -14:51:44.739).
Field size: 38.1293 x 28.8327 arcminutes
Field rotation angle: up is -82.5227 degrees E of N
Field parity: pos
Creating new FITS file "Barnard_wcs.fit"...

Read More...

Thomas Stibor replied to the topic 'MAX_EXP_RETRIES does not work in indi_asi_ccd' in the forum. 1 week ago

Hi Klaus,

I guess the code is adapted from the example code of the ASI SDK. As mentioned in one of my earlier posts,
there is unfortunately not much hope getting the ASI120/ASI130mm USB2.0 work reliably under Linux for all settings (arbitrary exposure time, 16 bit etc..) There are certain strict timings which have to be met.
Another approach (last try) would be testing your setting with: https://github.com/indigo-astronomy/indigo
The ASI CCD code is especially designed to work with ASI120mm, see e.g. asi_read_pixels

static bool asi_read_pixels(indigo_device *device) {
	ASI_ERROR_CODE res;
	ASI_EXPOSURE_STATUS status;
	int wait_cycles = 9000;    /* 9000*2000us = 18s */
	status = ASI_EXP_WORKING;

	/* wait for the exposure to complete */
	while((status == ASI_EXP_WORKING) && wait_cycles--) {
		pthread_mutex_lock(&PRIVATE_DATA->usb_mutex);
		ASIGetExpStatus(PRIVATE_DATA->dev_id, &status);
		pthread_mutex_unlock(&PRIVATE_DATA->usb_mutex);
		usleep(2000);
	}
	if(status == ASI_EXP_SUCCESS) {
		pthread_mutex_lock(&PRIVATE_DATA->usb_mutex);
		res = ASIGetDataAfterExp(PRIVATE_DATA->dev_id, PRIVATE_DATA->buffer + FITS_HEADER_SIZE, PRIVATE_DATA->buffer_size);
		pthread_mutex_unlock(&PRIVATE_DATA->usb_mutex);
		if (res) {
			INDIGO_DRIVER_ERROR(DRIVER_NAME, "ASIGetDataAfterExp(%d) = %d", PRIVATE_DATA->dev_id, res);
			return false;
		}
		if (PRIVATE_DATA->is_asi120)
			usleep(150000);
		return true;
	} else {
		INDIGO_DRIVER_ERROR(DRIVER_NAME, "Exposure failed: dev_id = %d exposure status = %d", PRIVATE_DATA->dev_id, status);
		return false;
	}
}

Cheers
Copello

Read More...

Thomas Stibor replied to the topic 'Updating comet data causes crash' in the forum. 2 weeks ago

How about running https://wiki.ubuntuusers.de/memtest/ . You problem could be the result of some faulty RAM

Read More...

Thomas Stibor replied to the topic 'ASI 120MM no longer working together with EQMod' in the forum. 2 weeks ago

Yes indeed the latest Kernels need devices which comply 100% to the USB standards. Have tried exp time > 1.5sec.
I wrote a simple command line tool ( https://github.com/tstibor/asic ) to control mono ASI cams and to understand the timing problems they have with detailed debug details.
You can use that as an easy starting point to explore which parameter combination suppose to work

Read More...

Thomas Stibor replied to the topic 'ASI 120MM no longer working' in the forum. 2 weeks ago

I have the ASI130mm USB 2.0 which makes the same trouble as the 120mm USB 2.0.
I did also flash the compatibility firmware. However, except that the warning in the Kernel message buffer disappeared, nothing substantially
really changed. Since some Linux Kernel Version >= 3.0 the camera just makes trouble. Before it actually worked.

What works so far (for me) is: Exposure >= 1.5 sec and 8 bit. Whenever the exposure < 1.5 sec or in 16 bit, I am getting the errors.

Read More...

Thomas Stibor replied to the topic 'Updating comet data causes crash' in the forum. 2 weeks ago

Which Distribution are you running?

It it somehow confusing, because according to your backtrace (bt). The crashed finally occured in trimmed_helper which
was called by trimmed which is called by setFromString in dms.cpp:

bool dms::setFromString(const QString &str, bool isDeg)
{
    int d(0), m(0);
    double s(0.0);
    bool checkValue(false), badEntry(false), negative(false);
    QString entry = str.trimmed();
    entry.remove(QRegExp("[hdms'\"°]"));

As one can see, the Parameter is "reference to str" and a bool value.
When I trace the function and breakpoint there I get:
tstibor@polaris:~/dev/astronomy/kstars/build/kstars>gdb ./kstars
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./kstars...done.
(gdb) break dms.cpp:58
Breakpoint 1 at 0x1018a0: file /home/tstibor/dev/astronomy/kstars/kstars/auxiliary/dms.cpp, line 58.
(gdb) run
Starting program: /home/tstibor/dev/astronomy/kstars/build/kstars/kstars 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe187e700 (LWP 24205)]
[New Thread 0x7fffd7ef2700 (LWP 24206)]
[New Thread 0x7fffd76f1700 (LWP 24207)]
org.kde.kstars: Welcome to KStars 3.0.0
org.kde.kstars: Build: 2018-09-02T09:15:01Z
org.kde.kstars: OS: "debian"
org.kde.kstars: API: "x86_64-little_endian-lp64"
org.kde.kstars: Arch: "x86_64"
org.kde.kstars: Kernel Type: "linux"
org.kde.kstars: Kernel Version: "4.9.0-8-amd64"
[New Thread 0x7fffd6ef0700 (LWP 24208)]
[New Thread 0x7fffc53df700 (LWP 24209)]

Thread 1 "kstars" hit Breakpoint 1, dms::setFromString (this=this@entry=0x7fffffffd180, str=..., isDeg=isDeg@entry=true)
    at /home/tstibor/dev/astronomy/kstars/kstars/auxiliary/dms.cpp:58
58	    int d(0), m(0);
(gdb) p *str->d
$1 = {<QArrayData> = {ref = {atomic = {_q_value = {<std::__atomic_base<int>> = {static _S_alignment = 4, _M_i = 4}, <No data fields>}}}, size = 12, alloc = 13, 
    capacityReserved = 0, offset = 24, static shared_null = {{ref = {atomic = {_q_value = {<std::__atomic_base<int>> = {static _S_alignment = 4, 
                _M_i = -1}, <No data fields>}}}, size = 0, alloc = 0, capacityReserved = 0, offset = 24, 
        static shared_null = <same as static member of an already seen type>}, {ref = {atomic = {_q_value = {<std::__atomic_base<int>> = {static _S_alignment = 4, 
                _M_i = 0}, <No data fields>}}}, size = 0, alloc = 0, capacityReserved = 0, offset = 0, 
        static shared_null = <same as static member of an already seen type>}}}, <No data fields>}
(gdb) p isDeg
$2 = true

However, according to you trace:
#2 dms::setFromString (this=0x7fffffffb068, str=..., isDeg=104)
isDeg = 104 and not a bool?? Did you compile with the Debug symbols?

Can you also remove /home/trifid/.local/share/kstars/comets.dat
so it is newly downloaded when update the comet data.

Read More...

Thomas Stibor replied to the topic 'Updating comet data causes crash' in the forum. 2 weeks ago

Just compiled the latest KStars version from GIT, and updating comet data works without any problem (Debian 9.5).
As mentioned before, if you could compile KStars with:

cmake -DCMAKE_BUILD_TYPE=Debug

and run KStars within gdb
tstibor@polaris:~/dev/astronomy/kstars/build/kstars>gdb ./kstars
(gdb) run
Starting program: /home/tstibor/dev/astronomy/kstars/build/kstars/kstars 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe187e700 (LWP 15109)]
[New Thread 0x7fffd7ef2700 (LWP 15110)]
[New Thread 0x7fffd76f1700 (LWP 15111)]
org.kde.kstars: Welcome to KStars 3.0.0
org.kde.kstars: Build: 2018-09-02T09:15:01Z
org.kde.kstars: OS: "debian"
org.kde.kstars: API: "x86_64-little_endian-lp64"
org.kde.kstars: Arch: "x86_64"
org.kde.kstars: Kernel Type: "linux"
org.kde.kstars: Kernel Version: "4.9.0-8-amd64"
[New Thread 0x7fffd6ef0700 (LWP 15112)]
[New Thread 0x7fffc53df700 (LWP 15113)]
[New Thread 0x7fffc458a700 (LWP 15114)]
[New Thread 0x7fffc3d89700 (LWP 15115)]
org.kde.kstars: Processing  "unnamedstars.dat" , HTMesh Level 3
org.kde.kstars:   Sky Mesh Size:  512
org.kde.kstars: Loaded DSO catalog file:  "unnamedstars.dat"
org.kde.kstars: "Star HD20794 not found."
org.kde.kstars: "Star HD98230 not found."
File opened:  "/usr/local/share/kstars/ngcic.dat"
org.kde.kstars: Loading NGC/IC objects
File opened:  "/home/tstibor/.local/share/kstars/comets.dat"
org.kde.kstars: "Object named NGC 6050A not found"
[New Thread 0x7fffc1017700 (LWP 15116)]

and after the crash (segmentation fault) type
(gdb) bt
#0  0x00007ffff24beabb in QTemporaryFile::fileName() const () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x0000555555befcc3 in KSDssDownloader::startSingleDownload (this=0x5555564bf9e0, srcUrl=..., destFileName=..., md=...)
    at /home/tstibor/dev/astronomy/kstars/kstars/auxiliary/ksdssdownloader.cpp:233
#2  0x0000555555bafd65 in EyepieceField::slotDownloadDss (this=0x5555565dbe50) at /home/tstibor/dev/astronomy/kstars/kstars/tools/eyepiecefield.cpp:574
#3  0x00007ffff259f5e9 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff3449422 in QAbstractButton::clicked(bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#5  0x00007ffff3449674 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#6  0x00007ffff344aa67 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x00007ffff344ac44 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x00007ffff33a8278 in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5

then one can see and inspect what is going on.

Cheers
Thomas

Read More...

Thomas Stibor replied to the topic 'canon: can't set frame size' in the forum. 4 weeks ago

Hi there,

by taking a quick look inside the code:

// cdesc contains counter-clock wise e.g. RGBG CFA pattern while we want it sequential as RGGB
    bayer_pattern[0] = RawProcessor.imgdata.idata.cdesc[0];
    bayer_pattern[1] = RawProcessor.imgdata.idata.cdesc[1];
    bayer_pattern[2] = RawProcessor.imgdata.idata.cdesc[3];
    bayer_pattern[3] = RawProcessor.imgdata.idata.cdesc[2];
    bayer_pattern[4] = '\0';

    int first_visible_pixel = RawProcessor.imgdata.rawdata.sizes.raw_width * RawProcessor.imgdata.sizes.top_margin + RawProcessor.imgdata.sizes.left_margin;

One can see that the actual image size is smaller (the first visible pixel does not start at 0), but many pixel later.
There is a nice explanation in the LibRaw forum why that happens: In summary

"Many cameras, including Canons, contains 'masked pixels' around visible area.
Yes, in Canon data these pixels used for black level calibration.
On other cameras (e.g. Nikons) these pixels may be used for banding noise elimination."


So some portion of pixels are masked out, thus the actual size is slightly smaller.

Read More...

Thomas Stibor replied to the topic 'Astrometry.net index files installation problem' in the forum. 4 weeks ago

Yes, this is indeed true with the inparallel option and enough memory. It actually consumes a lot of memory, so running on RPI it is better switching it off !! Thanks for pointing that out.

Read More...

Thomas Stibor replied to the topic 'Astrometry.net index files installation problem' in the forum. 4 weeks ago

It works if you are on a bigendian machine otherwise install the littleendian. However,
as written in your previous post, probably it is much easier to just download them from Dustin Lang's website and put them in a proper directory
and adjust the add_path in astrometry.cfg and I would also recommend to set parameter: inparallel. To the best of my knowledge EKOS just looks
for the binary solve-field which is the astrometry console program and working horse doing the solving job. If for instance you want to solve a bunch of fit files you can do:

for i in *.fit; do solve-field -D /tmp --no-plots --overwrite --downsample 2 --tweak-order 2 --scale-units degwidth --scale-low 0.1 --scale-high 180.0 ${i} -N ${i%.*}_wcs.fit; done

This process can also be speed up when you known approx. your ra/dec position and e.g arcsex/pix. See the parameters of solve-field.
And as mention in a previous post, you can also switch to the GAIA DR2 catalogs

Read More...

Thomas Stibor replied to the topic 'Astrometry.net index files installation problem' in the forum. 4 weeks ago

The DEB files contain the fits, or some are downloaded via wget:

See e.g.

>apt-file list astrometry-data-tycho2-10-19-bigendian
astrometry-data-tycho2-10-19-bigendian: /usr/share/astrometry/index-tycho2-10.bigendian.fits
astrometry-data-tycho2-10-19-bigendian: /usr/share/astrometry/index-tycho2-11.bigendian.fits
astrometry-data-tycho2-10-19-bigendian: /usr/share/astrometry/index-tycho2-12.bigendian.fits
astrometry-data-tycho2-10-19-bigendian: /usr/share/astrometry/index-tycho2-13.bigendian.fits
astrometry-data-tycho2-10-19-bigendian: /usr/share/astrometry/index-tycho2-14.bigendian.fits
astrometry-data-tycho2-10-19-bigendian: /usr/share/astrometry/index-tycho2-15.bigendian.fits
astrometry-data-tycho2-10-19-bigendian: /usr/share/astrometry/index-tycho2-16.bigendian.fits
astrometry-data-tycho2-10-19-bigendian: /usr/share/astrometry/index-tycho2-17.bigendian.fits
astrometry-data-tycho2-10-19-bigendian: /usr/share/astrometry/index-tycho2-18.bigendian.fits
astrometry-data-tycho2-10-19-bigendian: /usr/share/astrometry/index-tycho2-19.bigendian.fits
astrometry-data-tycho2-10-19-bigendian: /usr/share/doc/astrometry-data-tycho2-10-19-bigendian/changelog.Debian.gz
astrometry-data-tycho2-10-19-bigendian: /usr/share/doc/astrometry-data-tycho2-10-19-bigendian/copyright


Read More...

Thomas Stibor replied to the topic 'Astrometry.net index files installation problem' in the forum. 4 weeks ago

Hi there,

there are here: http://broiler.astrometry.net/~dstn/4100/
If you are also interested in the latest Gaia DR2 catalogs see here:
http://data.astrometry.net/5000/

Cheers
Thomas

Read More...

Thomas Stibor replied to the topic 'indi_gphoto_ccd with DSLR T7i' in the forum. 2 months ago

Hi there,

I just comment on github to the problem. Disabling mirror lock (in INDI client) will unfortunately not fix the problem.
Probably it is the best just to #if 0 the two lines where the mirror customex is enabled/disabled. It seems to work on some cameras (e.g. 700D), however,
in the current implementation, also when mirror lockup is disabled, the customex function is called because the customex is stateless. One cannot tell (query) via libphoto2 whether it is enabled/disabled.

Read More...

Thomas Stibor replied to the topic 'Re:RE: Re:Announcing Ekos Live' in the forum. 2 months ago

Hi Jasem,

that is very impressive and another huge step towards making INDI/EKOS a big success.

Thanks for all your work !!!

Read More...

Thomas Stibor replied to the topic 'indi_canon_ccd ERROR:Unsufficient memory' in the forum. 3 months ago

Is there not a

RawProcessor.recycle()
missing at the end of
read_libraw()
before the function return 0 when successful?
I cannot see where the resources are free'd!
In other words:
int read_libraw(const char *filename, uint8_t **memptr, size_t *memsize, int *n_axis, int *w, int *h, int *bitsperpixel,                                                      
                char *bayer_pattern)                                                                                                                                          
{                                                                                                                                                                             
    int ret = 0;                                                                                                                                                              
    // Creation of image processing object                                                                                                                                    
    LibRaw RawProcessor;                                                                                                                                                      
                                                                                                                                                                              
    // Let us open the file                                                                                                                                                   
    if ((ret = RawProcessor.open_file(filename)) != LIBRAW_SUCCESS)                                                                                                           
    {                                                                                                                                                                         
        DEBUGFDEVICE(device, INDI::Logger::DBG_ERROR, "Cannot open %s: %s", filename, libraw_strerror(ret));                                                                  
        RawProcessor.recycle();                                                                                                                                               
        return -1;                                                                                                                                                            
    }                                                                                                                                                                         
                                                                                                                                                                              
    // Let us unpack the image                                                                                                                                                
    if ((ret = RawProcessor.unpack()) != LIBRAW_SUCCESS)                                                                                                                      
    {                                                                                                                                                                         
        DEBUGFDEVICE(device, INDI::Logger::DBG_ERROR, "Cannot unpack %s: %s", filename, libraw_strerror(ret));                                                                
        RawProcessor.recycle();                                                                                                                                               
        return -1;                                                                                                                                                            
    }
...
...
  for (int i = 0; i < RawProcessor.imgdata.rawdata.sizes.height; i++)                                                                                                       
    {                                                                                                                                                                         
        memcpy(image, src, RawProcessor.imgdata.rawdata.sizes.width * 2);                                                                                                     
        image += RawProcessor.imgdata.rawdata.sizes.width;                                                                                                                    
        src += RawProcessor.imgdata.rawdata.sizes.raw_width;                                                                                                                  
    }                                                                                                                                                                         
  
   /* TODO: */
     RawProcessor.recycle()                                                                                                                                                                       
    return 0;                                                                                                                                                                 
}


Read More...

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!