Hello,

Thank you for your reply. I sought and found two types. One is from Astrometry. The other is Stellermate. The files for Stellermate are Deb packages.

Hello,

Now, that I have found at least two Astrometry resources I can talk about an issue from last night. I have been fortunate to be receiving three straight clear nights to work under AstroBerry.

This is my setup. My OTA is an Orion 6” RC tied to an motorized Vixen GP mount. For visual guiding and alignment, I use a ZWO 120mm and a QHY PoleMaster. For mount controls, I use EQMod to run the AstroEQ. The tripod is a Vixen SGX mount with an 8” extension.

QHC PoleMaster software works under AstroBerry. The alignment is spot on. My reticle agrees with the celestial pole placement. My first object near my view is M31. Using mount control, I search, find, and GOTO to empty space.

I use GPSD with a DIY Mall device. KStars and Echos knows where the mount is located, elevation, and time.

The mount starts parked at the celestial pole. Why did I go to empty space and not M31? I tried EKOS and Astrometry three times.

My first time was using the ZWO. The image captured is grainy and out of focus. Bummer, I am supposed to use QHY. I stop the process and use the QHY. I begin the process again. The ZWO image is up. Why?

I wait 9 minutes for Astrometry to load image 1. With the Astrometry Imaged captured, Solver begins and ends with Solver timed out. Capturing begins again. With the ZWO image, no wonder, I thought. I have ZWO in a ZWO 60mm x 280 on top of my OTA. It needs to be focused first.

On the second attempt, the QHY image is shown. It is a beautiful image of Polaris. This should be easy. PoleMaster has done the heavy lifting. After three more sessions of this repeatable failure, I am now looking for solutions.

The missing Astrometry files were downloaded from Astrometry and copied into the appropriate folder under sudo. These are big files. They take a long time to load and the PI memory is on a budget. I am puzzled why it thinks it needs gargantuan solver files. The QHY can capture 1920 x 1280 images by default.

The PoleMaster software is not having problems. I need to check my logs to see if GPSD failed to see the device. Being in a different time slot can produce empty space.

The ZWO is a USB 3.0 device. My QHY5LII is under repair. The Raspberry PI 3 B+ is 2.0. ZWO’s grainy picture is USB 3.0 compatibility need given by USB 2.0. Not good.

In EKOS, I used 180’ x 180’ as my FOV. I live in the country on a ridge. Very few objects are in my way. Given my setup, I should not be pulling from 2’ x 3.8’ or the next arc second level above the smallest. Somehow, my setup is being honored.

I am left with two problems to solve.

GPSD and rules are tricky items to resolve. The USB Port assignment process is consistently different. It auto increments the assignment. I use a USB 7 port powered hub to support the 5 USB devices. What port did USB assign GPSD? I know rules can be conditionally automated. I will research getting USB to behave.

The other item is the Solver Timeout issue. EKOS, Astrometry, and Pi are not working together. The Solver shutdown is nearly instantaneous. The gap in the timeline is not precision enough to show a delta. This says out of memory to me. Loading a 400mb file to search is nothing trivial. Why such large files when I picked a large arc second level?

Thank you to the team working on this area of AstroBerry.



I have to start with the AstroEQ as the only device on the Hub. It must have RS232 access ASCM00 or ASCM01. All others are added after booting is complete.

To make sure you USB GPS device always has symbolic name e.g.you can create an udev rule file e.g.with contentNote this rule works with u-blox chips, once the USB GPS dongle is plugged in you should see

So your GPS device name persistently is
Probably it would be a good idea to submit this rule also upstream to GITHUB.

Cheers
Thomas

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.

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.

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.