AVR-Chat

I preface this question with the fact that I have very limited knowledge of
CAN bus and DeviceNet technologies (I do have a background in data
communications from both the EE and software engineering perspective).  I
have only 'skimmed' the description of CAN bus and DeviceNet on Wikipedia.
I know that there are Atmel devices such as the ATMega16M1 that implement
much of the CAN network support in hardware (skimmed the ATMega16M1
datasheet).

I understand that CAN works well for 'local area' sensor networks such as in
a automobiles, etc. but can I leverage the Atmel CAN support for a network
that is physically much larger (i.e.: one with significant propagation
delays)?

I am currently implementing a network of (hopefully) low cost network nodes
using ATMega16s connected via multi-master, half-duplex RS-485.  The network
is:

1) Outdoors
2) Length: 1,000s of feet using one pair from a CAT-5 cable (other pairs
used for other control tasks).  I anticipate breaking the net into subnets
with intelligent (buffered) 'bridge' devices if the physical layer requires
it.
3) Bus/power surge protection provided by transorbs, etc.
4) Data rate: As fast as practical to reduce message latency but I don't
anticipate needing an excessively high data rate.  For the moment let's say
on the order of 100 kbs.
5) Message Traffic: Most messages are broadcast type messages containing
status info that any node may consume to support its work, others are
addressed to specific nodes.  Some messages are more time sensitive than
others but there are also messages that are sent more or less continuously
as bus bandwidth allows.

Would it be possible/practical to use the Atmel CAN support in this
environment?

I read somewhere that CAN was used up to 400m due to timing considerations.
Can this distance be extended by altering (possibly 'non-standard') timing
parameters within the AVR hardware?

I've used CAN networking at 250Kbps on runs of up to 1000 feet with no 
problems.  Lower frequencies can tolerate longer runs.  However, if you 
can deal with very low baud rates (which are less sensitive to timing 
and impedance issues), of say 9600 and lower, you can simply use any 
USART with "9th bit" addressing mode and CAN transceivers to get very 
long runs.  Pay close attention to ground issues on long runs since you 
can build up large ground potential differences that can damage devices.

Your 100Kbps rate is pretty slow for CAN, no big deal there.  CAN 
networking is a broadcast bus, every node hears every message, each node 
typically sets filters to only listen to its own address.

One project that I worked on had a "star" CAN network with hubs that 
echoed messages between arms of the star, so your idea is fine.  You can 
also do CAN as a true buss where all nodes hang off of the same wires. 
Make sure to terminate your runs whichever way you choose to go.

The hardware CAN module can give you full CAN addressing, with the usual 
futzing about with the control registers for "free".  If you go the 
USART route you'd need to develop your own networking protocol.  With 
the extended CAN networking scheme you will be sending 13 byte packages 
with 8 bytes being the payload and the other 5 bytes being protocol 
related.  With your own USART networking scheme you have to/get to pick 
your own payload and protocol overhead.

CAN is a very flexible networking scheme, but there are details that you 
must follow for it to work properly.

DLC

Chuck Hackett wrote:
> I preface this question with the fact that I have very limited knowledge of
> CAN bus and DeviceNet technologies (I do have a background in data
> communications from both the EE and software engineering perspective).  I
> have only 'skimmed' the description of CAN bus and DeviceNet on Wikipedia.
> I know that there are Atmel devices such as the ATMega16M1 that implement
> much of the CAN network support in hardware (skimmed the ATMega16M1
> datasheet).
> 
> I understand that CAN works well for 'local area' sensor networks such as in
> a automobiles, etc. but can I leverage the Atmel CAN support for a network
> that is physically much larger (i.e.: one with significant propagation
> delays)?
> 
> I am currently implementing a network of (hopefully) low cost network nodes
> using ATMega16s connected via multi-master, half-duplex RS-485.  The network
> is:
> 
> 1) Outdoors
> 2) Length: 1,000s of feet using one pair from a CAT-5 cable (other pairs
> used for other control tasks).  I anticipate breaking the net into subnets
> with intelligent (buffered) 'bridge' devices if the physical layer requires
> it.
> 3) Bus/power surge protection provided by transorbs, etc.
> 4) Data rate: As fast as practical to reduce message latency but I don't
> anticipate needing an excessively high data rate.  For the moment let's say
> on the order of 100 kbs.
> 5) Message Traffic: Most messages are broadcast type messages containing
> status info that any node may consume to support its work, others are
> addressed to specific nodes.  Some messages are more time sensitive than
> others but there are also messages that are sent more or less continuously
> as bus bandwidth allows.
> 
> Would it be possible/practical to use the Atmel CAN support in this
> environment?
> 
> I read somewhere that CAN was used up to 400m due to timing considerations.
> Can this distance be extended by altering (possibly 'non-standard') timing
> parameters within the AVR hardware?
> 
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 

