Posts Tagged ‘bluetooth’

A wireless retrofit for remote monitoring

Sunday, June 8th, 2008

Cambridge Consultants has demonstrated a one-chip platform called Vena which adds wireless technology to existing health monitors for just $10 per unit.

Vena includes support for both IEEE 11073 and the Bluetooth Medical Device Profile. Security is also built-in.

What we’re talking about is the use of unlicensed wireless frequencies, at short distances, to move data from a monitor to a PC and then, if necessary, out to the Internet.

I first wrote about this in 2003 as The World of Always On, and it is personally gratifying to see it come on-stream, especially as a retrofit.

As a retrofit, wireless technology should not need separate government approvals in each application. Once a device is approved, the retrofit is the mere transference of data.

This has tremendous potential in both critical care monitoring and wellness applications.

A real-time monitor with wireless capability could detect health attack precursors and order the ambulance before the patient was aware of symptoms.

In wellness, this would enable real-time tracking of workouts, catching “non-workout” exercise in, say, getting to and from the office, and detecting non-compliance with a coaching regimen.

Separately, but not coincidentally, Cambridge hired MIT Venture Mentor Craig Carlson to head its U.S. acquisition initiative. Read more…

ZigBee vs. Bluetooth

Saturday, May 24th, 2008




ZigBee is broadly categorized as a low rate WPAN, and its closest technology is Bluetooth. A good bit of energy has been spent in analyzing whether ZigBee and Bluetooth are complementary or competing technologies, but after a quick look at the two, it can be seen that they fall a lot farther down the complementary side of the spectrum. They are two different technologies with very different areas of application and different means of designing for those applications. While ZigBee is focused on control and automation, Bluetooth is focused on connectivity between laptops, PDA’s, and the like, as well as more general cable replacement. ZigBee uses low data rate, low power consumption, and works with small packet devices; Bluetooth uses a higher data rate, higher power consumption, and works with large packet devices. ZigBee networks can support a larger number of devices and a longer range between devices than Bluetooth. Because of these differences, the technologies are not only geared toward different applications, they don’t have the capability to extend out to other applications. As an example, for its applications, Bluetooth must rely on fairly frequent battery recharging, while the whole goal of ZigBee is for a user to be able to put a couple of batteries in the devices and forget about them for months to years. In timing critical applications, ZigBee is designed to respond quickly, while Bluetooth takes much longer and could be detrimental to the application. Thus, a user could easily use both technologies as a wireless solution in a PAN to suit all types of applications within that network.

Zigbee:

+ lower production costs
+ less battery usage
+ larger node capability 255 vs 8
+ less system resources

- but less data speed ‘only’ 250 Kbps (vs 1 Mbps for bluetooth)
- Not (a lot) available
- Uses 900 Mhz frequentie (vs 2.5 Ghz for bluetooth)
- Less companys that support it
- 30 meter range (vs 10-100 meter for bluetooth)

And the biggest difference is the purpose of both technologie, bluetooth is made to replace datacables, while Zigbee is made to control and monitor activities, like temperature, light, …