Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Lin_guider 3.1.0 has been released

  • Please log in to reply
25 replies to this topic

#1 rumen

rumen

    Lift Off

  • -----
  • topic starter
  • Posts: 21
  • Joined: 02 Apr 2015

Posted 14 April 2015 - 06:13 AM

I am glad to announce that Lin_guider 3.1.0 has been released. It can be found here: http://sourceforge.n...ects/linguider/

Lin-guider is an open source astronomical auto guiding software for Linux.

 

Supported cameras:

* QHY5, QHY6, QHY5L-II-M, QHY5L-II-C, QHY5-II

* Meade DSI II Pro

* Atik (all except Atik GP)

* Starlight Xpress

* ZWO ASI

* Various webcams

 

Supported Pulse drivers:

* FTDI chip-based 

* parallel port-based (LPT) 

* GPIO-based

* GPUSB devices

* Direct support for Celestron Nexstar protocol based mounts

* All supported cameras with ST4 port.

 

What is new in 3.1.0:

* Make reticle and square dragging responsive (independent of the exposure time)
* Reticle can be moved if the square is over it

* Last used square is now saved in configuration
* Make ASI buffer cleaning optional for better performance
* Add new dithering commands GET_DISTANCE and DITHER_NO_WAIT_XY
* Accept commands over TCP or Unix Sockets(default)
* Make Atik and SX drivers prefer the first camera with ST4 port
* Fixes in Atik, ASI and QHY5 drivers
* Created lg_tool.pl to be used as a dithering agent or as standalone application

 

Here is a screenshot of Lin-guider 3.0.0 used for guiding the 2-meter Ritchey-Cretien telescope with the Echelle Spectrograph of Bulgarian National Observatory (the hole in the center is where the optical fiber is, so it is guided with what is left from the stellar image, trying to keep the most of the starlight in the optical fiber for the spectrograph): 

Screenshot from 2015-02-22 14_51_09.png


Edited by rumen, 14 April 2015 - 06:30 AM.


#2 tjay

tjay

    Vanguard

  • *****
  • Posts: 2181
  • Joined: 03 Feb 2007
  • Loc: just outside of Toronto

Posted 14 April 2015 - 11:43 PM

Rumen,

 

Thanks for all the great work on Lin_guider.

 

Any chance that a regular Meade DSI or DSI II will work, now or in the future?  I've got a DSI mono and DSI II colour I'd love to use.



#3 rumen

rumen

    Lift Off

  • -----
  • topic starter
  • Posts: 21
  • Joined: 02 Apr 2015

Posted 15 April 2015 - 03:42 AM

Tom,

Thank you for the nice words, Andrew and I are trying to make Lin_guider as good as we can :)

 

> Any chance that a regular Meade DSI or DSI II will work, now or in the future?  I've got a DSI mono and DSI II colour I'd love to use.

 

unfortunately there are no plans to make DSI or DSII work with Lin_guider. And I do not think they will work out of the box. But still we may make them work at some point. The problem is that I have none of these cameras, and as far as I know Andrew does not have them either. You may probably know that to make some piece of hardware work, you need the hardware otherwise it is very complicated, sometimes next to impossible, especially without a specification or a simulator. So unless some owner with reasonable programming skills writes a driver or some of us manages to get his hands on these cameras and has some extra time to spare there will be no driver. Unfortunately this is how it works with non commercial open source software... 

 

Rumen



#4 brave_ulysses

brave_ulysses

    Viking 1

  • -----
  • Posts: 921
  • Joined: 19 Apr 2009
  • Loc: touching the distant sands

Posted 15 April 2015 - 12:13 PM

thank you!



#5 tjay

tjay

    Vanguard

  • *****
  • Posts: 2181
  • Joined: 03 Feb 2007
  • Loc: just outside of Toronto

Posted 15 April 2015 - 09:20 PM

Tom,

Thank you for the nice words, Andrew and I are trying to make Lin_guider as good as we can :)

 