-- 
-------------------------------------------------
Dennis Clark          TTT Enterprises
www.techtoystoday.com
-------------------------------------------------

I'd think that the low speed confg would be fine.

--- In AVR-Chat@yahoogroups.com, dlc <dlc@...> wrote:

>
> I've used CAN networking at 250Kbps on runs of up to 1000 feet with no 
> problems.  Lower frequencies can tolerate longer runs.  However, if you 
> can deal with very low baud rates (which are less sensitive to timing 
> and impedance issues), of say 9600 and lower, you can simply use any 
> USART with "9th bit" addressing mode and CAN transceivers to get very 
> long runs.  Pay close attention to ground issues on long runs since you 
> can build up large ground potential differences that can damage devices.
> 
> Your 100Kbps rate is pretty slow for CAN, no big deal there.  CAN 
> networking is a broadcast bus, every node hears every message, each node 
> typically sets filters to only listen to its own address.
> 
> One project that I worked on had a "star" CAN network with hubs that 
> echoed messages between arms of the star, so your idea is fine.  You can 
> also do CAN as a true buss where all nodes hang off of the same wires. 
> Make sure to terminate your runs whichever way you choose to go.
> 
> The hardware CAN module can give you full CAN addressing, with the usual 
> futzing about with the control registers for "free".  If you go the 
> USART route you'd need to develop your own networking protocol.  With 
> the extended CAN networking scheme you will be sending 13 byte packages 
> with 8 bytes being the payload and the other 5 bytes being protocol 
> related.  With your own USART networking scheme you have to/get to pick 
> your own payload and protocol overhead.
> 
> CAN is a very flexible networking scheme, but there are details that you 
> must follow for it to work properly.
> 
> DLC
> 
> Chuck Hackett wrote:
> > I preface this question with the fact that I have very limited knowledge of
> > CAN bus and DeviceNet technologies (I do have a background in data
> > communications from both the EE and software engineering perspective).  I
> > have only 'skimmed' the description of CAN bus and DeviceNet on Wikipedia.
> > I know that there are Atmel devices such as the ATMega16M1 that implement
> > much of the CAN network support in hardware (skimmed the ATMega16M1
> > datasheet).
> > 
> > I understand that CAN works well for 'local area' sensor networks such as in
> > a automobiles, etc. but can I leverage the Atmel CAN support for a network
> > that is physically much larger (i.e.: one with significant propagation
> > delays)?
> > 
> > I am currently implementing a network of (hopefully) low cost network nodes
> > using ATMega16s connected via multi-master, half-duplex RS-485.  The network
> > is:
> > 
> > 1) Outdoors
> > 2) Length: 1,000s of feet using one pair from a CAT-5 cable (other pairs
> > used for other control tasks).  I anticipate breaking the net into subnets
> > with intelligent (buffered) 'bridge' devices if the physical layer requires
> > it.
> > 3) Bus/power surge protection provided by transorbs, etc.
> > 4) Data rate: As fast as practical to reduce message latency but I don't
> > anticipate needing an excessively high data rate.  For the moment let's say
> > on the order of 100 kbs.
> > 5) Message Traffic: Most messages are broadcast type messages containing
> > status info that any node may consume to support its work, others are
> > addressed to specific nodes.  Some messages are more time sensitive than
> > others but there are also messages that are sent more or less continuously
> > as bus bandwidth allows.
> > 
> > Would it be possible/practical to use the Atmel CAN support in this
> > environment?
> > 
> > I read somewhere that CAN was used up to 400m due to timing considerations.
> > Can this distance be extended by altering (possibly 'non-standard') timing
> > parameters within the AVR hardware?
> > 
> > 
> > 
> > 
> > 
> > ------------------------------------
> > 
> > Yahoo! Groups Links
> > 
> > 
> > 
> 
> -- 
> -------------------------------------------------
> Dennis Clark          TTT Enterprises
> www.techtoystoday.com
> -------------------------------------------------
>

Hmm... This sounds to me like a perfect application for a Zigbee
network. The modules are a bit more expensive, but since you wouldn't
have to run wires, the final cost should be roughly comparable if not
substantially less. Individual lengths can be as much as 1 mile, but
since they are designed to run as a mesh network they can cover even
much larger lengths by repeating messages from modules farther down
the line. Speeds are up to 250kbps.

Sparkfun has a good selection of the modules available at:

http://www.sparkfun.com/commerce/categories.php?c=111

To get a one mile range, look at the XBee Pro 50 or 60mW modules. If
you use one of the modules with an integrated antenna, no additional
FCC certification is required.

If you can keep your segments under 400ft each, Digikey sells a less
expensive unit from Microchip that would work nicely:

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=MRF24J40MA-I/RM-ND

On Sat, Sep 5, 2009 at 11:15 AM, Chuck Hackett<egroupscdh@up844.us> wrote:
> I preface this question with the fact that I have very limited knowledge of
> CAN bus and DeviceNet technologies (I do have a background in data
> communications from both the EE and software engineering perspective).  I
> have only 'skimmed' the description of CAN bus and DeviceNet on Wikipedia.
> I know that there are Atmel devices such as the ATMega16M1 that implement
> much of the CAN network support in hardware (skimmed the ATMega16M1
> datasheet).
>
> I understand that CAN works well for 'local area' sensor networks such as in
> a automobiles, etc. but can I leverage the Atmel CAN support for a network
> that is physically much larger (i.e.: one with significant propagation
> delays)?
>
> I am currently implementing a network of (hopefully) low cost network nodes
> using ATMega16s connected via multi-master, half-duplex RS-485.  The network
> is:
>
> 1) Outdoors
> 2) Length: 1,000s of feet using one pair from a CAT-5 cable (other pairs
> used for other control tasks).  I anticipate breaking the net into subnets
> with intelligent (buffered) 'bridge' devices if the physical layer requires
> it.
> 3) Bus/power surge protection provided by transorbs, etc.
> 4) Data rate: As fast as practical to reduce message latency but I don't
> anticipate needing an excessively high data rate.  For the moment let's say
> on the order of 100 kbs.
> 5) Message Traffic: Most messages are broadcast type messages containing
> status info that any node may consume to support its work, others are
> addressed to specific nodes.  Some messages are more time sensitive than
> others but there are also messages that are sent more or less continuously
> as bus bandwidth allows.
>
> Would it be possible/practical to use the Atmel CAN support in this
> environment?
>
> I read somewhere that CAN was used up to 400m due to timing considerations.
> Can this distance be extended by altering (possibly 'non-standard') timing
> parameters within the AVR hardware?
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Chuck Hackett wrote:
> I read somewhere that CAN was used up to 400m due to timing considerations.
> Can this distance be extended by altering (possibly 'non-standard') timing
> parameters within the AVR hardware?

Table of maximum bus length vs. speed:

http://www.can-cia.org/index.php?id=158

--

Timo

Hello guys,

