Evolving wireless technology
During my post-RBI hiatus, I continued to pay attention to the areas I traditionally follow, at least to some extent. This included attending the Sensors Expo last month. Generally I go through that show pretty quickly since much of the equipment displayed is down at the component level and aimed more at OEMs than end users. Nonetheless, one of the items I reported on was from a Cores Electronic, a company that uses a Web enabled technology which allows a user to access data from a wireless device anywhere in the world via the Internet. That in itself is interesting on its own merits, but it got me into a conversation with Marius Ghercioiu, president of Cores Electronic. He had read an article I wrote in 2007 on the topic of wireless instrumentation and plant-level networks. He was particularly taken by comments on the three mutually-exclusive goals of wireless technology: bandwidth, determinism, and power consumption, and that no system can excel all three.
Ghercioiu reported that his approach has conquered that, or at least made the triangle smaller. As he puts it:
“The three capabilities can be made mutually non-exclusive if you redefine bandwidth from the implied vertical data flow between a tag/measurement node and the application running on PC or server, to a horizontal data flow between a federation of tags/measurement nodes to a cloud-based application, as graphically illustrated in the attached picture.
Battery life is dictated by the frequency and length of tag/measurement node radio transmissions (and not by length of measurement/processing period), as shown by the following power measurement study done on a Tag4M WiFi tag:
1. Boot sequence takes 10-12 ms and has a mean current consumption of 10 mA;
2. Transmission period, where the tag may transmit up to six times inside of a communication period. Transmission time takes 5-10 ms and has a peak current consumption of 210 mA, which is also the wake-up period pick current consumption level;
3. Measurement period takes 0.5-5 ms and has a mean current consumption of 20 mA;
4. Receiving period, when the tag waits for AP acknowledgement, which takes 0-80 ms and has a mean current consumption of 30 mA; and
5. Sleep mode, where the tag current consumption is 3 µA.
The conclusion on battery power is that by reducing the frequency and length of tag/measurement node transmission periods, we preserve battery power. This does not conflict with determinism or with horizontal bandwidth.
Determinism can be controlled by moving those application algorithms that require minimized latency in tag/measurement node firmware. This does not conflict with preserving battery power or with horizontal bandwidth.
Bandwidth defines the amount of information per unit of time that comes from the tag/measurement node to the application software. Instead of requiring one tag/measurement node to send millions of data points to the server, as in data acquisition devices that scan multiple channels at MHz frequency in PC-based setups, we require the cloud-based application to ‘scan’ millions of small battery powered tags/measurement nodes.
The Cloud Instrument technology may very well change the way we do measurements in the future.”
This approach may not be suitable for every application, but it illustrates the point that wireless technology is improving. I suspect that going forward the three points will continue to be mutually exclusive, however they may get so close together that the differences won’t really matter. Still, I’m sure battery life can never be too long for some users.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.