It's takes 1.04 milliseconds to transmit the 8 byte token frame at 76800.
This comes from the following formula:
((10/76800)*1000)*8 = 1.0417
Tusagetimeout can be as much as 15 milliseconds. So, assuming the worst case where each node "holds" the token for 15 milliseconds before sending the token to the Next_Station:
1.04 + 15 = 16.04 milliseconds per station
16.04*16 = 256.64 milliseconds for 16 devices
16.04*8 = 128.32 milliseconds for 8 devices
Let's round up to 130 milliseconds (for 8 nodes) and 260 milliseconds (for 16 nodes) to account for any errors. This is given your criteria assuming no master node has any data payload and that max-master and MAC addresses are configured optimally (i.e. no PFM cycles encountered by any node).
Worst case, a node in the provided configuration (with 8 nodes) could "get the token" 8 times every 1,040 milliseconds.
Worst case, a node in the provided configuration (with 16 nodes) could "get the token" 4 times every 1,040 milliseconds.
Realistically, you'd see Tusage_timeout values in the 5 - 10 millisecond range. But for purposes of these types of calculations, we should assume the worst case.
From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of Christoph Zeller
Sent: Monday, March 14, 2011 4:13 AM
Subject: [BACnetLighting] MSTP Cycle times
Hi lighting guys,
is there anybody who can tell me how often you get the token per second assuming to have 8 or 16 participants in an mstp network
when no master needs to send payload?
Can we assume 78600 Baud (for lighting applications, or do we have to lower our expectations?)
I try to estimate the possible throughput and bandwith issues for lighting applications.
-----BACnetLighting@yahoogroups.com schrieb: -----
Von: "David Ritter" <dritter@...>
Gesendet von: BACnetLighting@yahoogroups.com
Datum: 11.03.2011 19:56
Betreff: [BACnetLighting] New document for March 15 telco
I have uploaded a new version of the proposed changes to the lighting command (DHR-019-05). It is available on the yahoo group. Please get this document and review it if you are going to participate in the March 15 telco.
There are three significant changes from the previous version. The first is the Lighting Command property was changed from a constructed datatype to an Octet String. The second is a special value of -1.0 was added to present value to allow writing a blink warning without having to use the lighting command. The third is the addition of a Blink_Active property which is TRUE when the lighting object is in a blink-warn state. There are also a few minor changes and the addition of a new example (#2) to show an override switch with a blink warn.
Feel free to send any comments before the telco via email or the yahoo group if you are unable to participate on Tuesday.