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.
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.
For certain, Moving to 19.04 was a good choice. The boot time is significant more faster. I will be interested to see the number of apps migrating to be 19.04 compliant.
I am happy to report; conflict has been resolved. I had to normalize INTERFACAES, HOSTPAD.CONF, DNSMASQ.CONF and DHCPCP.CONF,
auto lo vap0 wlan0 MyNIC
iface lo inet loopback
iface vap0 inet static
iface vap0 inet dhcp
iface wlan0 inet manual
iface MyNIC inet manual
Apparently, vap0 and wlan0 are in conflict with DHCP.CD. Ok. When upgrading from 18.04 to 19.04, the config files pushed contained wlan0 as the recipient of DHCPCD benefits. This overwrote the vap0 settings. I dutifully replace wlan0 with vap0 to get back to normal. Sysl;og says that isn't working.
Sep 11 11:10:00 astroberry dhcpcd: vap0: IAID eb:62:37:f8
Sep 11 11:10:00 astroberry dhcpcd: vap0: IAID conflicts with one assigned to wlan0
Sep 11 11:10:00 astroberry dhcpcd: vap0: adding address fe80::7227:4587:bb11:12c3
File structures for IPV4 and IPV6 are listed as owned by wlan0. Just removing them in a conf file does nothing to clean up the file system, Time for the wrecking ball.
Rest and fresh review reveals the culprit. The network for VAP is not defined. I tried to use bridge to bridge between vap0 and wlan0 explicitly. Under 16.04 and 18.04, no bridge was required. A bridge requires iptables. Here is my ifconfig output. The virtual network, vap0 , does not have a network defined. Hence, when I connect, I get the universal subnet mask of 255.255.0.0 as generated by "no, you didn't get an IP from your provider. The virtual IP wlan0 is dependent on receiving help from something. Time to build a bridge.
vap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.149.232 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::7227:4587:bb11:12c3 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:62:37:f8 txqueuelen 1000 (Ethernet)
RX packets 2249 bytes 682949 (682.9 KB)
RX errors 0 dropped 4 overruns 0 frame 0
TX packets 681 bytes 226004 (226.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:62:37:f8 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I bit on the move to 19.04. Now, Astroberry WAP does not give an IP address anymore. I know I ensured no config file was altered . Any conf file is in order. Apparently something has changed that now does not allow DHCP to be shared with WLAN.
DHCPCD.CONF looks fine.
WPA_SUPPLICANT.CONF looks fine.
Connect to Astroberry WAP and receive no DHCP. Hmm...
To me, I see too many WLAN0 config options. SSID = astroberryPI is listed as a configuration but nothing show up there. What a challenge. 19.04 is too new.
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.
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.
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.
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+="ttyS2" for one device and SYMLINK+="ttyS1". This is my workaround. Now, both devices are bound to ttyACM1 and ttyACM2. 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.
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.
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.
Success! At least CMAKE isn’t complaining about missing pieces.
My steps in getting 1.8 update onto a Raspberry PI and AstroBerry as as follows.
1. Get Synaptic - this will allow you to search for missing components
2. Get CMAKE - CMAKE is not part of AstroBerry.
3. With Synaptic, search for the Debug armf installs for the following
3f. Any other missing variables
At least two optional components are not armf compatible.
Now, to see if these updates help with some of the equipment.