I'll share with you the weekend project I am developing with Arduino 
board and AVR Studio.
This is a Robot dev. plataform. I can program the Arduino in LOGO 
language using the Cricket Logo, Logo Blocks (it's not working 100%), 
iCode, and CTI Blocos.

Regards.

This sounds cool. I look forward to hearing more about your project!

On Sun, Sep 6, 2009 at 2:17 PM, Adeilton
Oliveira<adeiltonjunior@terra.com.br> wrote:

> Hello guys,
>
> I'll share with you the weekend project I am developing with Arduino
> board and AVR Studio.
> This is a Robot dev. plataform. I can program the Arduino in LOGO
> language using the Cricket Logo, Logo Blocks (it's not working 100%),
> iCode, and CTI Blocos.
>
> Regards.
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Guys,

Here is the link

http://babuinoproject.blogspot.com/

Regards.


Adeilton Oliveira wrote:
>  
>
> Hello guys,
>
> I'll share with you the weekend project I am developing with Arduino
> board and AVR Studio.
> This is a Robot dev. plataform. I can program the Arduino in LOGO
> language using the Cricket Logo, Logo Blocks (it's not working 100%),
> iCode, and CTI Blocos.
>
> Regards.
>
> 



[Non-text portions of this message have been removed]

> -----Original Message-----
> From: stevech11
> I'd think that the low speed confg would be fine.

From what I've read so far I believe it would be fine.  

After the application is more defined I'll have a better hand on message
sizes and xmit rates are.

Of course it depends on what one defines as low speed/high speed - I
remember when I was able to move from 300 BAUD to 1,200 BAUD and thought I
was in Heaven!

> -----Original Message-----
> From: dlc

> .... However, if you
> can deal with very low baud rates (which are less sensitive to timing
> and impedance issues), of say 9600 and lower, you can simply use any
> USART with "9th bit" addressing mode and CAN transceivers to get very
> long runs.  Pay close attention to ground issues on long runs since you
> can build up large ground potential differences that can damage
> devices.

I'm thinking of going this route (using CAN transceivers) on the initial
version (ATMega16) and implementing a simplified CAN-like bus arbitration
and message protocol.  If that works fine I'll leave it that way but if I
need more speed/sophistication I can transition to full CAN later.

< ... CAN
> networking is a broadcast bus, every node hears every message, each
> node typically sets filters to only listen to its own address.

That was my plan when I was considering RS-485 multi-drop-multi-master.  90%
of the traffic is consumed by at least two, and potentially many more, other
nodes.

> ....
> With your own USART networking scheme you have to/get to pick
> your own payload and protocol overhead.

Kind of like being your own boss - you get the benefits but you also get the
headaches :-)


> -----Original Message-----
> From: Mike Payson
> 
> Hmm... This sounds to me like a perfect application for a Zigbee
> network. The modules are a bit more expensive, but since you wouldn't
> have to run wires, the final cost should be roughly comparable if not
> substantially less. ....

As with many potential solutions it has pros & cons that I have looked at.
You'd have to have more info on the project, install sites, etc.  

In a nutshell: One of my other hobbies is ride-on, live steam railroading
(see: http://whitetrout.net/Chuck/844/photos and
http://whitetrout.net/Chuck/844).  The tracks are 7.5" gauge using aluminum
rails on treated wood ties.  The application I am working on is a robust,
automatic signal system for tracks around the country.  One of the major
things the system addresses is detecting a train shunting the rails.  This
becomes challenging in very wet weather where a 900 foot long "block" can
contain ~2,700 ties and they all conduct a bit, to make it worse, a block
that long starts to take on the characteristics of a very lossy transmission
line (w/distributed R & C) and it can get difficult to detect a "shunt" out
of the noise.  Oh, yea, 1,000's of feet of aluminum rail and cable-carrying
conduit makes a great antenna and lightning magnet and the system needs to
survive a nearby lightning strike (disregard DIRECT lightning strike, these
tracks don't have a NASA budget <g>).

The "nodes" I keep referring to are located at switches (detect point
position, control a point motor, etc.), connected to "blocks" of track (~10
to maybe ~1,000 feet long) to detect trains, at signal heads to drive the
signals, etc.

I really need to get a web page up on this thing but that's yet another
project - So many projects, so little time :-(  I think that the major
factors effecting RF .vs. hardwire in my case are:

1) Power
2) Node density

All the nodes need power and they are not near local power sources.  I could
provide solar chargers but that would dramatically increase cost and many of
the nodes are in areas with dense tree cover and batteries are not an option
in most situations.  I am using a #16 pair for power distribution (48vdc) in
a conduit along the track ROW with plenty of room for a CAT-5 cable.

I am getting CAT-5 for ~$55/1000, so if, in a particular area, the
inter-node distance is long enough or node density is low enough, Zigbee
might be cost effective.  I was planning on having network segment bridges
for various reasons and Zigbee might fit in there also.  But those issues
are for large installations and are down the road (track? <vbg>) at the
moment.

There are also a couple of cases where someone using my system might only
need a couple of nodes and might want to use RF w/batteries so they can take
in the equipment when not in use (vandalism), don't have to trench, etc.  I
see nothing in my design that would preclude this.

I have checked out the links you provided, thank you.  It's always good to
keep informed about potential solutions in case project factors change.

Thanks to all for the info ...
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck

>> -----Original Message-----
>> From: Mike Payson
>>
>> Hmm... This sounds to me like a perfect application for a Zigbee
>> network. The modules are a bit more expensive, but since you wouldn't
>> have to run wires, the final cost should be roughly comparable if not
>> substantially less. ....
>
> As with many potential solutions it has pros & cons that I have looked at.
> You'd have to have more info on the project, install sites, etc.
>
> In a nutshell: One of my other hobbies is ride-on, live steam railroading
> (see: http://whitetrout.net/Chuck/844/photos and
> http://whitetrout.net/Chuck/844).  The tracks are 7.5" gauge using aluminum
> rails on treated wood ties.  The application I am working on is a robust,
> automatic signal system for tracks around the country.  One of the major
> things the system addresses is detecting a train shunting the rails.  This
> becomes challenging in very wet weather where a 900 foot long "block" can
> contain ~2,700 ties and they all conduct a bit, to make it worse, a block
> that long starts to take on the characteristics of a very lossy transmission
> line (w/distributed R & C) and it can get difficult to detect a "shunt" out
> of the noise.  Oh, yea, 1,000's of feet of aluminum rail and cable-carrying
> conduit makes a great antenna and lightning magnet and the system needs to
> survive a nearby lightning strike (disregard DIRECT lightning strike, these
> tracks don't have a NASA budget <g>).
>
> The "nodes" I keep referring to are located at switches (detect point
> position, control a point motor, etc.), connected to "blocks" of track (~10
> to maybe ~1,000 feet long) to detect trains, at signal heads to drive the
> signals, etc.
>
> I really need to get a web page up on this thing but that's yet another
> project - So many projects, so little time :-(  I think that the major
> factors effecting RF .vs. hardwire in my case are:
>
> 1) Power
> 2) Node density
>
> All the nodes need power and they are not near local power sources.  I could
> provide solar chargers but that would dramatically increase cost and many of
> the nodes are in areas with dense tree cover and batteries are not an option
> in most situations.  I am using a #16 pair for power distribution (48vdc) in
> a conduit along the track ROW with plenty of room for a CAT-5 cable.
>
> I am getting CAT-5 for ~$55/1000, so if, in a particular area, the
> inter-node distance is long enough or node density is low enough, Zigbee
> might be cost effective.  I was planning on having network segment bridges
> for various reasons and Zigbee might fit in there also.  But those issues
> are for large installations and are down the road (track? <vbg>) at the
> moment.
>
> There are also a couple of cases where someone using my system might only
> need a couple of nodes and might want to use RF w/batteries so they can take
> in the equipment when not in use (vandalism), don't have to trench, etc.  I
> see nothing in my design that would preclude this.
>
> I have checked out the links you provided, thank you.  It's always good to
> keep informed about potential solutions in case project factors change.
>
> Thanks to all for the info ...
>
> Cheers,
>
> Chuck Hackett
> "Good judgment comes from experience, experience comes from bad judgment"
> 7.5" gauge Union Pacific Northern (4-8-4) 844
> http://www.whitetrout.net/Chuck
>

I'm confused by the power issue... You say you are already providing
48vdc, so why not just step the power down for the Zigbee? Running
cable isn't quite as bad since you already have the conduit, but it
still seems that running cable would be a hassle, and the cost would
be almost identical or even cheaper.

As for the RF concerns, Zigbee is designed for use in noisy
environments, so it would likely be a good candidate. It actually
sounds like a good candidate for a white paper on Zibee technology.
:-) Might be worth contacting Digi and see if they'd help you in
exchange for writing up your experiences.

> From: Mike Payson
> ....
> 
> I'm confused by the power issue... You say you are already providing
> 48vdc, so why not just step the power down for the Zigbee? Running
> cable isn't quite as bad since you already have the conduit, but it
> still seems that running cable would be a hassle, and the cost would
> be almost identical or even cheaper.

No problem powering the Zigbees from 48v.  I'm already planning on
downconverting the power with a switcher regulator to power the nodes (the
reason for a 48vdc bus rather than ac, etc. is a whole other discussion that
I won't go into here).

I only mentioned the 48v power cable to say that there is already a conduit
to all the (current) node locations.  The point being that it is minimal
effort to pull the CAT-5 with the power cable and the only added cost is the
CAT-5 itself which was costing us ~$55 per 1,000 feet.

From Wikipedia: "Transmission range is between 10 and 75 meters (33 and 246
feet) and up to 1500 meters for zigbee pro, although it is heavily dependent
on the particular environment."

I see on the Sparkfun site that 1mw units are about $23, 2mw $26-$29, pro
$38-$45.

(what follows is of the top of my head ...)

So, assuming two nodes separated by 1,000 feet, it costs me about $28 per
node with CAT-5, and (since I have to use Pro), let's say $40 per node -
and, that's assuming that Pro can reach that far in a heavily wooded area.  

To be fair, since Zigbee can communicate in both directions (east/west on a
track for instance), let's say 5 nodes, each separated by 1,000 feet, that's
$220 for cable (4,000 feet @$55/1000) or $44/node.  For Zigbee Pro, that's
$200 (5 units @$40) or (obviously) $40 per node.  

Sounds about the same, but: I would have to test to confirm that Pro can
cover the distance in a heavily wooded area - I know cable works reliably
that far.  If a Zigbee link doesn't work someone has to diagnose if it's an
RF problem or not and then track down the source requiring somewhat special
knowledge and equipment - a cable is a comparatively easy thing to diagnose
with minimal tools, and knowledge.

Now, suppose the nodes are clustered in a smaller area (higher density), my
cable costs per node go down dramatically but the Zigbee costs can (from
above) only go down to ~$25 per node after the range is small enough for the
1 or 2 mw units.

Another factor:  I'm currently using CAT-5 because it's a "commodity" item
(LOTS of it is made and available) but I am currently only using one of the
4 pair in the cable.  If future use does not surface for the other 3 pairs,
I could go to a jacketed single twisted pair which would again lower the
cost for cable, or even, since it's in conduit, I could use single-pair,
un-jacketed cross-connect wire.

That said, I still see a use of wireless in my application, for example:
One of my users is located in a public park and they have a small number of
signal heads that, due to vandalism, must be put out when needed (let's say
two days per month) and gathered up at the end of each day.  I can see the
signal head containing a battery (recharged by just plugging the signal head
into a charging station at night), a node and Zigbee.  No need to run
data/power cable in the city park and no vandalism.  I can also envision
other cases where a network would be a mix of wired and wireless ...

Oh, one other advantage of Zigbee could be that (if self powered) it is
inherently protected from lightning, HOWEVER the node is still connected to
the rails which are still great lightning/ground voltage gradient attractor
:-)

Apologies to others not interested in such non-AVR discussions ... Now back
to our regularly scheduled AVR specific discussion ...
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck

I've been working professionally for 3 years now in IEEE 802.15.4 and have these tid-bits, and if you wish, I can elaborate....

ZigBee is not IEEE 802.15.4 and vice-versa. The comparison might be IEEE 802.3 versus IP/ethernet.

ZigBee is one of several network layer protocols used with IEEE 802.15.4. ZigBee is used normally only if you need meshing. For either on-hop networks as peer to peer or point to multipoint, ZigBee is a disadvantage versus simple source/destination addressing, as you would with, say, UDP datagrams or ethernet packets.

The range one can achieve is ordinary RF engineering... most '15.4 modules (don't even think of starting with a chip) have either 2mW or 50mW of power. In some countries, regulations prohibit more than about 10mW of radiated power. MOdules can have on-board antennas with little or no gain, or external antennas with lots of gain, regulations-permitting. 

The receiver sensitivity in these modules, marketing baloney aside, is essentially the same. It's governed by the definition of '15.4, which for the 2.4GHz version, is DSSS 250Kbps before coding and other overhead. A good number is -90dBm at the receiver input. So the range is the usual RF budget: Tx power + antenna gain - distance-dependent path loss at 2.4GHz - additional losses from clutter + antenna gaine versus receiver sensitivy. 

With 60mW modules, with 0dBi gain on one end and 5.6dBi on the other, and elevated 20ft. the line of sight range I achieved was 3/4 mile, with the far end just 4 ft. above ground. WIth (legal) higher gain antennas you can probably get line of sight, do the math- of much more than that, absent sustained interference.

The protocol is CSMA like 802.11, so it can be used in unlicensed bands.

There are perhaps 20 module vendors and 6 chip vendors. 

The most popular for casual use is Digi's XBee series 1 (non-ZigBee).

steve

--- In AVR-Chat@yahoogroups.com, "Chuck Hackett" <egroupscdh@...> wrote:

>
> > From: Mike Payson
> > ....
> > 
> > I'm confused by the power issue... You say you are already providing
> > 48vdc, so why not just step the power down for the Zigbee? Running
> > cable isn't quite as bad since you already have the conduit, but it
> > still seems that running cable would be a hassle, and the cost would
> > be almost identical or even cheaper.
> 
> No problem powering the Zigbees from 48v.  I'm already planning on
> downconverting the power with a switcher regulator to power the nodes (the
> reason for a 48vdc bus rather than ac, etc. is a whole other discussion that
> I won't go into here).
> 
> I only mentioned the 48v power cable to say that there is already a conduit
> to all the (current) node locations.  The point being that it is minimal
> effort to pull the CAT-5 with the power cable and the only added cost is the
> CAT-5 itself which was costing us ~$55 per 1,000 feet.
> 
> From Wikipedia: "Transmission range is between 10 and 75 meters (33 and 246
> feet) and up to 1500 meters for zigbee pro, although it is heavily dependent
> on the particular environment."
> 
> I see on the Sparkfun site that 1mw units are about $23, 2mw $26-$29, pro
> $38-$45.
> 
> (what follows is of the top of my head ...)
> 
> So, assuming two nodes separated by 1,000 feet, it costs me about $28 per
> node with CAT-5, and (since I have to use Pro), let's say $40 per node -
> and, that's assuming that Pro can reach that far in a heavily wooded area.  
> 
> To be fair, since Zigbee can communicate in both directions (east/west on a
> track for instance), let's say 5 nodes, each separated by 1,000 feet, that's
> $220 for cable (4,000 feet @$55/1000) or $44/node.  For Zigbee Pro, that's
> $200 (5 units @$40) or (obviously) $40 per node.  
> 
> Sounds about the same, but: I would have to test to confirm that Pro can
> cover the distance in a heavily wooded area - I know cable works reliably
> that far.  If a Zigbee link doesn't work someone has to diagnose if it's an
> RF problem or not and then track down the source requiring somewhat special
> knowledge and equipment - a cable is a comparatively easy thing to diagnose
> with minimal tools, and knowledge.
> 
> Now, suppose the nodes are clustered in a smaller area (higher density), my
> cable costs per node go down dramatically but the Zigbee costs can (from
> above) only go down to ~$25 per node after the range is small enough for the
> 1 or 2 mw units.
> 
> Another factor:  I'm currently using CAT-5 because it's a "commodity" item
> (LOTS of it is made and available) but I am currently only using one of the
> 4 pair in the cable.  If future use does not surface for the other 3 pairs,
> I could go to a jacketed single twisted pair which would again lower the
> cost for cable, or even, since it's in conduit, I could use single-pair,
> un-jacketed cross-connect wire.
> 
> That said, I still see a use of wireless in my application, for example:
> One of my users is located in a public park and they have a small number of
> signal heads that, due to vandalism, must be put out when needed (let's say
> two days per month) and gathered up at the end of each day.  I can see the
> signal head containing a battery (recharged by just plugging the signal head
> into a charging station at night), a node and Zigbee.  No need to run
> data/power cable in the city park and no vandalism.  I can also envision
> other cases where a network would be a mix of wired and wireless ...
> 
> Oh, one other advantage of Zigbee could be that (if self powered) it is
> inherently protected from lightning, HOWEVER the node is still connected to
> the rails which are still great lightning/ground voltage gradient attractor
> :-)
> 
> Apologies to others not interested in such non-AVR discussions ... Now back
> to our regularly scheduled AVR specific discussion ...
>  
> Cheers,
> 
> Chuck Hackett
> "Good judgment comes from experience, experience comes from bad judgment"
> 7.5" gauge Union Pacific Northern (4-8-4) 844
> http://www.whitetrout.net/Chuck
>