> Any chance that a regular Meade DSI or DSI II will work, now or in the future?  I've got a DSI mono and DSI II colour I'd love to use.

 

unfortunately there are no plans to make DSI or DSII work with Lin_guider. And I do not think they will work out of the box. But still we may make them work at some point. The problem is that I have none of these cameras, and as far as I know Andrew does not have them either. You may probably know that to make some piece of hardware work, you need the hardware otherwise it is very complicated, sometimes next to impossible, especially without a specification or a simulator. So unless some owner with reasonable programming skills writes a driver or some of us manages to get his hands on these cameras and has some extra time to spare there will be no driver. Unfortunately this is how it works with non commercial open source software... 

 

Rumen

Thanks for the reply.   I wondered if the sample code out on the net might be enough to get something working.   If I had time,  I might give it shot myself



#6 rumen

rumen

    Lift Off

  • -----
  • topic starter
  • Posts: 21
  • Joined: 02 Apr 2015

Posted 16 April 2015 - 05:03 AM

 

Tom,

Thank you for the nice words, Andrew and I are trying to make Lin_guider as good as we can :)

 

> Any chance that a regular Meade DSI or DSI II will work, now or in the future?  I've got a DSI mono and DSI II colour I'd love to use.

 

unfortunately there are no plans to make DSI or DSII work with Lin_guider. And I do not think they will work out of the box. But still we may make them work at some point. The problem is that I have none of these cameras, and as far as I know Andrew does not have them either. You may probably know that to make some piece of hardware work, you need the hardware otherwise it is very complicated, sometimes next to impossible, especially without a specification or a simulator. So unless some owner with reasonable programming skills writes a driver or some of us manages to get his hands on these cameras and has some extra time to spare there will be no driver. Unfortunately this is how it works with non commercial open source software... 

 

Rumen

Thanks for the reply.   I wondered if the sample code out on the net might be enough to get something working.   If I had time,  I might give it shot myself

 

Well one may use some code from the net, and if lucky it will work somehow. The real trouble is to make it stable and to polish the rough edges. Many cameras have their oddities and there is no way to know them in advance. For example if you set gain on QHY5II while exposure is in progress there is a good chance that the camera will hang and should be reconnected, so this should be forbidden by the software, also if the camera is in 16bit mode the ST4 port does not work and many more. ZWO ASI cameras have another odd "feature" one has to read the frame twice to make sure the new exposure is read otherwise you may end up with the old exposure being used again.

Some cameras in binning mode do not return X/2 by Y/2 image but let us say X/2+1 by Y/2 and many more. You may be able to figure out some of them by looking at the code but you will never know if this is a wired workaround or just badly written code. I hope you get the idea :)



#7 tjay

tjay

    Vanguard

  • *****
  • Posts: 2181
  • Joined: 03 Feb 2007
  • Loc: just outside of Toronto

Posted 17 April 2015 - 06:06 PM

 

 

Tom,

Thank you for the nice words, Andrew and I are trying to make Lin_guider as good as we can :)

 

> Any chance that a regular Meade DSI or DSI II will work, now or in the future?  I've got a DSI mono and DSI II colour I'd love to use.

 

unfortunately there are no plans to make DSI or DSII work with Lin_guider. And I do not think they will work out of the box. But still we may make them work at some point. The problem is that I have none of these cameras, and as far as I know Andrew does not have them either. You may probably know that to make some piece of hardware work, you need the hardware otherwise it is very complicated, sometimes next to impossible, especially without a specification or a simulator. So unless some owner with reasonable programming skills writes a driver or some of us manages to get his hands on these cameras and has some extra time to spare there will be no driver. Unfortunately this is how it works with non commercial open source software... 

 

Rumen

Thanks for the reply.   I wondered if the sample code out on the net might be enough to get something working.   If I had time,  I might give it shot myself

 

