Jump to content
Reva

Absolute UTC-based Timecode?

Recommended Posts

Would an absolute timecode based on UTC time be a viable option?

 

Using UTC (Universal Time Coordinated, the worldwide used date/time of day reference) as absolute timecode would allow to operate any device totally independently anywhere in the world while keeping a very precise uniform timecode.

 

With a GNSS-disciplined precision oscillator it would be possible to keep absolute time sync better than +/- 3 milliseconds per day even if the GPS/GLONASS/... satellite signal is lost.

With automatic GNSS resync a precision better than +/- 1 ms is easily possible. The drift without any GNSS signal to resync until 1 frame is reached would correspond to about 2 weeks.

Effective precision depends on the used hardware, figures are based on relatively inexpensive commonly available components but higher precisions are possible (for example GSM networks are synchronized with sub-microsecond precision relying on GNSS time references).

 

With an absolute UTC-based timecode each device could manage its timestamps entirely autonomously.

 

I'd be interested to know if such system could be used as technically it wouldn't be very complex to implement.

 

Share this post


Link to post
Share on other sites

Sure, that could be nice. Now you just need to convince every single manufacturer to install one of these systems in their devices. That includes camera, sound, studio, and others. Ideally it should include manufacturers from both high-end and low-end devices, as to me this would mostly make sense if I then wouldn’t need a TC device anymore. 

 

Couple of caveats could be:

indoors sync would be lost. The clock would continue to run of course, but at what precision? Varying probably. Also the TC quartz would need to be temperature controlled. Both of these (GNSS and TCXO) need space. An increasingly rare commodity. 

 

 A minor thing: when shooting nights I like to offset TC by 12 hours so as not to cross midnight and have the ToD effectively jump back 12 hours, potentially causing problems for post. Or some directors or ADs ask for the TC to start at 0:00 so that they can keep track of the shooting time. That wouldn’t be possible with self-syncing systems - unless you program a software utility into the firmware that would allow for such user settings which could be derived from the main clock. Surely possible, but it adds... 

 

 

Share this post


Link to post
Share on other sites

OB vans and tv studios usually use a TC that's set by GPS, local time.

When doing ENG sports shoots I (have to) ask the engineer to give me an output to synchronize our mixer and camera.

 

I guess the reason why there is no common use of UTC as TC in our world is that there are too many concepts gathering absolute time. There is GPS (not working in buildings), DCF77 (only central Europe), mobile phones (no reliable time Information) and other ways I don't know.

A manufacturer only will develop a TC device that works everywhere in the world to get money out of it. Not possible nowadays 

Share this post


Link to post
Share on other sites

Thanks for your replies

GNSS, which simply means that in addition to GPS, where available, other satellite navigation systems are also used, typically the Russian GLONASS, the other ones not being fully operational yet. For the user it's totally transparent and receivers track as many satellites of any system they can receive and decode (at least within the maximal number of satellites data channels a receiver can track simultaneously). Many receivers are designed to simulatneously track many more data channels (up to 400 or even more) than they can actually receive. More advanced receivers allow shorter times to first fix (TTFF, i.e. how long it takes to compute a position solution after a total loss of signal).

The timing accuracy of GNSS positioning systems is very high, which allows simple GNSS modules (costing a few US$) to be used as time reference with a precision way better than one millisecond. The precison of a GNSS-disciplined time base is mostly limited by the precision of its local oscillator when GNSS sync is unavailable.

