Ok, well, I hope the end result is that we have an initial implementation from TS supporting a couple of different chips, and some software contributed from users. I would think you would want groups of zigbee networks controlled by something like a TS-7400 and attached to a wired network. You would not want a whole factory based on zigbee for instance.
On the power usage, they define zigbee end device, zigbee router, and zigbee coordinator. Only the zigbee end devices (which take no part in routing) can be extremely low power, but they said they could last years (2 AA batteries) with a polling frequency in the range of 30 seconds. A watch could be a zigbee end device only, and would have a polling rate of every 24 hours maybe. The result is a star/mesh combination network.
I will post the links again to the part 1 and part 2 tutorial on Circuit Cellar for those interested.
http://www.circuitcellar.com/library/print/0205/Cross175/index.htm
http://www.circuitcellar.com/library/print/0305/Cross176/5.htm
I am wondering if we need another protocol above zigbee for transfering registers with real-time values. Modbus over zigbee???
Don.
On 10/31/06, Pat Farrell <> wrote:
Again, we are moving out of the ts-7000 charter, but ZigBee and TS-7400s
seem like a good idea, so I'll press on.
Don W. Carr wrote:
>> OK, please enlighten me... I was under the impression that zigbee and
>> 802.15.4 were the same.
>> Is zigbee just a protocol?
>>
>> What functionality do I get with just the radio part?
>> In particular, I am looking for a mesh and relay type of self-healing
>> network.
> 802.15.4 is just the MAC and physical layer. Zigbee adds network and
> application layers, turning it into an ad-hoc self healing mesh network.
Correct. IEEE 802.15.4 is the standard that ZigBee is built on top of.
So 802.15.4 is necessary but not sufficient.
ZigBee is much like TCP/IP, a complete stack to build an application
over. IEEE 802.15.4 is more like Ethernet, you need TCP/IP over it, and
then telnet, ssh, ftp, email, http, etc. on top of that.
>From what I can see ZigBee is a standard in search of applications.
There is no interoperability between products. ZigBee offers
certification of "profiles" which are application level specifications,
and could in theory work across vendors. I have only heard of one
profile, and that just controls light switches, sort of like X10.
For now, I don't see any way to attempt to use chips and ZigBee stacks
from various vendors.
> As I understand, the new standard that Nokia is proposing to replace
> blue tooth, which WILL work with watch type devices that have tiny
> batteries, is based on 802.15.4 (correct me if I am wrong), but does not
> use zigbee. Sooner or later, we will be able to download our Google
> calender to our watch and have it beep for apointments.
Right, Nokia has built to the same IEEE standard, but all the upper
layers are different. There is a similar protocol called ANT.
> 802.15.4 end devices should be able to go years on two AA bateries
> (acording to what I have read).
I'm pretty sure you can go a year or so on two AA batteries now, if your
duty cycle is low enough. But all the chips use 50 to 100 milliamps when
in use, and most take 50 to 100 milliseconds to find a "controller" and
transfer data. I don't see the radios dropping much below 30 milliamps
even after optimization, RF just takes power.
The problem with watch-type batteries (CR2032, etc.) is that they all
only support one or two hundred nanoamps of continuous draw. So you have
to be very smart about power management.
A reliable mesh is possible with ZigBee, altho it is often part of
higher level stacks offered by the vendors, such as Ember's EmberNet.
Using a mesh significantly increases power requirements. I don't think
that a mesh of watches with watch batteries is possible with current
technologies.
--
Pat Farrell pfarrell%40bioinformatx.com
www.bioinformatx.com
-- Dr. Don W. Carr J. G. Montenegro 2258 Guadalajara, Mexico +52-333-630-0704 +52-333-836-4500 ext 2930
__._,_.___
![]()
SPONSORED LINKS
__,_._,___
|