Hi All,

I have tried to use the Fast Clock using Time Broadcast Protocol in Ver 4.14+Rd06e0b but I do not see any activity in the OpenLCB Monitor.
Do I need to do something other than start/stop the fast clock?
Regards
Nom

Nom,

I'd suggest using 4.17.3 (4.16 has baud rate issues for some systems) as
there are updates in the LCC/OpenLCB library since 4.14.

-ken cameron

Ken,
Thanks for you reply.? I upgraded to 4.17.3 but I still do not see any CAN activity or any activity in the OLCB Monitor?from JMRI when stopping or starting the clock or on a minute change.
Regards

Nom

It seems to me that the functionality of the Fast Clock has somehow not made it into 4.17 either.? There is no activity in the traffic monitor and I would expect that it would show there regardless of baud rate issues.
?I also cannot get the start/stop button to show on the displayed (LCD) clock.

Nom

Nom,

There are few known bugs with the implementation.? This is one of them.? There is a hardware fast clock in development that will work with the JMRI fast clock over OpenLCB/LCC.? I'll ping the developer that worked on this feature to comment.

Thanks,
Stuart

Thanks Stuart.

I have just rewritten the software in my current LCC hardware clock to use the draft time protocol.? I can use a minute change watcher to send the info but as 4.14 and 4.17 release notes indicated the feature was available I wanted to make sure I wasn't missing something that was required to provoke the time broadcasts into action.

Regards
Nom?

Nom,

I didn't realize you have your own implementation.? That's great.? If you are able to act as the Broadcast Time Server, I think the JMRI will function just fine as a client.? The client is simpler, and I think most of the JMRI implementation bugs are on the server side.? You should still be able to use the JMRI interface to setup the time server if your implementation has the setup over the network features.

Thanks,
Stuart

Hi Stuart,
Sorry to confuse the issue.? My clock is a slave, and yes, the implementation is reasonably simple.? I was thinking that the JMRI clock may not start sending events unless it sees a Consumer Identified for some or all of the events in the Time Protocol.? I only implement time, start and stop.
The rate is auto determined by timing the period between successive minutes and calculating the internal second rate.

Regards
Nom

Nom,

I wrote the OpenMRN C++ implementation for both the time server and client for OpenLCB.? I haven't messed with it in a little while, but I'll have a more detailed look at it again over the weekend.? We are supporting a commercial manufacturer with the OpenMRN implementation for their Fast Clock product that should launch this year, so getting back into it over the weekend has overlapping value with that effort.

Stay tuned...

Thanks,
Stuart

开云体育

Hi,

If I understood things correctly at SLC, the only time the 'clock' sends events is if it has seen a 'request' for that event during the initialization. A request meaning that some consumer was configured to a 'well known' clock event.

Dick :)

Hi Stuart & Dick,

Thanks for the replies.? I had assumed JMRI would not just send LCC frames unless there was an LCC connection and a clock slave on that.? But at this stage of development, the doco is not very specific.

Regards

Nom

On Thu, Sep 12, 2019 at 02:07 PM, dick bronson wrote:

If I understood things correctly at SLC, the only time the 'clock' sends events is if it has seen a 'request' for that event during the initialization. A request meaning that some consumer was configured to a 'well known' clock event.

Dick,

This is not exactly true.? You are correct, that if a 'request' has been received for a particular clock event, the clock is to always send that event when appropriate.? While the clock is also not required to send an event for every fast time second, it is required to send at least one event every once per real time hour, and no more frequently than once per real time minute.? The clock client is required to track time internally between clock events sent by the server.

This is all spelled out in detail in both the Standard & Technical Note.

Thanks,
Stuart

My understanding of the design was not to broadcast events that were not
being listened for. The ideal was to save traffic that wasn't needed. The
result is any client must support the protocol for doing the request
producer etc...

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org

On Fri, Sep 13, 2019 at 10:32 AM, Ken Cameron wrote:

My understanding of the design was not to broadcast events that were not
being listened for. The ideal was to save traffic that wasn't needed. The
result is any client must support the protocol for doing the request
producer etc...

Ken,

This is partially correct.? We do still need to periodically broadcast a time event so that time clients that are tracking the progression of time internally do not accumulate time drift away from the server.? Again, if you read the S & TN, it is all outlined in those documents.

Thanks,
Stuart