Another option besides chrony etc... is to use e.g. the following python script which fetches the time/date from GPS and set it
simply with a "sudo date" command.

#!/usr/bin/python

import os
import sys
import time
from gps import *

print 'Set System Clock to GPS UTC time'

try:
  gpsd = gps(mode=WATCH_ENABLE)
except:
  print 'ERROR: No GPS Present, time not set!!'
  sys.exit()

while True:
  #wait until the next GPSD time tick
  gpsd.next()
  if gpsd.utc != None and gpsd.utc != '':
    #gpsd.utc is formatted like"2015-04-01T17:32:04.000Z"
    #convert it to a form the date -u command will accept: "20140401 17:32:04"
    #use python slice notation [start:end] (where end desired end char + 1)
    #   gpsd.utc[0:4] is "2015"
    #   gpsd.utc[5:7] is "04"
    #   gpsd.utc[8:10] is "01"
    gpsutc = gpsd.utc[0:4] + gpsd.utc[5:7] + gpsd.utc[8:10] + ' ' + gpsd.utc[11:19]
    os.system('sudo date -u --set="%s"' % gpsutc)
    sys.exit()



 

Read More...

Well, you could also try to modify in file CMakeLists.txt the entry:

find_package(INDI 1.9.1)

to

find_package(INDI 1.8.9)

or some prior version and see whether it works as expected.

Read More...

Hmm that sounds indeed strange....

How about running your tests in full debug mode and providing the log files.

Read More...

Latest kstars (git master) requires at least INDI version 1.9.1

[thomas@x230 ~/dev/astronomy/kstars/kstars]$ grep -rn "find_package(INDI 1.9.1)" CMakeLists.txt
206: find_package(INDI 1.9.1)

otherwise INDI support (EKOS) is not included. That is, kstars is compiled without INDI+EKOS


-- The following OPTIONAL packages have not been found:

* INDI (required version >= 1.9.1), Astronomical instrumentation control, <www.indilib.org>
Support for controlling astronomical devices on Linux with KStars.

-- Configuring done
-- Generating done

Compile/install latest (git master) INDI and then you can compile kstars with INDI/EKOS support

Read More...

Hi there,

did you check whether the problem is also occurring with version 1.8.9? Since version 1.9.0 a lot of code is C++ modernized and this could
be a side effect. I am testing on master, but observing/imaging on version 1.8.9.

Cheers
Thomas

Read More...

As you mentioned the stty is identical, so the problem must be somewhere else. The commands GR, GD, Gm are listed in the source code here:

[thomas@x230 ~/dev/astronomy/indilib/indi/drivers/telescope]$ grep -r ":GR#\|:GD#\|:Gm#" .
./eq500x.cpp: else if (getCommandString(PortFD, b, ":GD#") < 0)
./eq500x.cpp: else if (getCommandString(PortFD, b, ":GR#") < 0)
./lx200pulsar2.cpp: return (getSexa(fd, "#:GR#", ra) && getSexa(fd, "#:GD#", dec));
./lx200pulsar2.cpp: bool success = PulsarTX::sendReceive(fd, "#:GR#", response);
./lx200driver.cpp: DEBUGFDEVICE(lx200Name, DBG_SCOPE, "CMD <%s>", ":GR#");
./lx200driver.cpp: if ((error_type = tty_write_string(fd, ":GR#", &nbytes_write)) != TTY_OK)
./lx200driver.cpp: DEBUGFDEVICE(lx200Name, DBG_SCOPE, "CMD <%s>", ":GR#");
./lx200driver.cpp: if ((error_type = tty_write_string(fd, ":GR#", &nbytes_write)) != TTY_OK)
./lx200driver.h:#define getLX200RA(fd, x) getCommandSexa(fd, x, ":GR#")
./lx200driver.h:#define getLX200DEC(fd, x) getCommandSexa(fd, x, ":GD#")
./lx200gemini.cpp: // Send ':Gm#'
./lx200gemini.cpp: const char *cmd = ":Gm#";
./magellandriver.h:#define getMAGELLANRA(fd, x) getCommandSexa(fd, x, "#:GR#")
./magellandriver.h:#define getMAGELLANDEC(fd, x) getCommandSexa(fd, x, "#:GD#")
./rainbow.cpp: if (sendCommand(":GR#", res) == false)
./rainbow.cpp: if (sendCommand(":GD#", res) == false)
./ioptronHC8406.cpp::GR# 2:12:57.4# RA
./ioptronHC8406.cpp::GD# +90* 0: 0# DEC
./crux_mount.cpp: sprintf(szCommand, "#:\\GE($GR #:GR#"
./crux_mount.cpp: ":\\GE$GD #:GD#"
./lx200_OnStep.cpp: getCommandString(PortFD, OSPier, ":Gm#");
./lx200_OnStep.cpp: // * 94 pierSide (N if never) {Same as :Gm# (E, W, None)}

Read More...

Hi there,

you could try (after connecting the serial cable) running running stty -a -F /dev/ttyUSB0, resp. -F /dev/ttyS0 to see how it's set up.
For my Celestron AUX converter it e.g. is configured as follows

$ stty -a -F /dev/ttyACM0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

Read More...

Yes it is a firmware issue and not hardware issue. The so compatibility firmware just makes sure that the max packetsize follow the USB 2 specification and is 512 rather than 1024 bytes.
However, the issues are still remain. Switching to 8 Bit helps but there are also randomly issues (and it is for sure not the cable).
In 16 Bit mode it is like tossing a biased coin, towards not working.


./zwo_FWTool_USB2 -i ../../../firmware/USB2.0/ASI130MM.iic -t li2c
[36233.666737] usb 1-1.2: new high-speed USB device number 8 using ehci-pci
[36233.919714] usb 1-1.2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 1024
[36233.921050] usb 1-1.2: New USB device found, idVendor=03c3, idProduct=130a, bcdDevice= 0.00
[36233.921054] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36233.921056] usb 1-1.2: Product: ASI130MM
[36233.921058] usb 1-1.2: Manufacturer: ZWOptical company
[36233.921060] usb 1-1.2: SerialNumber: 00000