On Sep 5, 2009, at 11:15 AM, Chuck Hackett wrote:

> I preface this question with the fact that I have very limited  
> knowledge of
> CAN bus and DeviceNet technologies (I do have a background in data
> communications from both the EE and software engineering  
> perspective).  I
> have only 'skimmed' the description of CAN bus and DeviceNet on  
> Wikipedia.
> I know that there are Atmel devices such as the ATMega16M1 that  
> implement
> much of the CAN network support in hardware (skimmed the ATMega16M1
> datasheet).
>
> I understand that CAN works well for 'local area' sensor networks  
> such as in
> a automobiles, etc. but can I leverage the Atmel CAN support for a  
> network
> that is physically much larger (i.e.: one with significant propagation
> delays)?
>
CAN is also used in much larger environments (chemical plants,  
semiconductor fabs, etc.).

> I am currently implementing a network of (hopefully) low cost  
> network nodes
> using ATMega16s connected via multi-master, half-duplex RS-485.  The  
> network
> is:
>
If you're thinking about using CAN you want to also use a CAN physical  
layer (for robustness).

> 1) Outdoors
> 2) Length: 1,000s of feet using one pair from a CAT-5 cable (other  
> pairs
> used for other control tasks).  I anticipate breaking the net into  
> subnets
> with intelligent (buffered) 'bridge' devices if the physical layer  
> requires
> it.
> 3) Bus/power surge protection provided by transorbs, etc.
> 4) Data rate: As fast as practical to reduce message latency but I  
> don't
> anticipate needing an excessively high data rate.  For the moment  
> let's say
> on the order of 100 kbs.
> 5) Message Traffic: Most messages are broadcast type messages  
> containing
> status info that any node may consume to support its work, others are
> addressed to specific nodes.  Some messages are more time sensitive  
> than
> others but there are also messages that are sent more or less  
> continuously
> as bus bandwidth allows.
>
> Would it be possible/practical to use the Atmel CAN support in this
> environment?
>
Should be.

