Using the Astrophysics experimental driver, I would like to slew my AP900 CP3 mount to a star located in the south-east part of the sky (say 10 degrees east of the meridian), with the counterweigth somewhat above the scope, so that when the star crosses the meridian, the counterweight will move lower than the scope, with no need of a meridian flip, and no disruption of the imaging session. I can do that manually using the handset (AP documents that feature very neatly), but would like to use the indi driver to achieve the same.
1- Using the Indi gui, one can set a meridian delay decimal value. What is the unit of this value ? Hours, tens of degrees ?
2- Apparently, the value are constrained between 0 and 3. So which correct value should I enter to move the 'apparent' meridian to 15 degrees east of the real meridian (i.e. one hour of HA angle) ?
Here is the requested screenshot.
I can confirm that this new flavour of the driver works very well, including the initialization procedure.
I noticed the temperature is only displayed if the sensor is plugged, which seems logical. And it is updated every 10 seconds or so.
Thanks a lot for that great work.
Testing the kstars/ekos ecosystem, I also had some crashes just by trying to display some stats or histograms of previously acquired images. No real stress, just looking at some values to see if there is any risk of saturation or so. But 1 time of 3, pressing such a button in the fits viewer just makes the whole kstars/ekos stack go away, no remission. That major instability kept me away from ekos, and makes me use ccdciel that is more reliable.
As far as I can see, the ubuntu package repository has only been updated for the Amd64 architecture, leaving out the i386 one. For instance, the i386 flavour of the indi-bin package refers to a 2018-12-19 compilation date, while the Amd64 is timestamped as 2019-02-27. Does it mean that i386 is no longer supported ?
From the i386 package list :
Depends: libc6 (>= 2.17), libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:4.2), libindi1, libnova-0.16-0, libstdc++6 (>= 6), libusb-1.0-0 (>= 2:1.0.9), zlib1g (>= 1:1.1.4), libindi-data (>= 1.7.6~201812191815~ubuntu18.04.1)
Description: INDI server, drivers and tools
From the Amd64 package list :
Suggests: indi-bin (= 1.7.6~201902271636~ubuntu18.04.1)
Depends: libindi1 (= 1.7.6~201902271636~ubuntu18.04.1)
Description: Instrument-Neutral Device Interface library -- debug symbols
Jasem, I have git- pulled and recompiled, and the 0-byte warning messages have vanished, it seems you've got it. Just great.
File Attachment:File Name: indi_sestosenso_focus_133037.log
File Size: 9 KB
OK, I think you have caught the bug. The SestoSenso firmware sometimes returns some 0-byte position value while it is fast moving. Attached are 2 log files, one with a 100 ms polling period, the other with a more reasonable 500 ms period.
Thanks a lot for your support, Jasem.
File Attachment:File Name: indi_sestosenso_focus_135330.log
File Size: 124 KB
File Attachment:File Name: indi_sestosenso_focus_135814.log
File Size: 10 KB
I did what you suggested, made 2 trials and got 2 debug files. They do not seem to be very informative, despite I entered the 'sync' command from the terminal in order to flush any buffered information.
For security reasons, I do not have an Internet access on my astro set-up. So no vnc or similar software.
File Attachment:File Name: indi_sestosenso_focus_163510.log
File Size: 1 KB
File Attachment:File Name: indi_sestosenso_focus_163854.log
File Size: 1 KB
I have recompiled the whole indi code from git. It contains your latest changes ( 003601f6b1a79a1f20efba273cb090b4eb51806c, f937d764ac4d494ede5f3c1860a23a6689a2d5ed, etc) for the sestosenso.cpp file. But unfortunately these changes do not fix the issue, any press on any preset button makes the driver crash.
I attach a log file that contains 2 successive crashes.
Sorry for the bad news.
File Attachment:File Name: log_15-44-21.txt
File Size: 71 KB
Using the last night build, I see some improvement as the last known focus position is correctly set when I use my Sesto Senso in a brand new Kstars/Ekos session. Which is great, thank you Jasem.
Unfortunately, a new bug has appeared (this is a regression compared to the last stable version I was using until today) : using the Indi Client board I have defined some preset values for that focuser. When I press the Goto button for one preset value, the Sesto Senso actually moves to that value, but that makes also the indi_sestosenso_focus driver crash. It is 100% reproducible. I attach the log file that shows the issue that is around these lines:
[2019-02-21T16:10:49.482 UTC INFO ][ org.kde.kstars.indi] - Sesto Senso : "[INFO] Device configuration applied. "
[2019-02-21T16:10:58.911 UTC INFO ][ org.kde.kstars.indi] - Sesto Senso : "[INFO] Moving to Preset 1 with position 0. "
[2019-02-21T16:11:00.113 UTC DEBG ][ org.kde.kstars.indi] - INDI Server: "2019-02-21T16:11:00: Driver indi_sestosenso_focus: terminate called after throwing an instance of 'std::invalid_argument'"
[2019-02-21T16:11:00.113 UTC DEBG ][ org.kde.kstars.indi] - INDI Server: "2019-02-21T16:11:00: Driver indi_sestosenso_focus: what(): stoi"
[2019-02-21T16:11:00.114 UTC DEBG ][ org.kde.kstars.indi] - INDI Server: ""
[2019-02-21T16:11:00.310 UTC DEBG ][ org.kde.kstars.indi] - INDI Server: "Child process 6843 died"
[2019-02-21T16:11:00.310 UTC DEBG ][ org.kde.kstars.indi] - INDI Server: "2019-02-21T16:11:00: Driver indi_sestosenso_focus: stderr EOF"
[2019-02-21T16:11:00.310 UTC DEBG ][ org.kde.kstars.indi] - INDI Server: "2019-02-21T16:11:00: Driver indi_sestosenso_focus: restart #1"
File Attachment:File Name: log_16-10-41.txt
File Size: 29 KB
With my SestoSenso, I am facing the exact same issue as NH, despite I upgraded the firmware to version (2.1).
The workaround described by wjdrijfhout does not work for me. If I sync/offset the absolute value to, say, 30000 (estimation of the actual position), and then request a move to 0 (inwards, so), the focuser goes _outwards_ by 30000 ticks. And this increases the whole confusion. The only solution is to go through the init process using the Windows-only PrimaLuce software. So there may be another issue with the sync process, maybe. To be confirmed by some other people, if possible.