DCF77 (https://en.wikipedia.org/wiki/DCF77) is useless for precise timing, it's widely used for basic clocks and also for industrial purposes and computer networks not requiring a precise time alignment because the required hardware is trivial and the decoding is extremely simple. As cheap GPS modules are now available it doesn't make sense to use any other RTC clock sync as long as it's possible to receive the signal.

With a relatively inexpensive basic GNSS time reference module integrating a local crystal oscillator a typical absolute timing accuray of about 20 ns (optimal conditions) and 500 ns (indoor) can be achieved (1 nanosecond = 0.001 microsecond = 0.000001 millisecond = 1E-9 s) in GNSS-disciplined mode.

In a GNSS-denied environment, i.e. where reception of satellite signals doesn't allow the processing of a valid UTC solution, the time reference issued by the module is based on its local crystal oscillator. In such case the timing accuracy drops to 100 ppb per 24 h (0.1 ppm or about 8.6 ms per 24 h), the effective precision will be better as the mentioned value applies to the whole temperature range of -40 to 85 °C (-40 F to 185 °F).

The required power in any mode doesn't exeed about 140 mW (at 3.3 VDC) and the mass of the bare module is around 2 g so it could certainly be integrated in battery-powered portable recorders or timecode generators.
Only for small hanheld portable recorders the power could be too high but the whole device could be shut down simply relying on resyncing after each power up.

Cold start acquisition time (TTFF, see above) depends on how well satellite signals are received and is typically around 10 to 30 s (some satellite constellation data is temporarily stored to allow faster cold starts than about 30 s but only if that data is not too old).

If GNSS is available the clock drift is negligible for timecode purposes (better than 1 microsecond) and in a GNSS-denied environment the max. drift in the discussed example would be around 9 milliseconds per 24 h (or 1 frame in about 4.5 days at 24 FPS). Any GNSS resync realigns the internal clock to full accuracy.

As UTC is an absolute time reference there's no need to worry about time zones, DST and other time corrections. UTC is identical at any moment everywhere in the world.

For timecode the discussed precision is high enough.

Other applications like absolute audio sampling sync or video genlock could probably also be achieved but I didn't check the specific timing accuracy requirements.
If higher precisions would be required more precise external oven-controlled crystal oscillators could be used but they're much more expensive and require around 1 to 4 W of power depending on the ambient temperature.

Share this post


Link to post
Share on other sites

Several years ago a friend of mine used that TC as the basis of sync between recordings being made on several continents at once.  I understand that it worked in the main but not without issues.  Cool idea though.

Share this post


Link to post
Share on other sites

I was referring to UTC because it's a universally available reference, there are not issues related to time zones, daylight saving, time corrections or so.

The precision I mentioned corresponds to the specs of relatively cheap modules which can easily be integrated in a design, lower precisions won't allow much lower costs and higher precisions are only required for special purposes (maybe genloc or sampling clock reference), in such case maybe 100 to 300 US$ should be added for a much more precise oven-controlled internal oscillator. When GNSS timing is available the time base precision exceeds requirements for sampling and genloc but jitter requirements should be verified.

Generating the time reference as I mentioned it does not require complex hardware, from there the used code can simply be either UTC or an arbitrary offset from UTC (though there remains the midnight roll-over issue mentioned by Mungo while true UTC is univoque).

I'm simply surprised that no time code standard based on UTC has been proposed, manufacturers and users could simply be offered the option to use either common timecode as usual or an absolute UTC version. To ensure interoperability, the usual timecode shall always remain a possible option, either as UTC offset or with common local (UTC independent) generation and snyc.

As the discussed GNSS time reference modules are relatively recent so comparisons shouldn't be based on older similar devices. Performance of the whole system depends also on the overall design including the antennna.

Share this post


Link to post
Share on other sites

I remember reading several articles about Ben Osmo's team on Mad Max Fury Road using several Ambient ACC501 Master Controllers with GPS Modules to jam their Lockits each day - as there were several shooting unit bases widely situated in the desert they started from each day, but may have ended up shooting the same action. I understood this to be a kind of GPS Time Of Day. The roll across midnight problem can be easily fixed with a standard 'time zone' offset.

My concern with GNSS modules in individual TC Boxes is their ability to actually see a satellite signal in many shooting environments (ie: indoors) or getting desensitised by strong RF fields from other gear on the cameras like Video Transmitters and such. In a real on-set environment, even getting the time to take them outside to 'see a satellite' after power-up at the start of the day, before putting them on the cameras, can be a challenge.

Share this post


Link to post
Share on other sites

RFI sensitivity highly depends on the used GNSS receiver, there are more or less advanced anti-jamming techniques, both based on hardware and software solutions.
I expect that modules like the discussed ones to perform well enough in presence of RFI levels like the ones you're referring to, especially also because you don't need continuous time solutions.

For the other issue, signal obstruction leading to GNSS service denial, while some receiver/antenna combinations perform better than others, there is obviously no universal remedy.

IMO practical tests should be done in order to determine if this factor is critical or not as well as for RFI/EMC.

What would be considered as acceptable clock drift per 24 h?

I mentioned 9 ms per 24 h worst case but it would be less if temperature variations are lower than 125 K. The required power is quite low (max. 140 mW with GNSS receiver and local oscillator running) so the idea would be to keep the device running 24/24 7/7.

Share this post


Link to post
Share on other sites
2 hours ago, Reva said:


What would be considered as acceptable clock drift per 24 h?

I mentioned 9 ms per 24 h worst case but it would be less if temperature variations are lower than 125 K. The required power is quite low (max. 140 mW with GNSS receiver and local oscillator running) so the idea would be to keep the device running 24/24 7/7.

 

9ms drift would be absolutely acceptable for normal TC duties. Anything below about 40ms would be OK. As a sample clock this would not be acceptable, but a sample clock doesn’t need a time of day reference anyway. For genlock it should be ok, too, but I‘m not sure. 

 

About the power. 140mW per ...? Per hour? That wouldn’t be that low. It would probably need its own battery (if it became a part in a bigger system), making it all bigger and costlier again. And what for? For the very rare case needing to keep time at exactly the same speed over great distances? 

There may be various situations where it could be useful, but for our standard scenarios I don’t see a big need for this. It would only make sense if absolutely every manufacturer were on board. Then we wouldn’t need external TC boxes anymore. Nice, but not essential. For TC box manufacturer this could be a viable path, but to what benefit exactly for us users?

Share this post


Link to post
Share on other sites

Ah, I'm moving to Flicks. Finally, I no longer need to put off sync. :-) (Actually, perhaps some programmers can tell us if this will be helpful for our world...or maybe it's more of a VR/AR thing...)

 

