Hello,

Last night was a beautiful clear sky where I live. Last night was like every other past night, with EKOS going nuts. In my previous post eight back, my first log of EKOS and INDI dancing contains a big error. My logs last night show the same problem. I won’t repeat the same issue.

Look at the time stamp between EKOS said the time was 11/24/2019 and INDI CCD said the time is 4/11/2019. That is a big time delta.

KSTARS showed the correct time on 11/24/2019. This makes INDI CCD drivers out of sync with every KSTARS/EKOS application. KSTARS/EKOS get their time from the system. That is a configuration page option confirmed enabled.

Everything works perfectly inside and tethered to the interior. When the device is unplugged from the internet, it thinks it is 4/11/2019. Chrony is installed and configured. Somehow, 4/11/2019 is hardwired into my INDI CCD drivers configurations. Where?

I manually installed INDI lib 1.8.1. That was before I enabled the INDI nightly builds. When I compiled, I certainly used the instructions provided. I will look at my time stamps to see where 4/11/2019 is showing up. For a while, KSTARS/EKOS and INDI thought 4/11/2019 was a very good date when not tethered. Isolated from the network yields 4/11/2019. Getting GPSD working solved The 4/11/2019 issue.

What is odd, INDI has GPSD giving EQMOD time and GPS coordinates when not tethered. The INDI CCD drivers think it is 4/11/2019. I include the option in DEBUG to log to a file and all of the files are in the 4/11/2019 folder for all CCD drivers. EQMOD logs are placed in the current date folder.

To Recap

My configuration is now very solid power, space, and cable management. All devices get power and are confirmed operational independently from INDI.

Under INDI and not connected to the internet, INDI CCD drivers think the date is 4/11/2019. Under INDI, captures and videos don’t work. Outside of INDI and when tethered, devices work as designed.

Hello,

I found the issue. In EKOS and unplugged, Object & Sequence Selection has two condition dates not activated.

Job Startup Conditions On = 11/04 11:38.
Repeat until = 11/04 11:38

Ok. The source is found. Why is this date and time so fixed when unplugged?

Again, both selections are not selected. ASAP and Sequence Completion are selected. Why is this date selected when it is not selected? This is my quest. I manually adjusted these two options to today. I will see if this relieves the EKOS and INDI CCD issue. Invalid start and end times can hose up time based calculations.

You probably found the root cause of many problems you reported so far.
Raspberry Pi does not have real time clock (RTC) built-in, so it gets the current time from the Internet. It does not matter if you use default timedate service, chrony or even ntp. All of them get the time from the Internet. To make time synchronization quicker Raspberry Pi uses so called "fake hardware clock", which saves last synced time and date to a flat file /etc/fake-hwclock.data. The binary that handles this is /sbin/fake-hwclock and system service is /etc/init.d/fake-hwclock
You just can't expect Raspberry to boot with proper time if you don't have Internet connection. By design it is not possible. UNLESS you use RTC module or GPS connected to Raspberry.

Hello,

Thank you. I did mention I have a GPS device in my equipment list. I did describe that EQMOD does get Location and Time from GPSD. From this reply, EQMOD is the single INDI applet using GPSD.

I can make sure to check and set these two options before conducting any EKOS operation. GPSD is working and supplying EQMOD position and time. KSTARS get its time and location from GPSD.

It is CCD drivers that seem to be out of sync with GPSD. CCD looks at an esoteric non selected option date to conduct all logging, console and file. This impacts PolarAlign and Tracking.

Is your system time correct? Type date in a console and check.

@AradoSKYindi if so, your CCD is probably not getting the time from your mount. Are you sure you configured your CCD driver correctly? Go to INDI panel, CCD driver tab, Options tab - what is your "snoop device" for telescope?

Hello,

Thank you for the suggestion. I am in KSTARS and in each CCD Option Snoop device list are

1. Telescope = EQMOUNT
2. Rotator = Rotator Simulator
3. Focuser = Focuser Simulator
4. Filer = Filter Simulator
5. Sky Quality = SQM

I do not see and option for three CCD snooping devices. It would seem to me that all devices in the EKOS grouping should be linked to the Mount. If the Mount has Time and Date, all identities in the EKOS group show get their needs from the Mount.

Under Telescope, two buttons say Primary / Guide. I have set all CCD in the mix as Primary. I think this messes up PHD2 and its INDI camera driver. With everything listed as Telescope, PHD2 presents the null list and provides the stock drive for the ZWO. The QHYCCD devices are excluded.

