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

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 , 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!)

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; ).

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.

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

Michael

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.

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" a écrit dans le message de news: snipped-for-privacy@p15g2000hsd.googlegroups.com...

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 ùessage routing, AES cyphering, etc. Its called ADDINET, and you can find a presentation here :

Friendly,

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.

Typo? Is that an "iarwe" with an uppercase 'i'? The font I'm using has no difference between capital i and lowercase L.

On Mar 22, 3:53 am, "Robert Lacoste"

I infer from this that you haven't actually put a CC1100 design into production in mass-market volumes, and you are estimating where the economies of scale might lead based on your experience with a prototype or short-run special-function device.

The OP, according to his project description, needs to Tx data from a number of remote locations to a single central point. He needs only a discrete Tx at the sensor end, and a simple collision avoidance algorithm (even that might not be necessary if the transmissions are infrequent enough; commercial wireless thermostat solutions, as a rule, rely on a short on-air time to reduce the possibility of collision).

Messing about with transceivers - the CC1100 is relatively finicky, though there are worse parts - and complex multilevel bidirectional protocols is wasted engineering for such a simple application.

"larwe" a écrit dans le message de news: snipped-for-privacy@d57g2000hsg.googlegroups.com...

If only unidirectionnal datastream is needed (and if lack of acknowledgements are ok) then you have just to replace the CC1100 by a CC1150... However if collision avoidance is needed (and it is usually the case) then you NEED a receiver too... Cheers, Robert