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
LAN-IN-THE-BOX
Echelon is best known for their LonWorks distributed processing and control scheme, which has found success over the years in large-scale building automation (e.g., lighting, security, and HVAC) and metering applications. However, while LonWorks may work for a skyscraper, it is overkill for smaller scale “in-room” or “in-box” applications. Enter Pyxos FT, designed to handle “last meter” tasks at the end of the wire. To that end, low-cost, low-power, and real-time capabilities are key requirements.
Here are the basics. A Pyxos FT network supports up to 32 nodes over tens to hundreds of meters of low-cost cable (e.g., Cat 5 twisted pair). The exact distance depends on a variety of factors, such as the type of wire, the network layout, and whether it just carries data or provides link power to attached devices as well.
Speaking of network layout, the “FT” in Pyxos FT stands for “free topology.” Logically, the network can be considered a bus in the sense that all nodes see all traffic. But, just because it’s logically a bus doesn’t mean it has to be physically wired as such.
The range of wiring options can be understood as follows. Imagine you’re able to connect the probes of a VOM to different nodes, in which case the wiring rule is simply as follows. Any configuration in which every node has electrical continuity with every other is allowed.
Obviously, a true physical bus (i.e., single-wire) fills that bill. But so does a star configuration. And so does a bus of stars, or a star of buses. Most notably, even a loop configuration (something most networking schemes frown on) is allowed. The cool thing about a loop is that it can be broken and the network will still work because a broken loop devolves to a bus.
Network management is centralized in a single Pyxos FT “Pilot” serving the individual nodes, which are known as “Points.” The decision to use a centralized approach has a number of ramifications.
On the downside, centralized control means there is a single point of failure. If the Pilot dies, so does the network, and nodes will have to fall back to a limp-home mode that can deal with the loss of connectivity.
That’s a significant price to pay, but one that delivers significant benefits as well. Perhaps most important, centralized control allows a degree of determinism that’s difficult to obtain with distributed peer-to-peer schemes. The Pilot schedules network activity so that each Point receives a certain amount of bandwidth with a dependable schedule.
Of course, no networking scheme can “guarantee” data delivery in all cases (e.g., wire short/open), so you the designer always have to make a provision to fail gracefully. But under normal conditions, Points can be assured they’ll get the bandwidth and precise timing they need when they need it.
Another benefit of the Pilot & Point scheme is that the asymmetry puts most of the complexity in the Pilot, making life easier (and cheaper) for the more numerous Points. Indeed, a so-called “unhosted” Point need consist of little more than a Pyxos FT chip by itself (see Figure 2).
|
a)
b)
|
| Figure 2a—In Hosted Point mode, the pins on the Pyxos FT chip implement an SPI for connection to the host MCU. b—In Unhosted Point mode, the pins revert to direct digital I/O functionality (four I/Os and one input). |
|
