Minimal BOM for bidirectional RF point-to-multipoint RF link?

Hi group. Would appreciate some views on this. Kindly bear with me, I
have tried to provide enough information and clarity to be useful:

Problem statement:
Need to develop a bidirectional point to multi point wireless link
(meaning many sensors and one aggregation point) for purposes of
industrial data collection. BOM needs to be as low as possible.

Requirements:
- One base station interacts with few sensors (sensors may come and
go)
- Medium range (up to 30 meters or so)
- ISM band (I prefer 433MHz due to environment but 2.4GHz can do)
- Low data rate requirements (and small amounts of data)
- Secure (3DES) - I realize this is not a function of the RF link per-
se but it is a requirement
- Can use proprietary protocol etc. (i.e. does not have to be
standards based)

Possible technologies:
- Non standards based link (using "plain vanilla" good old RF)
- Bluetooth
- Wifi (i.e. 802.11)
- Zigbee
- ??

Question:
Basically the question is framed around two issues: price of required
components and NRE to develop. Regarding components, the two main
components are a radio chip and a microcontroller  to drive it (and
also run the application logic of course). If possible I would like
both to be under $10 combined (at volume of thousands or more).
So, what choice will generate a minimal BOM while satisfying the above
requirements, and of course striking a good trade off between minimal
BOM and lower NRE. I do realize that, for example, in the case of a
standards-based solution (i.e. Bluetooth, WiFi, Zigbee) much of the
requirements (and work) is taken care of (i.e. mode building blocks
exist, both in silicon and code) where as in the "plain vanilla"
approach we would have to write a protocol stack, take care of perhaps
frequency hopping, encryption, etc etc.


Thanks

On Mar 21, 1:11 pm, "ElderUberGeek" <aribl...@gmail.com> wrote:


> Possible technologies:
> - Non standards based link (using "plain vanilla" good old RF)

IMHO this is your first and best option, particularly if your volumes
are going to be quite high. While I'm probably biased, since I do this
all day at work <g>, I'd say it's a rather simple matter to develop
such a link. You could develop the software using a COTS 433MHz tx/rx
pair [module], and then migrate to a custom circuit once you've licked
the bugs and your volumes justify it.

Using any of the standards you mentioned involves pulling in a lot of
interoperability junk you just don't need. With a proprietary physical
layer you can dimension the circuit to fit your needs, rather than
having your microcontroller, transceiver, PA, LNA, antenna, etc. all
driven by a third-party standard.

Note that it is quasi-useless to ask a question about "what's the best
RF solution" if you do not specify the target [geographic/political]
market.

On Mar 21, 10:23 pm, "larwe" <zwsdot...@gmail.com> wrote:
> On Mar 21, 1:11 pm, "ElderUberGeek" <aribl...@gmail.com> wrote:
>
> > Possible technologies:
> > - Non standards based link (using "plain vanilla" good old RF)
>
> IMHO this is your first and best option, particularly if your volumes
> are going to be quite high. While I'm probably biased, since I do this
> all day at work <g>, I'd say it's a rather simple matter to develop
> such a link. You could develop the software using a COTS 433MHz tx/rx
> pair [module], and then migrate to a custom circuit once you've licked
> the bugs and your volumes justify it.
>
> Using any of the standards you mentioned involves pulling in a lot of
> interoperability junk you just don't need. With a proprietary physical
> layer you can dimension the circuit to fit your needs, rather than
> having your microcontroller, transceiver, PA, LNA, antenna, etc. all
> driven by a third-party standard.
>
> Note that it is quasi-useless to ask a question about "what's the best
> RF solution" if you do not specify the target [geographic/political]
> market.

Thanks Iarwe, I tend to agree that this would be the most economical
solution. But I think, it would require the most work to architect and
build (speaking from the position of someone who does not do it all
day...).
Could you point me to some resources on how to architect such a
solution? Mainly what are the main firmware blocks (encoding/decoding,
protocol stack, encryption, and...??), and how do you implement
multiple nodes talking to a single point bidirectionally? (frequency
wise). - (Sorry this is new territory for me!)

On Mar 21, 2:42 pm, "ElderUberGeek" <aribl...@gmail.com> wrote:

> solution? Mainly what are the main firmware blocks (encoding/decoding,
> protocol stack, encryption, and...??), and how do you implement
> multiple nodes talking to a single point bidirectionally? (frequency

This project is not specified in enough detail to choose "the right"
method, but here are some generalities:

Operating on anything other than a single frequency makes the radio
much more complex (and type approval more complex, too). So you'll
probably only be operating on one frequency.

At the bottom level you need a physical encoding method. Manchester is
typically used for this sort of application. It should be no more than
a day or two to get this block working, and you don't need to build
any RF to do it; just connect two micros together.

Atop that you need some kind of media access control. For a many-to-
one relationship, a timeslice system works well. One way of achieving
this is by having the "base" transmit a sync message periodically, and
having a DIP switch or other arrangement on each sensor that
determines its "address", ie. timeslice.

Another, more general method is to have each node sniff for carrier
before it transmits; if it detects carrier, it waits for a random time
before attempting to tx again (CSMA/CA, basically; <http://
en.wikipedia.org/wiki/
Carrier_sense_multiple_access_with_collision_avoidance>).

Encryption is off-the-shelf software, nothing to do with the radio
[though there may be legal restrictions about using encryption on the
air].

It's really not as difficult as you might think. Almost all of the
protocol layer can be developed by tying a bunch of open-collector
output nodes to a shared I/O line on a master micro.

ElderUberGeek wrote:

> 
> Thanks Iarwe,

Is that like Iiama (instead of Llama)? Or perhaps a
protagonist in a Greek tragedy?

Michael

On Mar 21, 7:55 pm, msg <msg@_cybertheque.org_> wrote:
> ElderUberGeek wrote:
>
> > Thanks Iarwe,
>
> Is that like Iiama (instead of Llama)? Or perhaps a
> protagonist in a Greek tragedy?

Lewin Aleksis Roger William Edwards ;)

