×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Polar Alignment issue with EKOS and Astrometry

  • Posts: 389
  • Thank you received: 15
Hello Thomas,

Thank you for your input. As I stated, I am on a Raspberry PI 3 B+. The location of Rules.d is different on an RPI3B+. Also, exclusive rights the UART is demanded by devices needing RS232.

Instead of using ttyUSB, I used SYMLINK+="ttyS0" for one device and SYMLINK+="ttyS1". This is my workaround. Now, both devices are bound to ttyACM0 and ttyACM1. The next week is going to be rainy. I will not be able to test AstroBerry with this equipment. Both AstroEQ and U-Blox are happy. The other big item is GPSD. Apparently with the GPS device plugged in and not in clear path to a satellite, PPS and PPS1 take over tty ACM0. No matter what is in the Rule file, Kernel takes it over. Once the GPS finds a lock, PPS and PPS1 go away.
Last edit: 4 years 7 months ago by John Robison.
4 years 7 months ago #43012

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375
What do you mean by that? You're supposed to set FOV manually. It is EKOS that calculates exact FOV based on you camera and telescope. I believe that this is the origin of you problems related to plate solving.
Your camera settings will be read from the camera, so no need to configure anything. Your telescope settings (apperture and focal length) need to be set either in EKOS (mount tab) or INDI panel (options in mount tab).
After you set it up correctly take a look at FOV displayed in the EKOS Align tab (the one you use for plate solving). Verify the value using FOV calculator e.g. astronomy.tools/calculators/field_of_view/
If the values differ significantly you're not configuring your setup correctly.
4 years 7 months ago #43025

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
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.
4 years 7 months ago #43043

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375
Set the calculated FOV and you will be fine. Otherwise astrometry does blind solving. This takes lots of time
4 years 7 months ago #43045

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
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.
The following user(s) said Thank You: Craig
4 years 7 months ago #43080

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
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.
4 years 7 months ago #43155

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
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.
sudo ntpdate -g -h
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.
4 years 7 months ago #43158

Please Log in or Create an account to join the conversation.

  • Posts: 1067
  • Thank you received: 140
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...
4 years 7 months ago #43159

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
GPSD reports the time in UTC. How that is converted to local time is handled elsewhere by the system.
4 years 7 months ago #43160

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
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.
4 years 7 months ago #43162

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
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
sudo apt-get install gpsd gpsd-clients ntp ntpdate python-gi-cairo

Lines must be added to /etc/ntp.conf -Here is my example:
# Kernel-mode PPS ref-clock for the precise seconds
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS stratum 0
 
# Server from shared memory provided by gpsd
server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 refid NMEA stratum 3 time 1 0.000

You may try adding this to /etc/systemd/timesyncd.conf
[Time]
NTP=127.127.28.0

/etc/default/gpsd can be configured something like this, But check your device location
# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/ttyS0 /dev/pps0"
GPSD_SOCKET="/var/run/gpsd.sock"
 
# Other options you want to pass to gpsd
GPSD_OPTIONS="-D 5 -n"

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.
# Connect gpsd for one NMEA sync.
gpspipe -r -n 2 &

Last edit: 3 years 4 months ago by Andrew.
4 years 7 months ago #43163
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
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.
4 years 7 months ago #43210

Please Log in or Create an account to join the conversation.

Moderators: Radek Kaczorek
Time to create page: 1.061 seconds