agree on minimal set of parameters for fixed time programs

[emiltin]

No description provided.

[emiltin]

Parameters have been split into region/controller/intersection/program.

Parameteres for fixes time program is in:
https://github.com/rsmp-nordic/tlc_progamming/blob/main/program_fixed_time.yaml

[emiltin]

Define the cycle length.

[emiltin]

Is offset part a a fixe time program, or is that a controller parameter that's outside the program?

[emiltin]

I added cycle length as a parameter.

[marekzukal]

Offset should be a parameter of the signal program. Usually is. There can be an option to dynamically set the offset if there is a need later.

Historically there are multiple absolute cycle time sources (second of the day, month, year, etc.) New system should not copy obsolete solutions - let us have just one.

CTX = Cycle time within the signal program
Timestamp = Unix timestamp (64b)

CTX = (Timestamp + Offset) % CL

[emiltin]

Good idea to define this, although UTC is used for timestamps in RSMP. Unix time differs from UTC in the handling of leap seconds:
https://en.wikipedia.org/wiki/Unix_time

[marekzukal]

What we need is a global counter of seconds. Traditional methods use the number of seconds between a fixed point in time (day, month, year, arbitrary date). To my knowledge they all disregard leap seconds. (That does not mean that the system itself should not support handling of leap seconds.) Using Unix time allows us to have a widely available integer counter to use for synchronization. The main benefit is that the relationship between UTC are already well defined and understood.

Occurrence of a leap second will cause a coordinated signal program to fall out of synchronization (just like any other clock synchronization) and a need to synchronize again. All the traditional methods would be affected the same. A way around this would be to use something like TAI (https://en.wikipedia.org/wiki/International_Atomic_Time), but I think it is not worth the effort.

[emiltin]

A global counter implies syncronization, and the de facto standard to handle this is NTP.

UTC also handles leap seconds, although in a different way than Unix time. Would it not be easier to use UTC, since all RSMP timestamp are in UTC already?

[emiltin]

Since, as you point out, we need a second counter, that is in effect unix time, which is defined as "the number of non-leap seconds which have passed since 00:00:00 UTC on Thursday, 1 January 1970". The handling of leap-seconds is a bit tricky, but can be managed as you suggest.

So I think we agree :-)

[marekzukal]

Yes, it is a synchronization mechanism. I believe we are talking about different synchronization mechanisms on a different level and for a different purpose. The controller clock is running in UTC and there are multiple different methods of synchronization.
Now, for the purpose of time based coordination, the controller has to determine the position of the signal program that it is running relatively (using the offset parameter) to a global cycle counter. Then all the controllers in the group have the same global cycle counter and each of them can set its own cycle counter properly using the offset. The key is to have a way to transform UTC time to a continuous integer. So I am proposing Unix timestamp as it is the one I have the most experience with.
Sorry for the confusion. I sometimes forget the amount of context these terms carry :-D

[emiltin]

I agree Unix time is a simple and well-defined way to get a second counter from the UTC time that controllers use.

When a leap second occurs, Unix time jumps forward or backwards one seconds. We can handled like we otherwise handle changes in offset, as you mention above.