Hello,

I gave EKOS plenty of opportunity to set FOV. It was blank. The field can be overwritten. I picked a larger size. The large size should yield a smaller fill to load. Thank you for the link. I used the calculator to estimate 89’ x 70. This is nearly a two times smaller FOV.

I am puzzled why it was pulling from 2’ x 3.8’ level. Loading >. 99 mb into the PI is long. The size is between 100mb and 450mb per zone.

Set the calculated FOV and you will be fine. Otherwise astrometry does blind solving. This takes lots of time

The unsolved FOV that is calculated, the one you see if you mouse over the box of it only shows 0' X 0', uses the information entered on the mount tab. If that information is wrong, edits to it will not take effect until you use the save telescope information button. Doing so will update the calculated FOV. And a successful solve will automatically update it to the true value.

Hello,

Another clear night and I used PoleMaster and attempted Astrometry. I allow EKOS to determine the FOV, 88.4 x 70. This is same as the suggested site. Fantastic. After 6 passes of Solver failed, I quit using EKOS and Astrometry. The first image was never resolved.

I was looking at my configuration. GPSD was working. My Observation site was not configured for the session. My prefigured home site was selected. I then noticed the Clock time. My clock time said 1:30 PM. I my watch said 10:30 PM. Ok. Time mismatch issue. I corrected the time and retried.

I opened EKOS. A conflict occurred between PoleMaster and Indi Lib for QHY driver. I reset the USB and the PoleMaster was operational. I attempted EKOS Astrometry again after I realigned with PoleMaster. 6 attempts again with first image and no resolution. By this time, it was late. I packed it up.

I also discovered my RA motor was slipping.. The image returned was a beautiful shot of Polaris. Each failure was after 3 minutes exactly. Apparently, EKOS logging did not capture the Astrometry session. I am not done yet. I want this to work. Somehow, Astrometry is not seeing the image correctly. Or a parameter is not correctly set. All bands of FOV are installed. Getting the correct file is much faster with the calculated FOV.

Also, my GPSD is working very well. I keep wondering why, I have to set LOCALE and set system time when I move to use the device at night and isolated from the internet. System time should not drift hours. Ah. PI does not have a CMOS battery,.

Based a valid GPSD working device, Time Zone is based on Longitude and Latitude position. Why doesn't the GPSD play more of a role with Observation site. Based on LAT and LONG, KSTARS should know where it is. I can get tine from the GPS. But, I loose a precious R232 port to KERNEL (PPS and PPS1). EQMOD looks for some GPS to help it know where it is located. Finding the time way off got me questioning the process. Any delta time from local and not knowing where it is can hamper Astrometry.

Having an RA motor issue complicated Astrometry even more. I can solve the RA Motor. I built it. it is mine to fix. Next Clear night, I hope to have 1) the RA fixed and 2) procedures to establish LOCALE and Time upon boot up before trying Astrometry. PoleMaster is not dependent on GPSD and time. A working RA motor is all it needs. My mount is getting more heavy.

GPSD knows your location, but itself can not determine time zone. To do so would require a very large lookup table. Time zone should be set in the system, and within KStars geographic location. Furthermore you need to setup the NTP daemon to use GPS directly as a time source for the system. It not a perfect arrangement however. Because NTP will not sync the time if it is more than 1000 seconds off the system time. To get around this you can install ntpdate. Run it with -h -g.That should tell it to run once (-h) , ignore 1000s limit (-g) and should update the system time to the GPS.
Setting up PPS is not required for any of this.

Also if you are still having issues platesolving, try increasing the exposure time as I have found better performance.

Hi,
I use GPSD and it sets the time zone perfectly as do all my GPS dongles using GPSD...in fact of not heard of one that does not set the time zone...
Or am I missing something...

GPSD reports the time in UTC. How that is converted to local time is handled elsewhere by the system.

Hello,

I do believe a very large table of sites with Long and Lat values are part of KSTARS already. It takes a long time to get to my neck of the woods. I added my specific site (town) to the table. (No, stop lights. The Mayor/Water Master/Town Clerk/Post Master used to be one person.) Dream On. To me, GPSD and the Table would agree with each other. I am in the appropriate Observation site. KSTARS is ready to roll. Dream Off. Now, an observer would have to have the equipment and knowledge to accomplish what I just wrote. Any LONG and LAT from GPSD +/- between known sites would be in Time Zone and Country.

I have another clear night tonight. I have a solution to the RA slipping. I am ready to see if Astrometry and KSTARS can get to M31. It is easy to get to this time of year. It straight east of Polaris in my area. That is before it get too high. M81 is too low.

When I get done moving to Ubuntu Mate 19.04, I will used the NTPDATE -g -h. I also have procedure to set up the observation and time before I get to platesolving. Not knowing where you are and the time does not make for a platesolving or viewing good time. Stars are pretty. Space is big. But seeing Messier objects, Planets, Clusters, Galaxies and other things , that is what a scope is for.

You are evidently aware of the Geographic location, check that it has the correct UT offset and DST rule set. Check that KStars is updated by GPS and add GPSD to your INDI Profile.
Setting up NTP is necessary before you can use ntpdate. It can be difficult if you are not familiar with it.

Things you have to have installed
Lines must be added to /etc/ntp.conf -Here is my example:
You may try adding this to /etc/systemd/timesyncd.conf
/etc/default/gpsd can be configured something like this, But check your device location
You may consider adding this to rc.local to run at startup. It use supposed to start a GPSD client to initiate the service as preparation for NTP.

Hello,

Thank you for the screen shots. I was able to compare my selections. I do not have CCD camera yet. I am casually observing and working kinks out. I confirm that I have selected the same settings for GPS guidance of KSTARS and the use of EKOS equipment management.

I have my RA issues fixed. I have the 19.04 issues fixed. Now for a clear night get Astrometry working. As I stated, Observation GPS Location, is where my site was not selected. Next clear night I will try again. I am under 19.04 now. For a while, Ubuntu-mate was complaining about a partial upgrade. Those problems are now fixed under 19.04.

Are you testing this indoors? If so you may just be having issues getting a fix. You can monitor the gps status with gpsmon or cgps or xgps. Plus from within the indi driver. All things being equal when the indi driver receives a fix everything should update. And UTC offset is actually taken from the operating system's settings.

Hello Ihoujin,

I can and have. I test with a long USB extension and place the device in the window sill. It does get a lock there. I prefer testing outdoors. I like seeing tech working together for a specific goal.