Hello,

I am testing today while it is partly cloudy and sun. I did several changes and then unplug the internet. The GPSD still functions and automatically updates the Date and Time for the EKOS system. Under each CCD, I selected Save to File and saved. The location is now linked to today. I noticed the Object and Sequence Selection tab of EKOS is keeping tabs with the DATE and TIME of the Mount. Maybe the XML file was corrupted. I manually changed the Job Startup Selections and Job Completed selections to be current from April 11, 2019. Both time options are not selected.

Hello,

This makes two out of two times I have attempted to see the QHY products to work under EKOS and Polar Alignment. I attempted additional try events and all ended in failure of the QHYCCD drivers, PoleMaster and QHY5LII-C. Here is my equipment list.

2019-12-26T09:14:59 Guider port from QHY CCD QHY5LII-C-61f7e is ready.
2019-12-26T09:14:58 QHY CCD QHY5LII-C-61f7e is online.
2019-12-26T09:14:58 Guider port from QHY CCD POLEMASTER-00d7 is ready.
2019-12-26T09:14:57 QHY CCD POLEMASTER-00d7 is online.
2019-12-26T09:14:57 Guider port from ZWO CCD ASI120MM Mini is ready.
2019-12-26T09:14:56 ZWO CCD ASI120MM Mini is online.
2019-12-26T09:14:56 EQMod Mount is online.
2019-12-26T09:14:55 Guider port from EQMod Mount is ready.
2019-12-26T09:14:55 EQMod Mount is online.
2019-12-26T09:14:54 EQMod Mount is online.
2019-12-26T09:14:54 Joystick is disconnected.
2019-12-26T09:14:52 INDI services started on port 7624.

INDI says everything is ready. Here are my findings about GetQHYCCDSingleFrame error (-1). Apparently, this error message is about the device is not ready. Not Ready for What? DEBUG is silent. The PolarAlign and the QHY5 driver working is more a random act than a function of hardware startup time.

I have a ZWO ASI 120M. This device is plug-n-play. The ZWO does not have any problems. I select the driver and I get an immediate image. Solver immediately tries to solve my ceiling.

When a random event happens, both QHY devices operate and Solver works. I have a HEX file from QHYCCD dated from 2017. It appears to be the last gasp of support from QHYCCD. I also see the history here on this site of GetQHYCCDSingleFrame error (-1). This seems to be a reoccurring problem with QHYCCD over the life of INDI.

Hardware wise, the QHYL5II-C has an indicator light. When the light is lit, the device is supposed to be operational. When the light goes out, it is offline. Restarting the QHY5LII-C, gives this error.

2019-12-26T14:22:40: [ERROR] Connecting to camera failed (QHY5LII-C-61f7ec105d7c2144).

This says that the driver is putting the devices into a funky state of hardware offline. I have to do a hardware reset to get it back.

OACAPTURE is independent app from INDI. PoleMaster_QT is another independent APP. Both apps see the QHYCCD devices. OACapture sees the ZWO and QHY5LII while PoleMaster sees the Polemaster.

Now for the logs... This is my current test session. EKOS is section 1. The QHYCCD driver, PoleMaster is next.

The Time Delta between EKOS and the Driver is: EKOS is in real time, the Driver is +5 hours ahead. My Three CCD drivers all are +5 hours ahead of GPS/System Time. Since the ZWO does not have problems working, the issue is with the QHYCCD driver. The QHYCCD problem is independent of the clock.

Hello,

Thank you Knro. The CCD time is UTC time. EQMOUNT is Time Zone based. Normalizing logs are easy. Better to ask than to assume.

Thanks for the suggestion. You are right.

BTW problem is solved now

Thanks 9apps cartoon hd

Hello,

In another thread, the QHY driver issue has been resolved. Please update KSTARS. It has fixes in EKOS to prevent the same non-Mount driver, (auxiliary devices), from being loaded twice or more. USB is asynchronous communication. Reducing drivers to one instance resolved the QHYCCD issues. In EKOS profiles, all devices to be included are to be unique vendor instances. The vendor driver is supposed to manage all vendor devices under the INDI.

Technically, TCPIP is a different protocol. Under TCPIP, multiple drivers would be possible. Fortunately, the RPI has 1 RJ45 connector.