./zwo_FWTool_USB2 -i ../../../firmware/USB2.0/ASI130MM-compatible.iic -t li2c
[36214.974532] usb 1-1.2: new high-speed USB device number 6 using ehci-pci
[36215.188389] usb 1-1.2: New USB device found, idVendor=03c3, idProduct=130a, bcdDevice= 0.00
[36215.188393] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36215.188395] usb 1-1.2: Product: ASI130MM
[36215.188397] usb 1-1.2: Manufacturer: ZWOptical company
[36215.188398] usb 1-1.2: SerialNumber: 00000

The binary diff between the two firmwares is:

$ cmp -l ASI130MM-compatible.iic ASI130MM.iic | awk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
000001FA 02 04
000002A6 02 04
0000031A 02 04
0000038C 02 04
00000958 02 04
00000B48 02 04

One can for fun, change the "02" to "01", then the USB kernel layer complains:
config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 256

Anyhow, it is still a shame, that ZWO is not able to fix the firmware. At least they could release the code and somebody would for
sure fix it for them. Just search on github.com for ASI120mm, you will find some projects reverse engineered the SDK library.

I am wondering how many INDI users had to sell (stop using) there 120/130mm cameras.
I bought a used Starlight Xpress guider and did not regret it. 130mm was my only and last ZWO product.

Read More...

Hi there,

another option is also build an AUX cable in connection with some AVR MCU (e.g. Arduino Beetle). The AUX cable is be plugged in AUX port of the mount and the the AVR via USB to INDI.
There exists a great project project github.com/juanmb/NexStarAdapter where all details are explained. The software running on the AVR MCU emulates the handcontrol. This allows
to use the INDI Celestron AVX driver. In addition one can think about the option of modifying the AVR MCU code provided at github.com/juanmb/NexStarAdapter as a straight pass-through, that is,
one could use the indi_celestron_aux driver. I haven't tested the latter option, only the first. But both option would allow you so omit the handcontrol.
I attached some pictures of the cable/Beetle I built.

Cheers
 Thomas

Read More...

I cannot comment on QHY, but only on ASI ZWO 130mm.
This camera just makes troubles on Linux, and no ASI SDK or firmware update so far solves it.
So in other words, one has to buy a new (guiding) camera or hope that it will somehow run
with the 8-Bit hack. I finally gave up, and bought a Starlight Xpress and do not regret that at all (although
more expensive than ASI ZWO).

Please also check some older GIT commits such as:

commit 47227c00a6accb102561cd68c7211d668905f035
Author: Jasem Mutlaq <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Thu Apr 15 17:53:28 2021 +0300

Revert ASICAM camera SDK to 1.16 due to bugs and crashes

or

commit 247f92c9795dc7634670e447027804f76f655dd8
Author: Jarno Paananen <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Tue May 18 12:14:25 2021 +0300

Updates to ZWO SDKs (#403)

ASI Camera SDK 1.18
EAF SDK 1.4
EFW SDK 1.7

Unfortunately changelogs are just "Fix some bugs"

From my experience I would rather buy a slightly more expensive but very well supported camera,
such as Moravian Instruments or Starlight Xpress, rather than a ZWO, due to bugs in SDK.
I also have good experience with ATIK, no problems in several years and updates.

But please keep in mind, this is my biased opinion.

Read More...

Connect your device and type the following in the terminal

$ sudo dmesg && lsusb

/usr/lib/udev/rules.d

$cat 99-indi_aux_ppb.rules
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{product}=="*PPB*", SYMLINK+="ttyPPB", MODE="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0424", ATTRS{idProduct}=="2517", MODE="0666"

$sudo udevadm trigger

If astap is installed via an APT-Repo then the following command works:

sudo apt-get update && sudo apt-get --only-upgrade install astap

wget https://sourceforge.net/projects/astap-program/files/linux_installer/astap_armhf.deb/download -O /tmp/astap_armhf.deb

sudo dpkg --install /tmp/astap_armhf.deb