Giles, thank you for the useful pointers to chronyc commands. According to the man pages  "An absolute bound on the computer's clock accuracy (assuming the stratum-1 computer is correct) is given by: clock_error <= |system_time_offset| + root_dispersion + (0.5 * root_delay)"

With your sample output of the "watch chronic tracking" command the absolute bound clock error appears to be: 23,6 ms. I just tested with my RPi and end up with similar order of magnitude values: approx 13.1 ms after 30 min uptime, improving to 10.8ms after 75 min of uptime. So indeed the order of 10ms magnitude that can be expected with NTP over a good nework connection (and nobody watching netflix here at the moment .

David, I should have clarified that I choose the RTC and a GPS dongle primarily because I have a portable setup with NTP connection not easily available and I am fine with a time error of a second or so. I configured EKOS that the mount gets time and location information from GPSD as a convenience. The RTC will be synchronized by NTP every time I do have a network connection.

I have been looking into using GPS as an accurate local time source but as Giles points out, this will not work with a serial GPS dongle.  A GPS hat that also makes an accurate 1s time pulse available on an GPIO pin should work though - see for example this project github.com/domschl/RaspberryNtpServer. In my setup that would require a different case and then there is the concern of USB3 interference I mentioned so I have not yet pursued this.

In your case I would first check if your  NTP time synchronization over your network is good enough for you.  If this is not sufficiently accurate, given that you are on a network, you could setup a GPS based time server in any convenient location on your network (based on another RPi or  otherwise) away from any interference  and then configure the RPi in your observatory to use this as one time source.

Read More...

Hi David,

I understand that Astroberry uses "chrony", not ntpd, for the NTP protocol.  "sudo systemctl status chronyd" should show if this service is running.
chrony is running on my astroberry but timedatectl does indeed report "NTP Service: Inactive".  I do not know why this is.

Anyway, as the regular Raspberry Pi has no battery backed realtime clock, the date would default to 1970-01-01 on power up without an NTP client running and/or without network connection.
If you have a valid date/time and no battery realtime clock added, ntp must be running
Note: commercial RPi based astrocomputers will typically add a battery backed RTC  - valid date time is then no indication of running NTP. I have added a DS3231 based realtime clock to my  RPi (connects via I2C). for portable, off grid use.

As for accuracy: Without NTP the RPi clock is based on the processors crystal oscillator which is not temperature compensated. Time will drift with seconds per day. The DS3231 based RTC that I use, has a temperature compensated oscillator which (from memory) should drift less than a second per month. With NTP available, accuracy depends on many factors but will typically keep your clock within 10 of ms, but may drift up to 100 ms in congested, high latency networks. If time accuracy requirements are more strict (asteroid occultation measurements?) you could use GPS as a highly accurate local time source,

If you are going to use a GPS device , please note that USB3 signals can cause significant interference with the GPS signal (just as the widely reported interference that USB3 causes with 2,4GHz Wifi). I use a GPS dongle and place it as far as possible from RPi and USB3 cabels and camera. Even then I sometimes need to disconnect my USB3 camera to get initial GPS lock - but that is topic for another discussion.

Hope this helps,
Erik
 


 

Read More...

Same issue here as described by Jonathan and Alfred a.o.. Kstars/Ekos on a Raspberry Pi 4 / Astroberry upgraded to v.3.5.5 from previous versions with (regular) apt-get upgrades.

Kstar - Data - Download New data - Install [any catalog]  will download the corresponding .kscat file but it is not marked as installed in this window
nor listed in
Kstar - Data - Manage DSO Catalogs.

However, as described by others,  the .kscat file(s) are downloaded in ~/.local/share/kstars.
I tried using the "Import catalog" function of Kstars - Data - Manage DSO Catalogs, and selecting these .kcat files I did manage to install the catalogs.
(Import catalog did not let me browse into the .local folder, so I copied the files first to a reachable directory.)

They catalogs are then still not marked as installed in Data - Download new data, but I can now search again for these additional DSO objects with the find object function.

(I do sometimes have to type the full name though before some items are visible in "Find object" - not sure if this expected behaviour or also a new issue)
(For example, after installing the Sharpless catalog, typing "SH2 3" will list a range of entries starting with "Sh2 3" but "SH2 32"will only appear after I type the full entry)
 

Read More...