Facebook invented a new time unit called the ‘flick’ and it’s truly amazing

 

I was all set to dislike the “flick,” a time unit just recently invented by Facebook (technically the Oculus team), because I thought it was going to be something worthless like “the average time someone looks at a post.” In fact it’s a very clever way of dividing time that theoretically could make video and audio production much more harmonious.

So what is a flick? A flick is one seven hundred and five million six hundred thousandth of a second — 1/705,600,000 if you prefer the digits, or 1.417233560090703e-9 if you prefer decimals.

And why is that useful?

As a hint, here’s a list of numbers into which 1/706,600,000 divides evenly: 8, 16, 22.05, 24, 25, 30, 32, 44.1, 48, 50, 60, 90, 100, 120. Notice a pattern?

Even if you don’t work in media production, some of those numbers probably look familiar. That’s because they’re all framerates or frequencies used in encoding or showing things like films and music. 24 frames per second, 120 hertz TVs, 44.1 KHz sample rate audio.

Many of these fractions resolve into inconvenient decimal series, necessitating shorthand or estimations. For instance, the 1/24th of a second around which the entire film industry is based on is equal to 0.0416666666666666… on and on forever

 

The breathless rest:

https://techcrunch.com/2018/01/22/facebook-invented-a-new-time-unit-called-the-flick-and-its-truly-amazing/

 

Want to know more & are familiar with C++?

https://github.com/OculusVR/Flicks

 

Share this post


Link to post
Share on other sites

The TechCrunch article says:

 

"Even the weird NTSC numbers in use due to certain technical constraints divide nicely. 23.976 (technically 24*(1,000/1,001)=23.976023976230 with the last 6 digits repeating) becomes exactly 29,429,400 flicks. It’s the same for 29.97, 59.94, and any others like them. No more fractions or decimals needed whatsoever! How great is that?!"

 

And it looks like linking through to the Github page offers more info. But I'll need one of our programmer friends here to let us know if Flicks solves any real problems for them (and then perhaps down the road for us). Or if it's a solution for some other segment of the world, or a solution in search of a problem (that has not already been solved).

 

Still kinda interesting. I think...

Share this post


Link to post
Share on other sites

If we take as example a single cylindrical Li-Ion battery cell of a very common type "18650" with following specs:
- Nominal Voltage: 3.6 V
- Capacity: 2.9 Ah
- Diameter: 18.6 mm, Length: 65.2 mm, Mass: 44 g
the energy storage capacity would be (ignoring losses): 10.44 Wh = 0.01044 kWh = 37584 Ws = 37584 J.

The basic power requirement would be around 140 mW but we need some power margin for battery management, stabilizing DC/DC and a more or less sleeping general purpose low-power processor. Lets's add 60 mW, so the total maximal power would be: 200 mW = 0.200 W.

As batteries specs are usually too optimistic, let's derate the battery by about 30 % so we can consider 7 Wh per cell (also a low discharge rate application allows higher battery efficiency than short discharge times).
Doing so with a single Li-Ion cell: 7 Wh / 0.2 W = 35 h of standby duration (maybe with active LCD display but without backlight).

Using for example 4 cells we'd get 140 h of standby (i.e. only running the internal clock and GNSS receiver). As the generated timecode signal is of very low power I don't expect power requirements to be much higher when actively using the device for timecode generation, though using a LCD backlight could draw significant power, especially when set for sunlight readability.

