LTC SMPTE: Local freerunning clock running behind #287
Comments
|
Hi Dirk, I will try to replicate the free running clock problem that you are experiencing. The free running clock is based on H3_TIMER->AVS_CNT0 rpidmx512/lib-clib/src/h3/time.c Line 47 in 7a83cc4 According to the datasheet, there is a more accurate high speed timer. I will investigate of using this timer will improve the free running clock. Thanks, Arjan 
|
|
Hi Arjan, did some further testing. The issue does not happen when using source "internal". It is freerunning now for more than 30 minutes and has no visible lag to the GPS clock running next to it. Also the ~37s frame miss alignment seams not to happen. So I guess it is something just in combination with NTP Client. UPDATE: After more than 12 hours the "internal" clock is running less than 1s ahead. That sounds reasonable for a free running clock. |
vanvught
changed the title
|
Note: Changed NTP polling from rpidmx512/lib-network/include/ntpclient.h Line 40 in 20beb67 to |
|
Do you want me to test anything ? Where can I find the new Image ? |
|
Hi Dirk, I have reverted the NTP Client poll power back to 3. This would set the system time quicker, hence less drift. Thanks, Arjan |
|
Latest build. |
|
Thank you. At first the lates build looked quiet good. Viewing the clocks by eye they seem to be and stay perfectly in sync over pretty long time. But as my timecode reader has noticed some drifts in framerate I took a deeper look. I recorded the LTC output and analyzed it with ltcdump from this project https://github.com/x42/ltc-tools. This analyzes the LTC audio file and detects wrong frame as well as the aligment to the audio samples. Here is an example on what happend several times in similar ways: #User bits Timecode | Pos. (samples) Here is another example where the clock really stops for a short moment, even visually on the small OLED screen: 00000000 19:36:29:15 | 74808684 74810603 Interesting facts I noticed:
I put these ltcdump data to an excel file and printed errors over time (vertical line = some error): Following issue has probably the same reason: |
|
Hi Dirk,
That is 2^3 seconds were the NTP Client is synchronising the local system time. I am working on changing the timer for the local system time. However this needs testing HDMI on the OPi One, and DMX on both boards. Thanks, Arjan |
|
References to HS_TIMER
|
|
Let me know if I can test new builds on the OPi Zero. During this process I am still not sure would be the right way to go. If the LTC is updated to some NTP clock from time to time neccessarily there will be jumps in the LTC that would make the time more accurate but would also lead in some missing or some double frames. The other option would be to just update every 24h during the night so errors are minimized but that would need a good freerunning during the day to have at least 1-2 seconds drift in 24h. Perfect solution would be something that aligns the LTC (system time basis) to the NTP permanently by stepping up or down the clock speed according to the reference, so no jumps need to occur in the LTC. The chrony project does on linux for system time to NTP sync but I don't know if that could work on an OPi as well. |
That should be possible on the OPi Zero as it run Linux as well. I will look into the OPi driver for Linux.
|
That is what I am working with. As it breaks current code, it is some time expensive work. |
|
Hi Dirk, please will you give the attached firmware a test? I have set the NTP Client poll power back to 10. And using now the ARM Generic Timer as done with Linux. Thanks, Arjan |
|
sorry for the delay ... this release is now syncing every 2^10 seconds to the ntp server but the LTC also jumps + ~15min with every sync. Here are two examples happend right after each other in the same recording. 00000000 16:30:07:00 | 48903307 48905226 The clock it self seams to be accureate than the one before. I did not see any noticeable drift during the 17min. But in between the syncs there are still every few minutes lost and sometimes wrong ordered frames in the ltc output.: 00000000 16:29:54:22 | 48321566 48323485 |
|
Hi Dirk, I would like to split this issue in 2 items:
When you disable the NTP Client, then the local free running is oké ? Thanks, Arjan |
|
no problem, running on source "internal" it is very accurate and stable now, I've not logged a single error in 6 hours and drift is less than 0,5 seconds (OPi is running faster than real time), also acceptable from my point of view, I'll update my post tomorrow after 24h UPDATE: ... the internal ltc does not exceed 23:59:59:24 |
That is as designed. Otherwise the time coded show will start at the beginning 00:00:00:00 again. It is not expected that there is a time code show for more than 24 hours. |
|
You are right for timecode shows, I'm thinking of using this as a master time of day that repeats every day. |
During more testing of the NTP to LTC functionality I noticed that after an NTP sync (and of course every reboot) the LTC is in sync to other GPS locked clocks but it seem to be running in freerun until the next NTP sync in about 15-20 minutes. During that time of ~17 minutes (in my case) it is already running 2 seconds behind the GPS clock. With the new NTP sync it than jumps back to correct time. e.g. from 19:52:33 to 19:52:35 as well as 20:09:38 to 20:09:40 during my tests.
I also noticed some frame miss alignments in the LTC output every ~37s. e.g. [... :18,:19,:20,:21,:22,:21,:24,:00 ...] Letting the OPi run for roughly 12 hours freeruning (disconnected NTP Server) the time difference was about 3 minutes. That would be around 1f every 10s.
Any ideas how this could be fixed? Thanks Dirk
The text was updated successfully, but these errors were encountered: