Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about NTP clock accuracy with RPI3 #55

Open
nt74 opened this issue Jun 18, 2024 · 9 comments
Open

Question about NTP clock accuracy with RPI3 #55

nt74 opened this issue Jun 18, 2024 · 9 comments

Comments

@nt74
Copy link

nt74 commented Jun 18, 2024

I have installed rocky-pi OS on a RPI3 and dwm desktop. I have also installed all necessary packages to be able to run the OnAirScreen app.
The NTP clock is syncronised via chrony daemon and I am using our in-house NTP-clocks as well as ntp.org pool as backup. I have also installed a fake-hwclock (for RTC).
No matter what I try to configure when I compare to our PTP Grand Master clock (Clock readout) and "Atomic clock" phone app, the OnAirScreen clock is a bit late, approximate 0,5 second late.

Is there any adjustment and/or tweaks I can do?

@saschaludwig
Copy link
Owner

The OnAirScreen uses the system clock and has a screen refresh rate of 100ms
Could you try to check if the system clock is running correct?
Maybe in a terminal like so:
while true ; do sleep 0.1 ; date ; done

Do you have NTP warning enabled?
The NTP warning checks the local system time against your configured ntp server in OnAirScreen and if there is more than 300ms deviation, it will display a warning.
So your system time could be just 0,5s off. Maybe try ntpd instead of chrony or try to manually sync time with ntpdate.

@nt74
Copy link
Author

nt74 commented Jun 18, 2024

I did setup the while loop in a terminal window and the OnAirScreen app on the other and it seems like there is a delay of about 0,5 seconds between the NTP time on the terminal and the application.
Is there a way to eliminate this delay inside the application?

@saschaludwig
Copy link
Owner

Which version are you using?

@nt74
Copy link
Author

nt74 commented Jun 18, 2024

Latest GIT-version, 0.9.6beta2

@saschaludwig
Copy link
Owner

Latest GIT-version, 0.9.6beta2

Thanks, I will try to reproduce that on a RaspberryPi 3 Model B V1.2

@saschaludwig
Copy link
Owner

I tried the latest build here on a RaspberryPi 3 Model B V1.2 with my default Raspbian/RaspberryPi OS, and it has no such issue. See the captured output of the HDMI port: https://cloud.astrastudio.de/s/Z7XcYSggdKDZGgZ

So I guess the latency is somehow introduced in your distribution by whatever components are in-between the Qt rendering and the actual placement on the graphic card buffer.

That being said, it seems there is a need for an arbitrary latency compensation.
For example, when you feed your signal to a video mixer or crossbar, which introduces latency.
I will include such a static +/- compensation in msec, as config option in the next version.

@nt74
Copy link
Author

nt74 commented Jun 20, 2024

Which OS are you using for the RaspberryPi3 Model B V1.2 ?

@saschaludwig
Copy link
Owner

Which OS are you using for the RaspberryPi3 Model B V1.2 ?

The official Raspbian/RaspberryPi OS https://www.raspberrypi.com/software/

@nt74
Copy link
Author

nt74 commented Jun 20, 2024

It is strange that I cannot make it work, I have tried the official software as well.
Any particular installation steps I have to take? What packages to install etc?
I was successful with a Rocky Linux 9 x86_64 distro with just installing the pip requirements and qt5 packages. However I am not able to make the NTP time to be in sync with the system time with my RPI3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants