AVR-Chat

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
>
>
>
>