Well one may use some code from the net, and if lucky it will work somehow. The real trouble is to make it stable and to polish the rough edges. Many cameras have their oddities and there is no way to know them in advance. For example if you set gain on QHY5II while exposure is in progress there is a good chance that the camera will hang and should be reconnected, so this should be forbidden by the software, also if the camera is in 16bit mode the ST4 port does not work and many more. ZWO ASI cameras have another odd "feature" one has to read the frame twice to make sure the new exposure is read otherwise you may end up with the old exposure being used again.

Some cameras in binning mode do not return X/2 by Y/2 image but let us say X/2+1 by Y/2 and many more. You may be able to figure out some of them by looking at the code but you will never know if this is a wired workaround or just badly written code. I hope you get the idea :)

 

 

I definitely get the idea.  I've done some device driver development, but I don't seem to have the time to dedicate to do stuff like this anymore.   I wish my DSI's worked under Linux, maybe a vacation project sometime :)



#8 rumen

rumen

    Lift Off

  • -----
  • topic starter
  • Posts: 21
  • Joined: 02 Apr 2015

Posted 18 April 2015 - 04:19 PM

 

I definitely get the idea.  I've done some device driver development, but I don't seem to have the time to dedicate to do stuff like this anymore.   I wish my DSI's worked under Linux, maybe a vacation project sometime :)

 

 

This is the way the open source works :)

 

You have hardware and there is no driver for it and you know how to do it, you write one and give it to the community. This is the small price you pay for the tons of software you are using for free :)

 

Please let us know if you decide to make a driver!



#9 patdut63fromFr

patdut63fromFr

    Explorer 1

  • -----
  • Posts: 67
  • Joined: 31 Jul 2007
  • Loc: France

Posted 13 May 2015 - 12:41 AM

Hello Rumen,

 

Do you planed to include drivers of DMK cameras from imaging source ?

I think they are available there: http://unicap-imagin..._devices_en.htm

 

Thanks for answering

 

Patrick



#10 AdirondackAstro

AdirondackAstro

    Messenger

  • *****
  • Posts: 419
  • Joined: 06 Jun 2011
  • Loc: Plattsburgh, NY

Posted 18 July 2015 - 04:05 PM

I know this thread is a bit old, but I am having an issue getting up and running in Lin_Guider.

 

I have followed the instructions to get Lin_Guider installed with the correct drivers for a QHY5.

I am using an Orion Starshoot Autoguider which uses the QHY5 chip (from what I've read, so I should be setup properly).

In Lin_Guider I have selected QHY5 as my camera, and QHY5 in Driver Setup. 

When I start Lin_Guider I get no errors that my options are wrong, and I get video, but I don't get any guiding. I have gone into Driver Setup and clicked the RA+ DEC- DEC+ and RA- buttons and get no movement in the mount. 

I attempted calibration on a star and nothing happens, no time-outs, no signs of anything happening, and no pulse noises in the mount like it is moving and calibrating at all.

 

I've read up on so many things and I'm at a loss, that is actually how I found this post, by searching google for answers.

 

My setup is Linux Mint 17.1 64-bit, Orion Starshoot Autoguider, CG-5 AS-GT mount. 



#11 anat

anat

    iAstroHub 3

  • *****
  • Vendors
  • Posts: 1088
  • Joined: 03 Jun 2004

Posted 18 July 2015 - 06:46 PM

Check if your device firmware is properly loaded using:

lsusb   and 

dmesg

 

Do you images from the camera ?

Sometimes, you may need to use "sudo" to run LG.

 

Anat



#12 AdirondackAstro

AdirondackAstro

    Messenger

  • *****
  • Posts: 419
  • Joined: 06 Jun 2011
  • Loc: Plattsburgh, NY

Posted 19 July 2015 - 11:01 AM

Check if your device firmware is properly loaded using:

lsusb   and 

dmesg

 

Do you images from the camera ?

Sometimes, you may need to use "sudo" to run LG.

 

Anat

 

Thanks for responding, Anat. Here are the results of lsusb and dmesg. Yes I do get images from the camera. I was able to find stars in the camera when I took it out and tested it, but was unable to calibrate and guide since there seemed to be absolutely no movement in the scope from the autoguider.

 

lsusb:

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 0bda:58c2 Realtek Semiconductor Corp. 
Bus 001 Device 004: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 006: ID 0cf3:0036 Atheros Communications, Inc. 
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 16c0:296d Van Ooijen Technische Informatica 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

dmesg (only the last 10 lines):

[  233.974896] usb 3-2: new high-speed USB device number 2 using xhci_hcd
[  233.990993] usb 3-2: New USB device found, idVendor=1856, idProduct=0011
[  233.990998] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  234.089373] usb 3-2: USB disconnect, device number 2
[  235.822262] usb 3-2: new high-speed USB device number 3 using xhci_hcd
[  235.838711] usb 3-2: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[  235.839056] usb 3-2: New USB device found, idVendor=16c0, idProduct=296d
[  235.839061] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  235.839064] usb 3-2: Product: QHY5-CMOS
[  235.839066] usb 3-2: Manufacturer: QHY_CAMS

