RE: [Bacnet4linux-developer] BACNet4Linux TimeSync

[Coleman B. <col...@co...>]

Hi Steve,

> -----Original Message-----
> From: bac...@li...
> [mailto:bac...@li...] On Behalf
Of
> Steve Karg
> Sent: Saturday, March 12, 2005 7:04 AM
> To: bac...@li...
> Subject: Re: [Bacnet4linux-developer] BACNet4Linux TimeSync
> 
> Hi Coleman,
> 
> > in the BSD headers.  The current B/IP code has been working (send
and
> > receive!) like a clock for months now...
> 
> Excellent! I will have to fix the bacnet4linux code soon, and yes,
that
> string copy caused me problems initially (seg faults) so I converted
ALL
> the bacnet4linux code to use the BSD IP address (struct in_addr ip;)
as
> address storage and not a string.  I must have missed something
else...

That would have been the optimum solution, and probably easier on memory
requirements.  The strncpy is fairly prevalent now, in my version, so
part of it is laziness on my part to go in and break it again and fix
all those areas. :) I'll have to bite the bullet and do it, though.    


> 
> > A BACnet device isn't allowed to simply broadcast time-syncs.
> 
> Well, actually it is allowed to broadcast time-syncs, provided it has
a
> broadcast address as one of the addresses in the list of recipients.
> 
> > BACnet device *have* to contain a time-sync-recipient property and
it
> > must be writable.  Even more than that, there are some bizarre rules
> > with what can be written.  However, Steve is right, it's implemented
and
> > works beautifully.
> 
> You are right - the Time-Synchronization-Recipients property is
required
> if the PICS indicates that the device is a Time Master, and it is
> required to be writable if implemented.
> 
> Well, it should simply be a matter of implementing the list and
handling
> the write property services.  You should be able to whip that code out
> in 15-30 minutes, no? :-)
> 

Isn't it true that if a device performs a time sync request then it's
considered a time master?  

Funny you say that.  I started implementing the write property service.
The function is there with the beginnings of a parser. So, 15-20 minutes
for *that* property!  :-)

> > What I had considered doing was letting my BACnet device receive
it's
> > time via NTP (ntpd???) and then have my BACnet stack broadcast
TimeSync
> > requests occasionally, say every 15-30 minutes.  So, from my point
of
> > view (in the case of my current implementation), yes this is quite
> > helpful.  However, can't this be accomplished by the current NTP
> > mechanisms?  However, my device isn't a workstation.
> 
> ntpdate/ntpd keeps the system clock updated, and can update other
> devices via NTP.  BACnet TimeSync would simply rely on the system
clock
> and update BACnet devices that are in its recipient list, or simply
> update via global or local broadcast if that is in its recipient list.
> 

Yes, that's precisely what my design called for.  The user tells my
widget to get it's time from external time source (assuming an Internet
connection), and my widget syncs its time with that source.  Then every
15 minutes (is this too often or not often enough? -- maybe
configurable) my widget performs a time sync for everyone in its
time-sync-recipient list (I'm implementing the BACnetAddress flavor).  

> Thanks for the update, Coleman, and for the insight!
> 
> Best Regards,
> 
> Steve
> --
> http://kargs.net/
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Bacnet4linux-developer mailing list
> Bac...@li...
> https://lists.sourceforge.net/lists/listinfo/bacnet4linux-developer