×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Astroberry configuration and accurate times

  • Posts: 181
  • Thank you received: 13
I am taking images and would like to ensure the time captured in the FITS file is accurate.  I notice astroberry default install isn't set up to use NTP servers. Timedatectl reports NTP Service: Inactive.
Should I install NTP and configure to get time from specific NTP servers or is the default configuration sufficiently accurate? 
2 years 5 months ago #76956

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

  • Posts: 3
  • Thank you received: 1
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
 


 
2 years 5 months ago #76967

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

  • Posts: 181
  • Thank you received: 13
Hi Erik. Yes your reply helps. Thanks for the tips. 'sudo systemctl status chronyd' indicates the clock is set on boot up and IP addresses of 3 servers are referenced. I am no expert but from I have read chronyd seems appropriate for an Astroberry client and is a later development to NTP although it uses the underlying NTP protocol. I normally turn off the raspberry pi after an observing session so it boots up regularly and must set the clock each time. I don't know how often chronyd checks when Pi is running? I guess there is a log that captures when the time is adjusted or a config setting that specifies how often it checks or maybe it works this out for itself based on how fast it drifts. Anyway I am assuming the system adjusts the time and doesn't drift with the crystal and I would have hoped the Astroberry developers would have flavoured raspberry with the best set up? It's just a case how accurate . To fractions of a second I hope.

The other factor possibly more significant is how accurate the fits file captures the start of the exposure because this is the time used in later analysis.

I have an observatory so don't change location but I notice Ekos does have GPS and interested in your suggestion of using a GPS dongle. Will it give me significantly more accurate time?
2 years 5 months ago #76989

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

  • Posts: 348
  • Thank you received: 69
It checks pretty often, usually it checks every minute, then once synced it slows down the polling, if it starts to notice the clock skewing away from real time it starts syncing more often again.

You can check status:
astroberry@astroberry:~ $ chronyc sources
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^+ ntp1.as200552.net             2   6   377     6  +1506us[+1506us] +/-   55ms
^* ns3.turbodns.co.uk            2   6   377     7  +2646us[+3105us] +/-   24ms
^+ time.rdg.uk.as44574.net       3   6   377     5  -3072us[-3072us] +/-   50ms
^- time.videxio.net              2   6   373     1  -3743us[-3743us] +/-   69ms

MS - status "^" = reachable, "+" candidate for sync, "*" currently sync'd
Stratum = how many hops away from a known good time source
Poll = level of polling 6 = 60seconds, 7= 120seconds, 8= 240seconds, etc...
Reach = reachability, this eventually ends up at 377 for fully reachable servers, lower numbers for servers not reachable
LastRx = number of seconds since server was last contacted
Last Sample = the data, note that the +/- is the accuracy, so chronyd should sync your time to around +/- 4 hundreths of a second, you may get better results

If you have a permanent PC that is always on, then you could run NTPD there, and configure chronyd on the Pi to sync to that, it will get better sync as the latency to the PC will be lower than an Internet time server.
To do that, look up the documentation on the Internet, configuration for chronyd is done via /etc/chrony/chrony.conf - by default it connects to a pool of servers, but you can configure a specific server using the server [IP-Address] directive.
Last edit: 2 years 5 months ago by Giles.
2 years 5 months ago #76993

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

  • Posts: 348
  • Thank you received: 69
The common USB GPS dongles will not supply time in an accurate way (to the nearest second), you need a more expensive GPS with a different port for GPSD to supply time accurately to ntpd/chronyd.
The following user(s) said Thank You: David Bennett
2 years 5 months ago #76994

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

  • Posts: 348
  • Thank you received: 69
The "watch chronyc tracking" may be useful for you.

ntpd/chronyd run complex algorithms, all specifically designed to get accurate time over time. Apart from when the Pi starts and chronyd notices the time is ghastly out of date, chronyd will not otherwise step the clock to the time reported by a NTP server. It will just remove  and minimise errors by speeding up or slowing down the system clock.
Example Output:
Reference ID    : A29FC801 (time.cloudflare.com)
Stratum         : 4
Ref time (UTC)  : Thu Oct 28 12:17:42 2021
System time     : 0.000445855 seconds slow of NTP time
Last offset     : -0.000263734 seconds
RMS offset      : 0.000827726 seconds
Frequency       : 1.653 ppm fast
Residual freq   : -0.001 ppm
Skew            : 0.114 ppm
Root delay      : 0.045226675 seconds
Root dispersion : 0.000737272 seconds
Update interval : 64.1 seconds
Leap status     : Normal
You can type "man chronyc" to get an explanation of all the items there.
The following user(s) said Thank You: Erik
2 years 5 months ago #76998

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

  • Posts: 3
  • Thank you received: 1
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.
2 years 4 months ago #77004

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

  • Posts: 181
  • Thank you received: 13
With the information received I will go and make some checks now Eric. Thanks.
2 years 4 months ago #77009

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

  • Posts: 983
  • Thank you received: 375
I will add just one thing to this very valuable thread.
To verify if GPS is used by chrony you can run
chronyc sources -v
If not, check /etc/chrony/chrony.conf file and make sure that the line
refclock SHM 0 offset 0.5 delay 0.2 refid GPS
is uncommented (no # in front of the line).
If you need to edit the file, save changes and remember to restart chrony by running
sudo systemctl restart chrony
2 years 4 months ago #77027

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

Moderators: Radek Kaczorek
Time to create page: 0.515 seconds