Potential customers looking at the first line your product brochure will mentally be asking: Am I interested? And you literally have less than one second in which to convince them to read the next line or else lose them.  Here are the simple steps to writing a killer product brochure:

Your first step in writing the killer product brochure is to forget everything you know about your product.  I’m serious.  Remember, the product brochure isn’t for your product — it’s for your customer.  You need to clear your mind for the next step.

Next: Put yourself in the customers’ shoes. Unless you can empathize with what they’re thinking and what they need, you won’t be able to connect with them.  News flash: frequent conversations with customers has been shown to be effective way to understand what they’re thinking about.

Thus mentally prepared, you can write your brochure.  The rule is simple: every sentence or image in the brochure needs to answer the question the customer will be asking, consciously or otherwise: Am I still interested? If the answer is yes, you’ve earned the attention of the customer long enough for the customer to read the next sentence. The exposition unrolls like this:

1. Am I your customer? The brochure should tell me at first glance whether or not this product is for me.  If not, no harm done — I’ll just stop reading.  Otherwise, I’ll read the next line…
2. Are you going to address problem of mine that needs to be solved? You need to convince me that you’re offering me something that I need.
3. What results will I see?  How will this product benefit me? If I think the expected outcome is worthwhile, I’ll keep on reading.

Notice that at this point, we haven’t said anything about what our product really is, but we have earned the customer’s interest to read this far.  Now (and only now) we can start to talk about the product.

4. Convince me that it works. This can be a picture of results or a short description makes me go “aha — I see what this is doing”.
5. How do I learn more? If I’ve read this far, I really am interested. Give me something to chew on. On a paper brochure, provide specifications on the back side. On a web page, offer a link to more detailed information.
6. Okay — what do I do next? A surprising number of product brochures and web pages forget this important step: what next? There should always be a call to action in the form of “call this number” or “click here”.

Now I just need to get around to writing our brochures.

As always, comments are welcome.

cellphone on a CD coaster

Does your cell phone inject nasty buzzing noises into your speakers while you’re trying to work? I came up with a simple hack: put a CD or DVD on your desk, then lay your cell phone on top of it. It appears that the dielectric in the disc is sufficient to mop up extra EMI from the phone, but not enough to stop it from receiving calls and e-mails.

This works with my iPhone — your mileage may vary.

Please post replies at http://blog.nbt-ventures.com/2009/08/12/taming-the-buzzing-cell-phone/ as to whether or not this works for you!

| | | | | |

On Twitter, I did a search for “iPhone line” and was rewarded with many tweets from people standing in line waiting for the new iPhone, reporting on lines of people waiting for the new iPhone, or (often) deriding people who even contemplated getting an iPhone.  I gathered 380 tweets, extracted all the lines that read “nn seconds ago from client_name” and tallied them by client_name.  Results after the jump:

93    web
69    TweetDeck
66    Tweetie
26    TwitterFon
21    txt
17    Twitterrific
16    twitterfeed
9    twhirl
7    mobile web
7    TwitterFox
7    HootSuite
5    twidroid
4    TwitterBerry
4    TwitPic
4    Flickr
3    Twittelator
3    Seesmic Desktop
3    Nambu
2    vlingo
2    digsby
2    UberTwitter
2    Twitterena
2    TwitterMail
2    TinyTwitter
2    Adium
1    Ping.fm
1    Movatter
1    Godark

Of course, not all of the tweets originated from iPhone clients, but it’s clear that TweetDeck, Tweetie and TwitterFon lead the pack.

Question: Is there a dark horse — one that deserves more recognition than it’s getting?

1. Who are you customers?  (or, how do you know whether or not someone is your customer?)
2. What products/services do you sell?
3. Why does the customer buy your product/service rather than making/doing it themselves or buying it from someone else?
4. How does your business generate a positive cash flow?
5. How does your business generate value beyond revenue from sales?

So, gentle reader: what essential question would you add to this list?