Message priority in CAN is handled by the message itself: that is, the  
actual message, taken as a number, is its own priority. So you have  
quite a bit of flexibility (though existing CAN schemes like CANopen,  
DeviceNet, etc. have their own meaning attached to various bits within  
the CAN messages).

-- 
Ned Konz
Seattle, WA
360-629-1091
http://bike-nomad.com

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Ned Konz

Sent: 17 September 2009 10:08
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] CAN Bus - usefull for long distances of outdoor
cable?

On Sep 5, 2009, at 11:15 AM, Chuck Hackett wrote:

>CAN is also used in much larger environments (chemical plants, 
>semiconductor fabs, etc.).



Is even recognised now for aviation, such is the robustness of the standard.


>If you're thinking about using CAN you want to also use a CAN physical 
>layer (for robustness).



I would opt to use on the many CAN physical devices out there. If the AVR
you use does not have it built in, then look at the Microchip MCP2510 as
this interfaces easily to the AVR using SPI bus.


>Should be.
>
>Message priority in CAN is handled by the message itself: that is, the 
>actual message, taken as a number, is its own priority. So you have 
>quite a bit of flexibility (though existing CAN schemes like CANopen, 
>DeviceNet, etc. have their own meaning attached to various bits within 
>the CAN messages).



Once you have used CAN for control you won't go back so easily to the likes
of RS485 and its inherent master/slave operation. With the mult-master in
the CAN bus you can concentrate on sending or receiving data instead of
working out who is going to play master. Adding new nodes to send additional
data does not require an update to any other device unless it is going to
act on that data.

