Hans's profile

dmsummers gave good advice already. I want to add a bit on the named devices as you mentioned ttyUSB0 and ttyUSB1. When you have disconnect/reconnect problems the old entry that was made for the device may not be gone yet, and then you get a new one with a higher number. This is annoying as you have configged INDI to look for ttyUSB0, but now the device new name may be ttyUSB1 and ttyUSB0 is unresponsive. The fix for this in Linux is to set up rules to name your devices yourself. Once done this makes the INDI configuration a lot easier too. For instance I use in /dev :

lrwxrwxrwx   1 root root           7 feb 15 13:26 integra_focusing_rotator0 -> ttyACM0
lrwxrwxrwx   1 root root          15 feb 15 13:26 integra_focusing_rotator3 -> bus/usb/002/018
lrwxrwxrwx   1 root root           7 jan 11 23:29 sx-ao-lf -> ttyUSB0
lrwxrwxrwx   1 root root          15 jan 11 23:29 sx_lodestar -> bus/usb/002/003
lrwxrwxrwx   1 root root           7 mrt 21 22:03 ZWO_ASI1600MM-Cool -> ttyACM0
lrwxrwxrwx   1 root root          15 mrt 21 22:03 ZWO_EFW -> bus/usb/002/017

You can use 'tail -F /var/log/syslog' to see what happens when you plug in a USB device. And tools like udevadm to search for identifiers, for instance for my sx-ao-lf serial to USB adapter it lists :

sudo udevadm info -a -n /dev/ttyUSB0 | egrep 'SUBSYSTEMS|DRIVERS|ATTRS{idVendor}|ATTRS{idProduct}|ATTRS{serial}|ATTRS{manufacturer}'
    ATTRS{idProduct}=="6001"
    ATTRS{idVendor}=="0403"
    ATTRS{manufacturer}=="FTDI"
    ATTRS{serial}=="FTFE88G0"

I maintain the naming in /lib/udev/rules.d/99-observatory.rules :

# SX-AO
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTFE88G0", MODE="0666", SYMLINK+="sx-ao-lf"

# Meade/arduino focuser
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="AL01C9TL", MODE="0666", SYMLINK+="moonlite_focus"

# ZWO camera
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="6572", MODE="0666", SYMLINK+="ZWO_ASI1600MM-Cool"

# ZWO filterwheel
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03c3", ATTRS{idProduct}=="1f01", MODE="0666", SYMLINK+="ZWO_EFW"

# Gemini Telescope Design Integra85 Focusing Rotator
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0043", MODE="0666", SYMLINK+="integra_focusing_rotator%n", ENV{ID_MM_DEVICE_IGNORE}="1"

# SX lodestar
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1278", ATTRS{idProduct}=="0507", MODE="0666", SYMLINK+="sx_lodestar"

Those rules get activated on boot, or manually with 'udevadm control --reload-rules'.

Now I chose to maintain these rules by myself. There may be other / better ways to do this. I hope others can fill in that.

-- Hans

Read More...

The VM is stopped because of a too large taxing on bandwidth for Jasem, and that the astro equipment device drivers did not always work nice in a VM. See www.indilib.org/forum/ekos/3295-ekos-vm.html#25151
You can download EKOS for various operating systems natively now at indilib.org/download.html but for fi. WIndows that does not include the device drivers. For that you still need a remote Linux computer with them (regular PC or something like a RPI).

Read More...

Hi mpfjr,

Do I understand right that you're trying to use the generic EKOS mount modeling system for a 10micron mount ?

As I see it the EKOS mount modeling system is a generic system that augments the pointing of a mount. Any mount.
A 10micron mount however has a built-in modeling system, far superior to what EKOS has (because fi. it uses the absolute encoders to model things like sag and mirror flop and also corrects for air pressure and air temperature).
The EKOS mount modeling system currently does not program that 10micron internal modeling system.

That said the EKOS mount modeling system should of course work. But I do not recommend to use it on a 10micron mount, I recommend to use its superior internal modeling system.
If you want to continue with the EKOS mount modeling system I have to defer to others here on this forum. I hope they can help you further.

If you want to program the 10micron internal modeling system then you have several options of which 2 work on Linux today (that I know of) : Either use the 'Alignment' tab in the 10micron INDI device driver by manually adding plate solved coordinate results. I have used this to make a model myself once. Or get MountWizzard version3 or later to automate the whole thing. I now only use MountWizzard together with a local installation of astrometry.net and the astrometry-api-lite interface to it that offers the same interface as nova.astrometry.net . Sadly MountWizzard v3 is not released yet publicly, and the repo still only has 2.x branches. The good news is that the MountWizzard author is working on a new version.

