Hello,

Happy 4th of July to US users. Last night was low humidity as compared to what is coming.

I ran into some unforeseen conflicts. I live in the US. My scope said it was in Warsaw. I checked GPSD. The service was running but dead as door handle. Ok. I have defined my geographic location. KSTARS shifted to the correct location.

I checked the status of GSPD and I saw red letters everywhere. The file /temp/vgps was read only and no permissions. Ouch.

After investigating, I found AstroPI3 components were locking onto the temp files GPSD needed. Plus, GPSPANEL changes the HFS rights to ROOT.

I would change them back. Restart GPSD. The rights would be changed. I like AstroPI3. But, the tools don’t allow GPSD to function. Thus, GPSPANEL does not talk to GPSD. I will shutdown indiwebmanagerapp as a service. It is locking the vgps file.

The second discovery was with NTP and GPSD. I added an RTC to AstroBerry. This solved the Time and Date link with EKOS. GPSD gives error messages about GLL time until after ZDA or RMC has supplied a year. Bugs.Debian.Org said in 2007, this is a bug in GPSD and GPS_Clients. That was a long time ago.

I wonder if this is a conflict between GPSD and NTPD with the RTC. More research is required.

Nope. Not possible. NTPD is not part of AstroBerry 2.0.3. I see this issue now as a GPSD and RTC conflict. I resolve some of the conflict by running

Dpkg-reconfigure initscripts

I ran this on my RPI3B+. After the July 3 issue, I found my RPI4B in a failed state. It doesn’t boot. It hangs on starting services. Under Windows, the card shows BOOT. Under Astroberry, I get BOOT and ROOTFS. The BOOT folder is fine on BOOT but empty on ROOTFS. This looks like a dirty shutdown. I am wondering about the stability of the media.

I had trouble using a SANDISK micro SD. I attributed this trouble to an incomplete download of the package. The file and image were incomplete. The behavior is the same. It acts like it cannot see the rest of the volume to complete booting. The two shares with using the RPI3B+ to analyze is interesting. Could this be the reason? BOOT contains BOOT.

Hello,

I am back to a working AstroBerry 2.0.3 after some sleuthing. I have the RTC and GPSD working together. I have the RPI4B booting properly. What a relief.

The issue is twofold. The raspi-config tool has a bug. When dealing options, options should be singular. If an option is available, it should be highlighted in raspi-config. This tool edits config.txt. Apparently, it just appends.

The boot hang was caused by me with the raspi-config tool. I wanted RTC to work for EQMOUNT to accept system time. Apparently, GPSD time works with INDI as Raspbian doesn’t have NTPD. If Raspbian did, RTC is not needed.

Ok, I added a DC3212 device to my RPI3B+ and RPI4B. I went through the offered steps to get Raspbian to recognize the i2c device by enabling it in raspi-config. Hwclock was not recognizing any RTC device to work with. Well, I rechecked my instructions and check raspi-config. It was not enabled. I enabled i2c again.

After July 3 session and RTC “working”, my RPI4B stopped booting. It would hang at the Raspberry splash screen loading services. I thought I had a corrupted boot or ROOTFS drives from a dirty shutdown. I thought I shut it down by selection and power off. But, no boot.

I then looked at my changes after confirming the file structure of BOOT (FAT32) and ROOTFS (exfs4). I looked at cmdline.txt and config.txt. I noticed two identical settings, i2c_armf=on. I removed one.

I rebooted and the RPI4B was back in business. My next problem was GPSD. I ran the initscripts on the RPI4B. I noticed GPSD was working after I rebooted. I made sure any and all INDI web and GPS pieces were dependent on an operating GPSD.service. This cleared up the mad grab of /temp/vgps between VirtualGPS, GPSPANEL, and GPSD. I made the offending INDI service to wait for GPSD.service. GPSD is now happy to have use of the shared resource/temp/vgps.

These issues are closed for now.

Hello,

When connected to the internet, GPSD and RTC work together. This is because RTC gets time from the internet. GPSD provided time is looking for a UTC compliant time. HWCLOCK does not appear to set the UTC time. Out in the field, GPSD runs but doesn’t see the GPS unit. I have to issue this date command.

date -u -s (UTC date and time = current time +/- UTC delta)

This has to be +/- UTC delta to current time. Once set, GPSD operates as running with no messages. But, I forced it to using “-=“ in the service. This was to see other problems before GPSD filled the syslog with UTC related messages. I took away the mask to see why GPSD doesn’t see the device. Here are my findings.

Another error message stops GPSD from using the Hardware. This error message has a solution which must be used.

*******gpsd:WARN: shmctl for IPC_RMID failed, errno = 1 (Operation not permitted)
*******Solution:
*******http://savannah.nongnu.org/support/?109325

Use: sudo ipcrm -M 0x47505344

This resets the device and GPSD to degoiate working together. I disconnected the network and tested. I am back working again.

Another observatonal items is ttyACM*. Assigning a ttyACM port to any RS232 dependent device is futile rule wise. The OS does what it needs as devices boot up when plugged in. Using rules to control devices is good documentation. This can be controlled.

1. ttyACM0 is supposed to be AstroEQ. This manages the motors of the OTA.

2. ttyACM1 is supposed to be UBlox-7. This is the GPSD to tell AstroEQ where it is in Time and Geographical place in UTC terms.

The rules for both begin with this start

ACTION=="add", SUBSYSTEM=="tty",KERNEL=="ttyACM0",

Or

ACTION=="add", SUBSYSTEM=="tty",KERNEL=="ttyACM1",

SYMLINK now works. So, the symbolic port can be used. This way the tty device is dependent on the exact one used.