CURRENT ISSUE
Contests
Feature Article
|
|
Issue #204 July 2007
Pyxos Power
by Tom Cantrell
Start | LAN-In-the-Box |Down to the Wire | Variable Interest | Hook 'Em Danno |Build it and they will come | Match point | Sources and PDF
DOWN TO THE WIRE
The deterministic bandwidth and latency derives from the Pyxos FT “frame” (see Figure 3). In turn, a frame comprises timeslots, typically one for each Point. Each timeslot gives its associated Point the opportunity to send 8 bytes of data and receive 8 bytes of data.
 |
| Figure 3—The Pyxos FT protocol relies on fixed-duration timeslots for each Point grouped into a fixed-duration frame. That means the bandwidth and latency from a Points perspective remains fixed (i.e., deterministic) even as the aggregate network loading (i.e., total of all Points activity) ebbs and flows. |
This frame scheme has some obvious implications for system designers. First, the overall frame time directly depends on how many timeslots it contains, since the latter are of fixed duration. Thus, the network bandwidth and latency for an individual Point is directly and inversely related to the number of Points in the network. As you can see in Table 1, bandwidth ranges from about 5 to 70 kbps, fine for a sensor or actuator, but leave your multimedia A/V at home.
The fixed frame and timeslot scheme also dictates that when you design your application you have to decide how many Points it supports now or in the future. For instance, if you want to give the network the ability to “grow” (i.e., add Points), you’ll have to allocate spare timeslots to accommodate future additions. Another option is to give the Pilot some extra intelligence (i.e., knowledge of multiple network configurations and the ability to switch between them) with the understanding that changing the frame time changes the Points bandwidth and latency.
Repeatable timing obviously works well in scenarios where data needs to flow like clockwork. But, what about applications where Point activity is more sporadic, perhaps triggered only infrequently by an alarm condition (e.g., temperature over threshold) or user intervention (e.g., a switch)? Fortunately, the Pyxos FT chip and protocol offers ways to accommodate, notably including interrupt and polling capability. The Pyxos FT chip interrupt output with a programmable trigger condition gives Points the ability to sleep until the Pilot actually sends them something. On the other side of the coin, polling allows a Point to query for any updates that might have occurred while it was asleep or otherwise preoccupied.
Besides the data, a Pyxos FT network can be designed to ship power over the same pair of wires. The link-power scheme is specified to use a 24-V AC or DC supply from which each Point derives its local supply (e.g., 3.3 V for the Pyxos FT chip along with any other voltages the Point requires).
How far you can stretch a link-powered Pyxos FT network depends on a lot of different factors. These include the type of wire, whether the link power is 24 VAC or VDC, and the amount of power required by the different nodes. A small network of low-power devices using the DC option might have a reach of 400 m. At the other extreme, a fully loaded network of power hogs using the AC option could top out at 10 m.
The Pyxos FT documentation includes reference designs for link-powered supplies giving Points 3.3-V power budgets of 100 mA (switching) or 15 mA (linear). Since getting the wires mixed up during installation is a matter of when, not if, the fact that Pyxos FT networks are designed to be polarity insensitive (both link power and data) is a very nice touch. Thanks to that feature and the “Free Topology” aspect, “wiring mistakes” are a real-world dollars-and-cents problem that Pyxos FT virtually eliminates.
|