larwe wrote:
> msg <msg@_cybertheque.org_> wrote:
>> ElderUberGeek wrote:
>>
>>> Thanks Iarwe,
>>
>> Is that like Iiama (instead of Llama)? Or perhaps a
>> protagonist in a Greek tragedy?
> 
> Lewin Aleksis Roger William Edwards ;)

Say thank-you to your parents.  I suspect you are the youngest
child.  My youngest daughter also got hung with all the unused
relatives names.  She only got to GJBEF.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



-- 
Posted via a free Usenet account from http://www.teranews.com

larwe wrote:

> On Mar 21, 7:55 pm, msg <msg@_cybertheque.org_> wrote:
> 
>>ElderUberGeek wrote:
>>
>>
>>>Thanks Iarwe,
>>
>>Is that like Iiama (instead of Llama)? Or perhaps a
>>protagonist in a Greek tragedy?
> 
> 
> Lewin Aleksis Roger William Edwards ;)
> 

Indeed Lewin; since your moniker is so often munged in this
NG I just couldn't resist this time -- I don't remember this
particular flub and I trust that 'ElderUberGeek' simply made
a typo. However, I do not remember ever seeing your complete
appellation in print ;)

Regards,

Michael

"ElderUberGeek" <aribloch@gmail.com> a &#4294967295;crit dans le message de news: 
1174497087.370774.276030@p15g2000hsd.googlegroups.com...
>
> Hi group. Would appreciate some views on this. Kindly bear with me, I
> have tried to provide enough information and clarity to be useful:
>
> Problem statement:
> Need to develop a bidirectional point to multi point wireless link
> (meaning many sensors and one aggregation point) for purposes of
> industrial data collection. BOM needs to be as low as possible.
>
> Requirements:
> - One base station interacts with few sensors (sensors may come and
> go)
> - Medium range (up to 30 meters or so)
> - ISM band (I prefer 433MHz due to environment but 2.4GHz can do)
> - Low data rate requirements (and small amounts of data)
> - Secure (3DES) - I realize this is not a function of the RF link per-
> se but it is a requirement
> - Can use proprietary protocol etc. (i.e. does not have to be
> standards based)
>
> Possible technologies:
> - Non standards based link (using "plain vanilla" good old RF)
> - Bluetooth
> - Wifi (i.e. 802.11)
> - Zigbee
> - ??
>
> Question:
> Basically the question is framed around two issues: price of required
> components and NRE to develop. Regarding components, the two main
> components are a radio chip and a microcontroller  to drive it (and
> also run the application logic of course). If possible I would like
> both to be under $10 combined (at volume of thousands or more).
> So, what choice will generate a minimal BOM while satisfying the above
> requirements, and of course striking a good trade off between minimal
> BOM and lower NRE. I do realize that, for example, in the case of a
> standards-based solution (i.e. Bluetooth, WiFi, Zigbee) much of the
> requirements (and work) is taken care of (i.e. mode building blocks
> exist, both in silicon and code) where as in the "plain vanilla"
> approach we would have to write a protocol stack, take care of perhaps
> frequency hopping, encryption, etc etc.
>

Hi,

On the hardware side the most cost effective way will very probably be to 
use an integrated transceiver chip, for example a Chipcon/TI CC1100 : under 
$2 in 1k quantities, minimal number of external components (may be 1$ 
including the crystal), and your prefered microcontroller depending on the 
application. Or, if you can wait a couple of months for it to be really 
available in volume, the newer CC1110 with onchip 8051 microcontroler 
(probably around $3). The antenna will be application dependant but could be 
a printed PCB antenna if you can accept a rather large PCB for 433MHz.

On  the software side you have several options : either develop the protocol 
stack yourself based on TI application notes, or look at the oneRF protocol 
standard that is starting to emerge (quite new...), or look at third party 
protocol stack suppliers. Well, for example my company has developped a 
protocol stack for CC1100+PIC18F or CC1110 chips dedicated to low latency, 
medium range applications, including frequency hopping & dynamic channel 
access control, automatic discovery, start network &#4294967295;essage routing, AES 
cyphering, etc. Its called ADDINET, and you can find a presentation here : 
http://www.alciom.com/en/solutions.htm

Friendly,

-- 
Robert Lacoste
ALCIOM - The mixed signal experts
www.alciom.com

On Mar 21, 10:39 pm, CBFalconer <cbfalco...@yahoo.com> wrote:

> > Lewin Aleksis Roger William Edwards ;)
>
> Say thank-you to your parents.  I suspect you are the youngest
> child.  My youngest daughter also got hung with all the unused

The youngest and oldest and middle. Really, they had no choice. My
father insisted on his names, which are the last three. Aleksis was my
godfather's name, and he's Sicilian; no negotiation possible there. My
mother didn't like any of those so she generated the name Lewin.