Here's a screenshot of a recent model I made with it :

-- Hans

Read More...

(gdb) up 3
#3 0x0000564d1dfde790 in Ekos::Capture::processPreCaptureCalibrationStage (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:5562
warning: Source file is more recent than executable.
5562 void Capture::toggleVideo(bool enabled)
(gdb) list
5557 }
5558 }
5559 }
5560 #endif
5561
5562 void Capture::toggleVideo(bool enabled)
5563 {
5564 if (currentCCD == nullptr)
5565 return;
5566

(gdb) up 1
#4 0x0000564d1dfde8cd in Ekos::Capture::updatePreCaptureCalibrationStatus (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:2988
2988 abortedJob = job;
(gdb) list
2983 SequenceJob * abortedJob = nullptr;
2984 for(SequenceJob * job : jobs)
2985 {
2986 if (job->getStatus() == SequenceJob::JOB_ABORTED)
2987 {
2988 abortedJob = job;
2989 break;
2990 }
2991 }
2992

No idea why abortedJob triggered yet.

Read More...

kstars-bleeding 6:3.3.4+201908080145~ubuntu18.04.1

After capturing 6 frames kstars/ekos segfaulted with :

(gdb) bt
#0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f32a64257f9 in KCrash::defaultCrashHandler(int) () from /usr/lib/x86_64-linux-gnu/libKF5Crash.so.5
#2 <signal handler called>
#3 0x0000564d1dfde790 in Ekos::Capture::processPreCaptureCalibrationStage (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:5562
#4 0x0000564d1dfde8cd in Ekos::Capture::updatePreCaptureCalibrationStatus (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:2988
#5 0x00007f32a0c4d0d4 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6 0x00007f32a0c410db in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7 0x00007f32a209682c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8 0x00007f32a209e0f4 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9 0x00007f32a0c119a8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007f32a0c69d8e in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007f32a0c6a589 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x00007f329c151417 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007f329c151650 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007f329c1516dc in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007f32a0c6a8ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007f32a0c0f9ea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007f32a0c18a84 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x0000564d1dc99c92 in main (argc=<optimized out>, argv=<optimized out>) at ./kstars/main.cpp:331

The logfile has :

[2019-08-25T00:08:57.697 CEST INFO ][ org.kde.kstars.ekos.focus] - "Autofocus complete after 9 iterations."
[2019-08-25T00:08:57.699 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 7000" startup 2 "24/08/19 22:54" state 3
[2019-08-25T00:08:57.699 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-08-25T00:08:57.705 CEST INFO ][ org.kde.kstars.ekos.capture] - "Ekos will refocus in 3600 seconds."
[2019-08-25T00:08:57.706 CEST INFO ][ org.kde.kstars.ekos.capture] - "Focus complete."
[2019-08-25T00:08:57.707 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Focus State "Complete"
[2019-08-25T00:08:57.725 CEST INFO ][ org.kde.kstars.ekos.guide] - "PHD2: Guiding Resumed."
[2019-08-25T00:08:57.726 CEST INFO ][ org.kde.kstars.ekos.guide] - "Guiding resumed."
[2019-08-25T00:08:57.727 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Guiding"
[2019-08-25T00:08:57.727 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Calibration & Guide stage...
[2019-08-25T00:08:57.727 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'NGC 7000' guiding is in progress."
[2019-08-25T00:08:57.728 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Get next action...
[2019-08-25T00:08:57.729 CEST INFO ][ org.kde.kstars.ekos.capture] - "Meridian flip configuration has been shifted to the mount module. Please configure the meridian flip there."
[2019-08-25T00:08:57.730 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'NGC 7000' capture is in progress..."
[2019-08-25T00:08:58.353 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 7000" startup 2 "24/08/19 22:54" state 3
[2019-08-25T00:08:58.353 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-08-25T00:12:00.858 CEST WARN ][ default] - QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
[2019-08-25T00:12:00.858 CEST WARN ][ default] - QSocketNotifier: Invalid socket 16 and type 'Read', disabling...
[2019-08-25T00:12:00.858 CEST WARN ][ default] - QSocketNotifier: Invalid socket 10 and type 'Read', disabling...

The console :

The konsole shows not much help either
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kstars path = /usr/bin pid = 8677
KCrash: Arguments: /usr/bin/kstars
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from kdeinit
sock_file=/run/user/523/kdeinit5__0
[1]+ Stopped kstars
~/ $?=147 INDI server localhost/7624 disconnected.
INDI server localhost/7624 disconnected.
Unable to start Dr. Konqi
Re-raising signal for core dump handling.5

Read More...

sterne-jaeger wrote: github.com/sterne-jaeger/kstars/tree/ekos_observatory

Awesome. Do you generate kstars/ekos/observatory/observatory.ui with some tool ? and if so how does that work ?

Read More...

sterne-jaeger wrote: ... I started testwise to develop a dedicated tab for the observatory.

Hey that's great that you started this ! Please tell me this lives in a branch in github somewhere

(we can arc it to phabricator later

)

We need to add things like which dome/roof driver is in use, make a distinction between roll-off roof and dome with shutter, which safety system is in use and what its status is (I see weather is already there), enable or disable closing on bad weather, we need a flexible close order (like dome park first, then close cap, then close shutter). And a hysteresis setting, like if we closed down and things are safe again wait with opening for X time. Retries, how many ? Logic like if dome park fails do we still want to try to close the shutter or not ? Maybe even pre and post scripts or curl calls per action. And a wake-human alerting system, which may be just another script to be called so to defer the actual implementation to the user. Do we need to support multiple mounts in an observatory here too ?

-- Hans

Read More...

With EKOS 3.2.2 closing up the observatory again on bad weather (live tested and verified last night, yay !) I'll adapt sentinel to handle the that the mount may already be parked etc. so that sentinel turns into a second defense line, an independent safety mechanism.
-- Hans

Read More...

Hi Ferrante,

fenriques wrote: I'm adapting the script to my setup, 2 out of 4 of my devices work:
1) Roof is ok. Only updating the property was needed:
<code>INDI_DOME_PARK_PROPERTY = 'Talon6.DOME_PARK.PARK'</code>
2) Weather is ok. Just used '_PARAMETERS' instead of '_STATION_INDEXES' :
<code>WEATHER_WATCHER_PARAMETERS = {'WEATHER_RAIN_HOUR', 'WEATHER_TEMPERATURE', 'WEATHER_WIND_SPEED'}</code>
And changed the variable names accordingly in the script.

Great !

3) Mount. I'm using 'LX200 10Micron' drivers. There's no PARK property there. Are you using the same driver?

I would hope so, I get this :

indi_getprop | sort -u | grep 10micron | grep PARK
10micron.DOME_POLICY.LOCK_PARKING=Off
10micron.TELESCOPE_PARK.PARK=On
10micron.TELESCOPE_PARK.UNPARK=Off

What do you get ? Is your scope parked when you try this ? Or has the scope been parked with this instance of the INDI driver once ?

4) Camera. The property 'ZWO CCD ASI071MC Pro.CCD_COOLER.COOLER_ON' is not listed using getprop with ASI071. Anyway when I execute the script it returns true but the cooler is still On. The only other property related to cooler is 'ZWO CCD ASI071MC Pro.CCD_COOLER_POWER.CCD_COOLER_VALUE' but doesn't change the cooler power neither.

In the ZWO asi_ccd.cpp code we have

bool ASICCD::initProperties()
{
    INDI::CCD::initProperties();

    IUFillSwitch(&CoolerS[0], "COOLER_ON", "ON", ISS_OFF);
    IUFillSwitch(&CoolerS[1], "COOLER_OFF", "OFF", ISS_ON);
    IUFillSwitchVector(&CoolerSP, CoolerS, 2, getDeviceName(), "CCD_COOLER", "Cooler", MAIN_CONTROL_TAB, IP_WO,
                       ISR_1OFMANY, 0, IPS_IDLE);

    IUFillNumber(&CoolerN[0], "CCD_COOLER_VALUE", "Cooling Power (%)", "%+06.2f", 0., 1., .2, 0.0);
    IUFillNumberVector(&CoolerNP, CoolerN, 1, getDeviceName(), "CCD_COOLER_POWER", "Cooling Power", MAIN_CONTROL_TAB,
                       IP_RO, 60, IPS_IDLE);

As you can see there the CCD_COOLER parameter is IP_WO, a write-only parameter. You get to see these with indi_getprop when you add -w

indi_getprop -w | sort -u | grep CCD_COOLER
ZWO CCD ASI1600MM-Cool.CCD_COOLER.COOLER_OFF=On
ZWO CCD ASI1600MM-Cool.CCD_COOLER.COOLER_ON=Off
ZWO CCD ASI1600MM-Cool.CCD_COOLER_POWER.CCD_COOLER_VALUE=0

And writing to CCD_COOLER_POWER is indeed not allowed as it's IP_RO , Read Only.
But writing to CCD_COOLER.COOLER_ON should work still. If it does not then that is a ZWO ASI and/or INDI driver bug. You can file a bug for that

5) Cap. Didn't test the cap.

Neither can I, I don't have a cap (yet).

-- Hans

Read More...