In fact, I used to have a weather station and a boiler control system
running in my old house all on the same CAN bus network. I built the weather
station first then add the boiler control. It basically operated independent
of the weather station but it used the data from the outside temp sensor to
control the heating level. I didn't have to make any changes to the weather
station nodes and simply added the boiler nodes into the network. They then
sent data on the bus which the required boiler nodes would receive and
process.


-- 
Ned Konz
Seattle, WA
360-629-1091
http://bike-nomad.com



[Non-text portions of this message have been removed]

Hello,

The blog has been updated with some new posts a videos, including the 
first application of Babuino Project, an obstacle avoidance vehicle.
Here is the link:

http://babuinoproject.blogspot.com/

Please feel free to make your comments!

Adeilton Oliveira



Adeilton Oliveira wrote:
> Guys,
>
> Here is the link
>
> http://babuinoproject.blogspot.com/
>
> Regards.
>
>
> Adeilton Oliveira wrote:
>>  
>>
>> Hello guys,
>>
>> I'll share with you the weekend project I am developing with Arduino
>> board and AVR Studio.
>> This is a Robot dev. plataform. I can program the Arduino in LOGO
>> language using the Cricket Logo, Logo Blocks (it's not working 100%),
>> iCode, and CTI Blocos.
>>
>> Regards.
>>
>> 
>



[Non-text portions of this message have been removed]

All,

We finally released a test version of Babuino software for you to test 
and give us your feedback.
We have new posts in our blog (http://babuinoproject.blogspot.com) 
including a Tutorial on how to upload the .hex file to Arduino.
The .hex file is available in our discussion group in Yahoo so it is 
readily available for you.
Here is the link:

http://tech.groups.yahoo.com/group/babuinoproject/

Please feel free to join and share with us your experience with our 
platform and programming Babuino in LOGO.

Hope you like!!


Regards,

Adeilton Oliveira



Adeilton Oliveira wrote:
>  
>
> Hello,
>
> The blog has been updated with some new posts a videos, including the
> first application of Babuino Project, an obstacle avoidance vehicle.
> Here is the link:
>
> http://babuinoproject.blogspot.com/ <http://babuinoproject.blogspot.com/>
>
> Please feel free to make your comments!
>
> Adeilton Oliveira
>
> Adeilton Oliveira wrote:
> > Guys,
> >
> > Here is the link
> >
> > http://babuinoproject.blogspot.com/ 
> <http://babuinoproject.blogspot.com/>
> >
> > Regards.
> >
> >
> > Adeilton Oliveira wrote:
> >>
> >>
> >> Hello guys,
> >>
> >> I'll share with you the weekend project I am developing with Arduino
> >> board and AVR Studio.
> >> This is a Robot dev. plataform. I can program the Arduino in LOGO
> >> language using the Cricket Logo, Logo Blocks (it's not working 100%),
> >> iCode, and CTI Blocos.
> >>
> >> Regards.
> >>
> >>
> >
>
> [Non-text portions of this message have been removed]
>
> 



[Non-text portions of this message have been removed]

Hello guys,

A long time ago I posted a message about the project I was working on. 
The project has grown and I'd like to share with you the latest status.
Now there are some people working with me in the software development 
and testing, and this week I received the first pics of Programming 
classes for kids using Babuino.

Take a look at them in http://babuinoproject.blogspot.com/ 
<http://babuinoproject.blogspot.com/>

Thanks!




Adeilton Oliveira wrote:
>
> Hello,
>
> The blog has been updated with some new posts a videos, including the
> first application of Babuino Project, an obstacle avoidance vehicle.
> Here is the link:
>
> http://babuinoproject.blogspot.com/ <http://babuinoproject.blogspot.com/>
>
> Please feel free to make your comments!
>
> Adeilton Oliveira
>
> Adeilton Oliveira wrote:
> > Guys,
> >
> > Here is the link
> >
> > http://babuinoproject.blogspot.com/ 
> <http://babuinoproject.blogspot.com/>
> >
> > Regards.
> >
> >
> > Adeilton Oliveira wrote:
> >>
> >>
> >> Hello guys,
> >>
> >> I'll share with you the weekend project I am developing with Arduino
> >> board and AVR Studio.
> >> This is a Robot dev. plataform. I can program the Arduino in LOGO
> >> language using the Cricket Logo, Logo Blocks (it's not working 100%),
> >> iCode, and CTI Blocos.
> >>
> >> Regards.
> >>
> >>
> >
>
> [Non-text portions of this message have been removed]
>
> 



[Non-text portions of this message have been removed]