My reasoning: the US demand for residential and commercial energy over the next 23 years is predicted to increase by 18% (see http://www.eia.doe.gov/oiaf/aeo/excel/figure36_data.xls) — excluding industrial and transportation sectors.

If we want the additional power generated by renewable sources (and who doesn’t?) this demand must be met by increasing wind and solar power generation capacity.

But http://www.eia.doe.gov/oiaf/aeo/execsummary.html says

…the [predicted] share of electricity sales coming from nonhydroelectric renewables grows from 3 percent in 2007 to 9 percent in 2030…

That’s a 6% increase, which is far short of the 18% predicted increase in demand.

The basic problem is that renewable energy sources — specifically wind and solar — can’t currently be deployed at a rate that keeps up with increased demand.  And unless we start do something differently, we will need to build yet more non-renewable sources of energy.

But I believe wholeheartedly that we can do something differently: we can give better feedback to energy consumers to help eliminate the most egregious sources of waste.  Properly done on a national scale, this will let us hold energy demand constant for a few years, buy time for solar and wind technologies to mature, and obviate the need to build more non-renewable generation plants.

Network Topologies

The topology of a network describes how individual nodes in the network connect to one another. (Note: the word “topology” derives from a branch of mathematics and from map making. If the word seems alien to you, you can simply substitute the word “layout” whenever you see it.)

The three most common topologies—point to point, star and mesh—are shown in the figure above. For now, assume that all nodes support bidirectional communication—they can both send and receive messages—but we will discuss unidirectional communication and its implications below.

Point-to-point Networks

A network that uses a point-to-point topology, or more succinctly, a point-to-point network, consists of two nodes. This is the simplest arrangement that can still be called a network. Node A can send messages to node B, and node B can send messages to node A.

Wireless point-to-point networks are often used for simple remote monitoring applications, such as collecting data from a single seismic sensor. In addition, a number of companies sell “wireless bridges” for wired networks, such as this wireless Ethernet bridge or 4-20 mA current loop bridge for industrial applications.

Beyond simple wire replacement, a simple bridge is useful in hazardous environments where running a wire is difficult or dangerous: in power substations, a single pair of wires can develop dangerously large voltage potentials. In these environments, a wireless link sidesteps all the problems associated with a wired connection.

Star Networks

Anyone who has worked with a WiFi is already familiar with a star topology: terminal nodes (such as the WiFi adapter in your laptop) communicate directly to a central control node (e.g. the Access Point in a WiFi network). A terminal node cannot communicate directly with another terminal node (in the star topology picture above, node B cannot communicate directly with node C) but it can send a message through the central node to be relayed.

Other examples of star networks are cell telephones (the towers are the central nodes, the handsets are the terminal nodes), and any centrally broadcast signal such as FM radio or television.

A network with star topology has the advantage of simplicity: all of the intelligence of the network can reside in the central node, which simplifies the design and operation of the terminal nodes.

On the other hand, this leads to a potential single point of failure—the entire network stops if the central node goes down for any reason.

And in some environments, getting sufficient RF coverage from the central node can be challenging: a friend of mine once said “It’s like trying to illuminate an entire supermarket from one really bright bulb hanging in the middle of the store. No matter how bright you make the bulb, you’ll still get shadows.” (Note: if you were that friend, please send me a note so I can give you proper credit!! — rdp)

For Computer Networks, usually there’s an easy fix when you find yourself in a radio shadow: simply move closer to the access point. But in Device Networks, it’s not so easy if the wireless node is attached to a two ton tank: it may be impractical to relocate the radios. This is one place where Mesh Networks can really help.

Mesh Networks

In a mesh network, nodes serve as “mini-routers” and can relay messages on behalf of their neighbors. This means that two nodes don’t need to have a direct radio link in order to communicate — all that is required is a set of “hops” to connect from one node to the next. In the mesh network figure above, node B cannot communicate directly to node D, but it can send a message to node C that will in turn re-transmit the message to node D.

Strictly speaking, a Mesh Network doesn’t require a central point of control. In fact, many network protocols such as ZigBee assign special powers to a “coordinator” node, but that is not part of the definition of a mesh network.

A mesh network is called self-organizing and self-healing if it can establish and maintain routing information among nodes without human intervention even as nodes come and go or the physical environment changes. Since Device Networks by definition need to operate without human intervention, nearly all mesh networking algorithms designed for Device Networks are both self-organizing and self-healing.

Simplex, Half Duplex, Full Duplex

Above, we showed examples of bi-directional networks, in which each node can transmit as well as receive. There are a few examples of uni-directional networks, so this is a good time to introduce the terms simplex, half duplex and full duplex.

• a simplex channel sends data in one direction only. A television broadcast channel is an example of a simplex channel: the transmission tower always transmits and never receives.
• a half-duplex channel sends data in both directions, but only one direction at a time. A CB radio or a walkie-talkie is an example of a half-duplex channel: once you push the microphone button to talk, you can no longer hear what is being transmitted on the channel. Most wireless LAN implementations are half-duplex: the WiFi adaptor in your laptop waits in receive mode until the access point gives it permission to transmit, it switches into transmit mode long enough to send a packet of data, then reverts to receive mode.
• a full-duplex channel can send data in both directions at the same time. In fact, many full-duplex channels are implemented as pair of simplex channels: one for transmitting and one for receiving. Your cell phone communicates to the cell tower on one frequency channel while the tower simultaneously communicates with your phone on another frequency channel.

Some wireless sensor networks are built using simplex channels with uni-directional communication: data flows from a single sensor (in a point-to-point network) or from multiple sensors (in a star network) to a collection point. Since only sensor data is being collected, there is no need to communicate back to the sensor.

One does not commonly find a mesh network built using simplex communication links: nodes need to be able to transmit and receive in order to relay messages for their neighbors. (Strictly speaking, you could build a multi-hop mesh network using all simplex channels arranged in a directed graph, but I don’t know of any such implementations.)

Sensor Network != Mesh Network

One caveat: many people use the terms “wireless sensor network” and “mesh network” as if they are interchangeable. It’s important to keep in mind that a “sensor network” is an application, while “mesh” is an implementation detail. While it is true that a mesh network is often the architecture of choice for a wireless sensor networks, there have been many successful implementations that use point-to-point or star topologies.

This is what got us so excited when we first started researching Device Networking: if you build devices that use silicon radios to form networks (and not just point-to-point connections), both Moore’s Law and Metcalfe’s Law come into play. We knew back then that the silicon radios—expensive at the time—would become cheaper. And we knew that building on top of standards—in our case, ZigBee and IEEE 802.15.4—would promote large-scale adoption predicted by Metcalfe’s Law.

In early 2003, we held up “networked streetlamps” as a slightly futuristic example of Device Networking: a tiny wireless mesh network node embedded in each streetlamp within a city would control and monitor that streetlamp. It could report on when a lamp is burned out (a threat to safety) or stuck on during the day (a waste of energy). But more than that, the wireless devices would blanket the city with a dependable wireless mesh network to be used by municipal and consumer services: utility meter reading; tracking buses and delivering content to bus tracking; monitoring traffic flow; locating available parking spaces.

Skeptics snickered at us: radio modules were too expensive, wireless communication was unreliable, and providing a wireless service using streetlamps as a backhaul was clearly just another of those weird Media Lab pie-in-the-sky projects.

Since then, however, Moore’s Law and Metcalfe’s Law have worked their magic, and today Sunrise Technologies is installing Ember Corporation’s ZigBee radios into streetlamps to create a municipal backhaul—the system has already been deployed in a pilot program in Taunton, MA.

So it’s not a matter of if Device Networking will become prevalent, it’s only a matter of when. As MIT professor, advisor and friend Andy Lippman says “We’re never wrong, we’re just sometimes ahead of our time.” Good words to live by.

In early 1966, Stewart Brand was musing on a point made by Buckminster Fuller: “People act as if the earth is flat, when in reality it is spherical and extremely finite, and until we learn to treat it as a finite thing, we will never get civilization right.” NASA had been putting people in orbit since 1962, yet had not published any pictures of the earth from taken from space. So Brand started a viral campaign, distributing buttons and posters that demanded “Why haven’t we seen a photograph of the whole earth yet?”

His efforts bore fruit. Reports of his campaign was picked up by major newspapers, and in 1968 the Apollo 8 flight gave us the first photographs of the whole earth as seen from space—one of the most famous pictures is shown here.

In Brand’s words:

Those riveting Earth photos reframed everything. For the first time humanity saw itself from outside. The visible features from space were living blue ocean, living green–brown continents, dazzling polar ice and a busy atmosphere, all set like a delicate jewel in vast immensities of hard–vacuum space. Humanity’s habitat looked tiny, fragile and rare. Suddenly humans had a planet to tend to. The photograph of the whole earth from space helped to generate a lot of behavior—the ecology movement, the sense of global politics, the rise of the global economy, and so on.

And yet.

Out of sight, out of mind

As much as I revere Brand’s work, we really haven’t seen the whole earth yet. We are told that the hole in the ozone layer has been getting progressively worse since it was first reported in 1984. Carbon dioxide levels in the atmosphere have been on the rise since 1759. We know these things are happening, but since we can’t “see” them on a daily basis we haven’t done enough to take appropriate action.

It’s human nature: we tend to change our behavior only when we can see the consequences of our actions.

There’s hope. One of the powerful facets of Device Networks is that they let us observe things in our physical world that have been previously invisible. Southern California Edison ran a simple pilot program that used networked Energy Orbs from Ambient Devices that glowed blue when power was inexpensive, green during peak hours, and red during “super peak” periods. The result? Customers cut back on their peak period usage by 40%.

The broad view

Device Networks can act as a “macroscope” over a large geographical area to observe phenomena that would otherwise go undetected. We can construct network sensors that monitor radon levels in thousands of homes in real time and analyze that data to predict earthquakes. We can build a giant distributed weather station by linking rooftop solar panels into the Embedded Internet and deduce the wind speed and direction as clouds’ shadows progressively occlude one panel and the next.

The long view

And sometimes “slow time” is just as important as “real time”. The Embedded Internet’s ability to record and analyze historical data lets us observe changes that occur too slowly for us to notice otherwise. Long term recording and analysis of global temperature data and CO2 levels can tell us much about our impact on our very finite planet. It’s not a coincidence that Stewart Brand was one of the creators of the Long Now Foundation.

By making manifest that which was previously invisible, the Embedded Internet can help us become better stewards of our small and precious planet.

---

copyright © 2008 nbt ventures, all rights reserved

---

share the love: | | | | | |

Device Networks are communication networks that link unattended physical objects to each other and to other networks and allow us to sense, control, identify or locate those objects.

It is easier to discuss Device Networks after describing two other familiar networks: Computer Networks and Voice Networks.

Computer Networks

Nearly everyone understands what we mean by computer networks — these are the high-speed digital networks that link our laptops, desktop computers and file servers. Computer Networks carry the massive torrents of data that serve us our e-mail, web pages, streaming audio and YouTube posts of chihuahuas on skateboards. In computer networks, TCP/IP and UDP are the dominant communication protocols and speed is the most important figure of merit: faster is always better.

Voice Networks

We are all equally familiar with voice networks, which link everything that starts or ends at a telephone handset. Back in the 20th century, most voice networks were made of copper wires carrying circuit-switched analog signals, but those have largely been replaced by packet-switched digital signals carried over wires and fiber optic cables or, increasingly, carried over wireless cellular networks.

We are seeing a wonderful blurring of voice networks and computer networks: Office buildings are now outfitted with telephone systems that use VOIP (Voice Over Internet Protocol), in which voice traffic is stuffed into TCP/IP packets and shunted over standard computer networks. And content originating from file servers — such as web pages, digital music, satellite radio — is being delivered directly to our mobile handsets The dominant figure of merit for voice networks is availability — you want your handset to be connected no matter where you are.

Device Networks

Which brings us to our definition of device networks: Device Networks are communication networks that link unattended physical objects to each other and to other networks, allowing us to sense, control, identify or locate those objects. Device networks are often wireless, but there are many examples of wired device networks.

Device networks have gone by many names including: Wireless Sensor Networks; Active RFID; Machine-to-Machine (M2M); the “X-Internet”; Real-Time Location Systems (RTLS); Supervisory Control And Data Acquisition (SCADA); Real-Time Process Control and a host of others. The label of choice depends upon the application or upon market researcher discussing it.

Device Networks normally have neither the high-bandwidth requirements of Computer Networks nor the low-latency requirements of Voice Networks. But all Device Networks, regardless of application or underlying technology, must be unimpeachably autonomous and able to function dependably under a broad range of conditions without human intervention. Device Networks must either never break, or if they do break, they must have the means to repair themselves.

---

copyright © 2008 nbt ventures, all rights reserved

---

share the love: | | | | | | | | |