Of course the generated code is a matter of firmware and the user should be able to decide about code details.

Ideally there should be an incentive for a standard and indeed I'm very surprised that users and manufacturers haven't proposed anything yet. The main benefit would be to allow each device to handle timecode totally independently.

Wireless short-range (i.e. very low distance, maybe up to a few meters) sync could be imagined using a portable unit when some sync device would be left on a camera and never be able to receive GNSS signals. The one-time sync precision would be slighty lower but the expected error would still remain way under 1 millisecond.

Referring to time units, it's merely a question of conversion and with current low-power-consumption proccessors it's very easy to calculate sync data using odd units with a precision far beyond the required one. Basically the precision will be limited by the timing reference accuracy but not the precision of timecode computations.

Share this post


Link to post
Share on other sites

so if I understand right we're talking about a medium size NP-F battery just to power the TC generator through a long production day and that still doesn't really work indoors? sounds dead in the water to me.

 

specially when 90% of the camera manufacturers don't even manage to put in a simple accurate independent TC clock - now that would be something worthwhile (with a small fraction of the energy consumption).

 

btw, there are lots of TC units that synch wirelessly already, check the Ultrasync One thread for a discussion about this.

chris

 

 

 

Share this post


Link to post
Share on other sites

The cylindrical Li-Ion cells I was referring to are max. approx. Diameter 19 mm x Length 66 mm (mass: 44 g) and one cell can power the device for about 35 h.
Indeed I expect that the power required to generate the timecode (as long as no LCD backlight is on) to be so small that it won't affect the discussed figures.
With a 4-cell battery you could power the device during 140 hours (or 5 days and 20 h non-stop). Using supercaps would allow comfortable time to hot-swap batteries while device is kept running normally. (I was referring to the bare battery cells, there's some small overhead for the case and and cell protection circuits.)

Now obviously it won't work if used permanently in a GNSS-denied environment but if being able to work over 5 days (and more if a larger battery is used or if the battery is hot-swapped) in a GNSS-denied environment wihtout having to worry about any timecode issue using various equipment could still be interesting.

The wireless-synched TC units you refer to are different as they still require synching (not based on an absolute time reference like UTC which can be acquired independently) and probably also feature less precise oscillators (to be verified but I'd be surprised if they use oscillators in the 0.1 ppm class (full operating temperature range)).

If a local oscillaror drift of 9 ms / 24 h is too large better oscillators can be used but costs and power requirements are increased.

BTW no idea why many timecode generators aren't very precise, maybe it's just a question of cost. The 0.1 ppm precision I mentioned is based on quite inexpensive oscillators. A 50 times more precise oscillator module can be used but it's more expensive and requires up to about 2 W (depending on the ambient temperature).

Board size isn't much an issue, the battery is much larger.

Share this post


Link to post
Share on other sites

yes I understood, but the 18650 are fragile (need a casing) and I'm sure not everybody likes to add another form factor battery to their arsenal (plus a charger). besides it's still way too large - just look at the size of a tentacle/betso/TCS unit, or imaging trying to add a 18650 into a GH5 camera.

plus if you're working in a studio you'll have to carry the camera to the outside every morning.

if you'd manage to build a inexpensive TC generator that keeps synch over 5+ days then you don't really need GPS synching in the first place. or rather, since you'll likely have to swap batteries the point is a moot point again.


sorry, I just don't see how this is better then the existing method of just jamming a tiny TC unit every morning to a master clock (or if that bothers you, then just get one that synchs wirelessly). 

 

now if the power draw/size could reduced by 90% and it would work indoors and be built in into every camera and recorder for 5bucks that would be different, but it does't look like that is possible anytime soon.

 

until then it sounds more like a thought experiment to me.

chris

 

 

Share this post


Link to post
Share on other sites
49 minutes ago, Reva said:

BTW no idea why many timecode generators aren't very precise, maybe it's just a question of cost. The 0.1 ppm precision I mentioned is based on quite inexpensive oscillators. A 50 times more precise oscillator module can be used but it's more expensive and requires up to about 2 W (depending on the ambient temperature).

 

The current crop of tc boxes claim an accuracy of 0.2 - 0.1 ppm, all of them temperature compensated. 

So at this point you’re proposing a new system that will be larger and heavier as current devices, with about the same accuracy or even less (your 0.9 ppm figure) and with the same battery capacity. And for studio productions they come with the added disadvantage of needing to go outside to get a signal. 

Sorry to say this, but unless you come up with better numbers or another compelling advantage, I think we are done here

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×