It appears it is working, and showing up like it should (unless I'm missing something within all this), so that is why I'm confused as to why it isn't calibrating/guiding/moving when I press the RA or DEC buttons within Lin_Guider.

 

This is what the terminal looks like when I first start it:

sudo ./lin_guider
[1437322072:898] Starting Lin_guider...
[1437322072:908] lusb::initialize(): Success
[1437322072:908] qhy5_core_shared object successfully opened.
[1437322072:908] mapped =0
[1437322072:908] Trying QHY5...
[1437322072:908] Control gain id=9963795
[1437322072:908] Gain supported
[1437322072:908] Control exposure id=9963793
[1437322072:908] Exposure supported
[1437322072:908]   Frame rate:   1/2 fps
[1437322072:908] Sending send command 0x42, 0x13, 0xf63c, 0x0018, 19 bytes

[1437322073:140] Sending send command 0x42, 0x14, 0x31a5, 0x0000, 0 bytes

[1437322073:151] Sending send command 0x42, 0x16, 0x0001, 0x0000, 0 bytes

[1437322073:171] Sending recv command 0xc2, 0x12, 0x07d0, 0x0000, 2 bytes

[1437322073:171] Exposure started
[1437322075:171] Exposure finished. Reading 1635900 bytes
[1437322075:281] Downloading finished. Read: 1635900 bytes
[1437322075:281] Sending send command 0x42, 0x13, 0xf63c, 0x0018, 19 bytes

[1437322075:594] Sending send command 0x42, 0x14, 0x31a5, 0x0000, 0 bytes

[1437322075:605] Sending send command 0x42, 0x16, 0x0000, 0x0000, 0 bytes

[1437322075:605] Sending send command 0x42, 0x13, 0xf63c, 0x0018, 19 bytes

[1437322075:917] Sending send command 0x42, 0x14, 0x31a5, 0x0000, 0 bytes

[1437322075:929] Sending send command 0x42, 0x16, 0x0000, 0x0000, 0 bytes

[1437322075:931] SRV: listening on Unix socket /tmp/lg_ss
[1437322075:952] Started successfully
[1437322075:977] Sending recv command 0xc2, 0x12, 0x07d0, 0x0000, 2 bytes

[1437322075:977] Exposure started
[1437322077:977] Exposure finished. Reading 1635900 bytes
[1437322078:087] Downloading finished. Read: 1635900 bytes
[1437322078:110] Sending recv command 0xc2, 0x12, 0x07d0, 0x0000, 2 bytes

When I run Lin_Guider and press one of the RA buttons this is what I get in the terminal:

[1437321950:123] outp tick 123445299
[1437321950:123] mapped =0
[1437321950:123] Sending recv command 0xc2, 0x18, 0x0000, 0x0000, 2 bytes

[1437321950:307] outp tick 307199988
[1437321950:307] mapped =1
[1437321950:307] Sending recv command 0xc2, 0x18, 0x0000, 0x0000, 2 bytes

[1437321950:307] Sending send command 0x42, 0x10, 0x0000, 0x0010, 8 bytes

[1437321950:308] outp tick 308392070
[1437321950:308] mapped =0
[1437321950:308] Sending recv command 0xc2, 0x18, 0x0000, 0x0000, 2 bytes

[1437321951:681] mapped =0
[1437321951:681] Sending recv command 0xc2, 0x18, 0x0000, 0x0000, 2 bytes

[1437321951:745] Exposure finished. Reading 1635900 bytes
[1437321951:854] Downloading finished. Read: 1635900 bytes
[1437321951:879] Sending recv command 0xc2, 0x12, 0x07d0, 0x0000, 2 bytes

[1437321951:879] Exposure started
[1437321953:879] Exposure finished. Reading 1635900 bytes
[1437321953:948] Downloading finished. Read: 1635900 bytes
[1437321953:971] Sending recv command 0xc2, 0x12, 0x07d0, 0x0000, 2 bytes

[1437321953:971] Exposure started
[1437321955:387] Device config saved
[1437321955:972] Exposure finished. Reading 1635900 bytes
[1437321956:040] Downloading finished. Read: 1635900 bytes
[1437321956:043] qhy5_core_shared::close_device(): Success
[1437321956:043] lusb::release(): Success
[1437321956:073] SRV:in_queue.size(): 0
[1437321956:073] SRV:out_queue.size(): 0
[1437321956:073] SRV:stopped
[1437321956:074] Terminated successfully.

Edited by AdirondackAstro, 19 July 2015 - 11:59 AM.


#13 anat

anat

    iAstroHub 3

  • *****
  • Vendors
  • Posts: 1088
  • Joined: 03 Jun 2004

Posted 20 July 2015 - 10:16 AM

In the drive setup (second icon), make sure you set the drive to QHY5. Use the nudge buttons to check if the mount moves correctly. You may need to set the guide speed in the mount to maximum so that the change is detectable from the mount controller. You should see the RA and DEC values changing when holding a button.

 

Anat


Edited by anat, 20 July 2015 - 10:19 AM.


#14 AdirondackAstro

AdirondackAstro

    Messenger

  • *****
  • Posts: 419
  • Joined: 06 Jun 2011
  • Loc: Plattsburgh, NY

Posted 20 July 2015 - 11:29 AM

Anat,

I do have QHY5 selected in Drive setup, and have clicked the buttons with no noises coming from the gears when I do, with the mount set to max. The result of clicking one of the RA buttons gave me this in the terminal, but no gear sounds. Also, holding the button seems to do nothing so I have to constantly press it (which is fine) in order to get any return in the terminal.

[1437321950:123] outp tick 123445299
[1437321950:123] mapped =0
[1437321950:123] Sending recv command 0xc2, 0x18, 0x0000, 0x0000, 2 bytes

[1437321950:307] outp tick 307199988
[1437321950:307] mapped =1
[1437321950:307] Sending recv command 0xc2, 0x18, 0x0000, 0x0000, 2 bytes

[1437321950:307] Sending send command 0x42, 0x10, 0x0000, 0x0010, 8 bytes

[1437321950:308] outp tick 308392070
[1437321950:308] mapped =0
[1437321950:308] Sending recv command 0xc2, 0x18, 0x0000, 0x0000, 2 bytes

[1437321951:681] mapped =0
[1437321951:681] Sending recv command 0xc2, 0x18, 0x0000, 0x0000, 2 bytes


#15 anat

anat

    iAstroHub 3

  • *****
  • Vendors
  • Posts: 1088
  • Joined: 03 Jun 2004

Posted 20 July 2015 - 06:33 PM

The problem can be anywhere between the QHY guider port and the mount guider port. Try using another program (EZcap or EXplanetary) and nudge the button on the program to see if your mount responds. If it responds, it means that the problem is at LG.

 

Anat



#16 AdirondackAstro

AdirondackAstro

    Messenger

  • *****
  • Posts: 419
  • Joined: 06 Jun 2011
  • Loc: Plattsburgh, NY

Posted 08 August 2015 - 01:21 AM

Sorry for bringing this post back up. I got Lin_Guider working good on my computer after switching from Linux Mint to Ubuntu. My question now is: do I have to recalibrate every time I move to another part of the sky? It doesn't take long to do, but not sure if there is a way to image one object, move to another and begin guiding without calibrating in the new spot? I could understand having to recalibrate when doing a meridian flip, but I'm working with the same section of sky.



#17 anat

anat

    iAstroHub 3

  • *****
  • Vendors
  • Posts: 1088
  • Joined: 03 Jun 2004

Posted 10 August 2015 - 04:08 AM

I usually don't recalibrate the guider when imaging on the same side of the sky, except at areas close to the poles.



#18 AdirondackAstro

AdirondackAstro

    Messenger

  • *****
  • Posts: 419
  • Joined: 06 Jun 2011
  • Loc: Plattsburgh, NY

Posted 10 August 2015 - 06:48 AM

Anat, I attempted slewing and the picking a star and hitting guide, but the arrows didn't move to the new star location. I only played with it for a little while so maybe I missed a step. Will have to try on next clear night.

Thanks for the response.

#19 mjhall29

mjhall29

    Lift Off

  • -----
  • Posts: 2
  • Joined: 19 Aug 2015

Posted 20 August 2015 - 08:21 AM

Sorry to be a pain but I am new to all this, I have been searching for a way to get the gpio configured for the raspberry pi 2. I can see it has been done but cant see how it was done, can anyone give me site i can look at or some idea where to start. I can make thesimple hardware to communicate with my AVX mount but haven't got the programming knowledge.

I have set up the PI two ways on one sd card with starspi. on the other directly from the lin_guider site. both work and both are set up as wifi access points. 

I did think of installing iastrohub but i dont know which way to go ? 

please help.

 

Thanks in advance.

 

Regards, Martin



#20 rumen

rumen

    Lift Off

  • -----
  • topic starter
  • Posts: 21
  • Joined: 02 Apr 2015

Posted 05 November 2015 - 09:16 AM

Hi all, I am glad to announce the release of Lin_guider 3.2.0 here is the list of changes:

 

* Fixed DEC swapping in GPIO driver
* Guider window UI tweaks
* Add adjust window to fit image button
* Add support for all Bayer patterns

* Always use '.' in floating point numbers, regardless of the locale
* Add normalization of gain coefficients, if enabled changing the guide rate will affect directly the guiding
* Restore reticle angle after restart
* Use latest Atik SDK (0.34)
* Use latest ASI SDK (0.1.0803)
* Add colour support for ASI cameras
* Add 16-bit support for ASI cameras
* Fix several issues in ASI driver
* Small fix in Starlight Xpress driver

 

http://sourceforge.n...ects/linguider/

Thank you!

Rumen


Edited by rumen, 05 November 2015 - 01:45 PM.

  • brave_ulysses, Alexander Wolf and bsavoie like this

#21 calli

calli

    Vostok 1

  • -----
  • Posts: 129
  • Joined: 16 Dec 2015
  • Loc: Berlin, Germany

Posted 12 January 2016 - 04:12 PM

@rumen: Is the Raspi Cam Module supported? I get errors while linguider tries to find a resolution/framerate.

 

Cheers,

Carsten



#22 calli

calli

    Vostok 1

  • -----
  • Posts: 129
  • Joined: 16 Dec 2015
  • Loc: Berlin, Germany

Posted 13 January 2016 - 11:33 AM

I managed to get linguider running on a Raspberry Pi (one). I can't say it is actually guiding however...


I have a alt/azm Nexstar SLT, I know that is not supported as it seems, but I just wanted to go through the process and set all up. I would say that it should work in a way that the normal tracking is switched off and then ONLY linguider follows the star. That should (in theory) make a difference in accuracy.

The Raspi is in a housing with a 1.25 inch tube on the Camera module (No IR filter here).


- Raspi Cam Module works

      - you need to load the bcm2835-v4l2 module

- linguider is tracking my teststar

      - I needed to adjust the framerate to 30 in the linguider config

- USB->Serial adapter connected to HC

    - use minicom to check

- libnexstar

   - tested it with the example programs coming with the lib

   - added my user to the dialout group, so I don't need to  run as root

- starting guiding

    - the sound of the mount changes! So there must happen something :-) Not sure what...

- The camera control from linguider is quite limited, but you can always use v4l2-ctl to tune your camera

Beside that I have not the faintest idea how that normally works, I guess I need to calibrate and train it somehow, but due to the nonexistant docs I have no clue so far...

 

Cheers,

Carsten



#23 lambermo

lambermo

    Viking 1

  • -----
  • Posts: 829
  • Joined: 16 Jul 2007
  • Loc: .nl

Posted 17 January 2016 - 06:35 AM

Not trying to hijack this thread, but i'm wondering if anyone here has compared Lin_guider to PHD2 + INDI. I'm interested in the results which I think can help both projects further.

 

-- Hans



#24 knro

knro

    StellarMate

  • -----
  • Vendors
  • Posts: 167
  • Joined: 08 Nov 2011
  • Loc: Kuwait

Posted 24 January 2016 - 01:38 AM

Not trying to hijack this thread, but i'm wondering if anyone here has compared Lin_guider to PHD2 + INDI. I'm interested in the results which I think can help both projects further.

 

-- Hans

 

INDI will be always slower than direct communication with the camera since INDI is a server/client framework and camera data are base64 encoded/decoded at the driver and client sides respectively. Notwithstanding that, INDI has a larger support of devices. Furthermore, you can use Ekos, which is a complete astrophotography tool and includes a guiding module based on lin_guider, so you essentially get the best of the two worlds.



#25 groz

groz

    Vanguard

  • *****
  • Posts: 2148
  • Joined: 14 Mar 2007
  • Loc: Campbell River, BC

Posted 24 January 2016 - 08:15 PM

 


 

INDI will be always slower than direct communication with the camera since INDI is a server/client framework and camera data are base64 encoded/decoded at the driver and client sides respectively.

 

In a purely theoretical manner, this is true, but, not necessarily in the real world applications.  To define slower, you have to define where all the latencies etc are in the system.  The largest latency in a guiding system comes from exposure time.  If you are doing 1 second exposures, then, your data is already a half second old by the time you begin camera readout.  Then the data has to be moved across the usb bus, and into the host for processing, another measureable length of time, probably measured in tens of milliseconds.  The next step, send base64 encode and send over a network, is entirely dependant on the speed of the processor, and the speed of the network.  Network speed is essentially infinite for a locally connected system.  Use the case here, indi server on an Atom processor board, with gigabit to the clients, the amount of time it takes to encode and transmit a guide frame to the client is lost in the noise of usb interruptions when measuring the time it takes to extract the frame from the camera over the usb port.

 

So when I look at our system from end to end, exposure time in the range of a second, 500ms average for latency (half the exposure time).  Extract guide image from camera is on the order of 20ms, encode and transmit over gigabit is on the order of 2ms.  The times added to the system overall due to being remote are inconsequential in the overall equation.  BUT, if you are using something like a raspberry pi on the remote end, the numbers change dramatically.  That unit has a 100mbit ethernet , which is under the covers a usb attached device, so a 10x increase in the time to transmit, aggravated farther by contention on the usb bus.  In that scenario, the remote nature of the device combined with the lower cpu power available for encoding, will significantly change the latency equation.

 

Direct communication will indeed always be faster, but, just how much faster depends on overall end to end system design.  In a well designed system, it may be faster, but the difference is so small as to be inconsequential.


Edited by groz, 24 January 2016 - 08:16 PM.



CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics