RF4CE has been officially announced

Hi.

Please keep me updated with the RF4CE developments.

Thanks.

Akiba

FreakLabs

Open Source Zigbee Development Blog

www.freaklabs.org 

 Hi Akiba,

I like your web site.  The RF4CE web site is under construction http://www.rf4ce.org/
You can follow the development on this web site.  

LPWRocks 

"the RF4CE protocol which is not based on any existing protocols in the market today"

With the pletora of 2.4GHz based protocols in developpment today (WiFi, RF4CE, Zigbee, Bluetooth, SimpliciTI, 6LowPAN, W-HART, ad-hocs ... to name just a few) I don't know if in the house of tommorow we will have more than few kbps !

I understand that each application needs its own specifications, constraints, ... but I don't understand the need to have SO MANY different solution. Standards are great for the sack of interoperabilty but aren't for code size i.e. But when we will be confronted to tens to hundreds of nodes in a smal room as the living room, with audio-visual, radio equipments, TV, Settop boxes, zigbee-enabled switches, w-hart-based HVAC controlers, 6LowPan intelligent fan, laptops, desktops, cellphones, .... I doubt that will be so simple to just forget the standards for a matter of cost reductions.

To come back to the RF4CE, why don't use existing protocol ? Do the bandwith-power requierment-simplicity-other criteria tradeoff is impossible to solve with actual protocol?

 If you checkout the RF4CE web site now it is alive and kicking

LPWRocks

The two directions are either trying to shoe-horn in a new concept into an existing standard or creating a standard that perfectly fits your goals.  With the former you have on less standard (unless like ZigBee you build it as a layer above an existing standard), but you might be constrained and if that larger standard body switches to a new standard (ZigBee Pro from ZigBee) do you switch or keep on the old one or adapt.  If you run the standard then all is well so long as the members don't try to do like Microsoft did to java, yeah we will use the standard, but put our additions in.

I have to agree with you about the few kbps.  With high data rate devices screaming all over the 2.4GHz space, all the other stuff might get squished out.  Fortunately a lot of this stuff is low data rate and not too critical on timing (though having to see The Donald an extra 1/2 second might be traumatizing), so it should work well. 

Thanks for the heads up on the rf4ce site. I already checked it out a couple days ago when someone from my blog was asking about it. There's also some interest in it here in Japan. 

Since you're in Norway, were you part of the original Chipcon team? I'm a big fan of the CC2420.

Akiba

Open Source Zigbee 

http://www.freaklabs.org

 Hi Akiba,

CC2420 is a great part. It has been around for a while. CC2520 is our new addition of course. 

Yes, I am in Norway and one of the Chipcon guys as many others. I am have been working with it ever since the release November 2003. It has been a great asset to the open source community implementing IEEE 802.15.4 applications. I am very happy to see that TinyOS and also the Contiki community adopted it.  

Anyway, I am big fan of Japan and Tokyo too. I have been there multiple times. A lot of exisiting short range communications apps in Japan. You are the trendsetters for many short range RF applications world wide.

LPWRocks  

 Hi,

Here is an article about RF4CE.

What is required for RF4CE? 

http://www.rfdesignline.com/showArticle.jhtml?articleID=209400657&cid=NL_rfdl

LPWRocks 

 RF4CE is built on top of the 802.15.4 MAC protocol, and includes networking functionality and application support profiles.  From a requirements standpoint to build an RF4CE compliant device you would need to get an 802.15.4 device (e.g. The CC2430), get a compliant RF4CE stack (not available yet since the specification has not been finalized, but we will release one as soon as it is ready), and then build your RC application using the application profiles and sample application code on top of this stack.  Right now the specification is still under development, but stay tuned as TI will be ready to release as soon as the specificaiton is complete and we will be prepared with full development kits, sample applications, reference designs, etc...  We're getting very excited!

Hi. Thanks for the info on RF4CE. If its possible to answer, I have a couple of questions. Don't need to answer them all, but if you can provide one or two, I'd greatly appreciate it.

Is the current version of the protocol using 802.15.4 in beacon mode or non-beacon mode? Also, if possible, what kind of routing are they using (ie: table-based, source routing, etc...)? And finally, how close is it to Freescale's Synkro stack?

Sorry if I sound pushy. There's just so little information out there about this protocol.

Thanks. 

I wish I could provide specifics but at this point I can't provide any information on the 802.15.4 configuration or details of RF4CE outside of a general overview of what functionality is supported.  Please see the RF4CE website for more information and check back periodically on the TI website as we will have a RF4CE product page available soon.  As far as Synkro is concerned, I don't know the details of what has been implemented there but I can say that the existing protocol will not be compliant and our competitors will be no further ahead of us in the sense that we will both release a compliant stack at the same time.  

Thanks for your questions and sorry I can't provide further detail at this time.

Brian 

Hi Akiba,

I guess I would expect it to be an asynchronous protocol, or a polled protocol using beacon request, and data request from the remote. This will then fall in the catagory of a non-beacon type network. 

LPWRocks 

I am just looking forward to being able to not have to aim at the TV or stereo.  The stereo one I have almost needs a laser sighting to get it just right.

Hopefully someone will make a retrofit kit for the IR devices out there that allows RF remotes to be used with them.

I am not sure if they would use beacon, but guessing. The reason for my guess is because this is the mechanism of IEEE 802.15.4 to associate to a network.  This is just an educated guess. Hopefully the network layer also will not be as complex and only contain a small set of primitives for the application layer to incorporate. 

LPWRocks 

 Is there a standard protocol using the simple ISM band like SIMPLICITI or MIWI (from Microchip), etc, etc?....there are a whole bunch of non-standards. I was hoping this standard could become that. I don't want something based on zigbee. I was something capable of 2Mbits/sec (before protocol) in a chip for around a dollar (not including uP). I have a new encryption standard that is as good as DES and doesn't require special hardware and much less oomph to decode (4 cycles in assembler per byte)....called SDES (Small Device Embedded Security) (I'll be putting this on open source eventually).

 The reason I'm looking for this is that there are whole bunches of applications to truely ubiquitously network the home where even a pen in networked, you cup is networked, all your applicances are networked, etc, etc.... The key though is providing the hardware to get from the device via cheap low power networking  to the main home or company network  at a very low cost (must be under $5 total for everything related to the wireless (sheilding, antenna, circuit board, manufacturing costs and components and a small uP....like an MSP430 kind of power).

The idea is that you need at least 2Mbits/sec (1MB would also work), but you need to be able to stream audio or small screen video (ipod type screen) and 2Mbits/sec should be enough for that.

Also would use an XML based UI where icons come from a predefined set of 255 of them with 3 states (on, off, disabled). These states could be 3 different icons for cases where the states don't mean anything. This eliminates any bitmaps. Then all the other elements like sliders etc are all standardized. So, on initializing contact between remote device and main master control PC (ONE PER SYSTEM). the control can be downloaded and an icon appears for that device. You click on this and it's UI appears. You click on another device and it's UI appears so you could have your alarm clock UI and coffee machine UI on the screen at once on the Master Control PC (MC). Then you could draw a line from the alarm event in the morning to the brew button on the coffee machine. This would cause your coffee machine to brew when the alarm wakes you up in the morning....you get the idea.

The MC could have certain "shared directories" set up by the user with music files and any music player (like your alarm clock) device could access those files, so you'd be able to select a song from your menu and set it to play or to play as the alarm. This helps you avoid setting SMB filesystems, but it does introduce a master Control PC in your system. You could have slave PCs where you could change some things but not UI to UI interaction, etc, etc...

The Slave Control (SC) device could be used for things like cellphone to turn on heat on your way home from work, so you can see the UI for your home's thermostat and turn it on directly using DDNS.

 Now, I tried putting a company together based on all this but I encountered that there are no standards for ISM. ZIGBEE isn't fast enough (2Mbits/sec) and requires too much in protocols and uses DES (too complex and unnecessary) etc, etc...

 I'd like a company like TI to take the initiative here and put together the protocol level (something that is IMS based but maybe a little simpler than SIMPLICITI, which I think is a little bit too complex).

 It's a big subject and I've barely even touched on some areas.

 It's going to be one of the radio companies (TI, Nordic Semiconductor or one of the bunch of new ones like Nanotron).

Other aspect is UWB is pretty much dead as it's not delivering in performance or price. Also what happened to 802.11n. The high end needs something for HD delivery. I was hoping that 802.11n would solve the problem.

Later

-Donald

 I think you're looking at protocols when in fact, the data rate that you are looking for is dependent on the radio. Zigbee, RF4CE, 6LoWPAN, etc... are just protocols that ride on top of 802.15.4 which specifies that the radio has a maximum throughput of 250 kbps. 802.15.4 was created for wireless sensor networks and emphasizes low data rate in exchange for low power. In fact, the name is LR-WPAN or Low Rate Wireless PAN. It sounds like you are looking more for a multimedia type of radio, of which Bluetooth and 802.11 are the most likely candidates. In regards to 802.15.4, some chips increase the throughput by decreasing the amount of spreading in the spread-spectrum radio. Although this is a TI board, I must say that Atmel offers this type of functionality in its AT86RF231 with a max throughput of 2 Mbps. Other companies such as Freescale and Radiopulse offer up to 1 Mbp. However if you choose to use these radios outside of the defined 802.15.4 spec, you will be incompatible with just about every other 802.15.4 radio out there so you will need to think if this is something you want to do. 

 No, I'm familiar with the distinction. Understand I was on the verge of doing a startup, talking with people for numbers in the range of 5 million dollars. I knew everything technical on the wireless end (I had to or they wouldn't even talk with me). I didn't get money or feel that it was worth proceding with because I couldn't find a standard for ISM like I was mentioning.

The problem I encountered though is exactly what you are saying. Zigbee forces you to be 250Kbits/sec, which isn't enough to be the "ultimate sensor" There are all kinds of sensors that require 1Mbits/sec.....e.g. low res video as an AI burglar alarm to recognize people and pets so you don't have to disable your alarm when you have pets at home. Thats just a minor example. I could think of many more. I've found that for a general purpose wireless sensor network for the home or everywhere, you need to be able to pipe audio and low res video. Other wise, you are going to have one network for one kind of sensor set, another for another type of sensor set, another for audio bandwidth levels, another for low res video levels, another for broadcast video, andother for HD video......whereas I can easily visualize a paradigm where there is one wireless (hardware up through protocols) that handles sensors plus streaming audio (one stream is enough) plus one low res compressed video stream (mpeg4). Then anther level (maybe 802.11n) to handle both broadcast and HD video as well as high bandwidth web browsing and general computer networking.

UWB has kind of turned out to be a flop in my opinion. 802.11 is a good standard, but the prices are in excess of $8 for a chipset. for higher bandwidth, 802.11n and those prices would be fine). For the low end, we need to use the ISM bands. The ISM bands that the $1 chips have are all around 1Mbit/2Mbit in bandwidth. If we could standardize on a protocol that lies over this PHY layer, we wouldn't need bluetooth or zigbee or any other.....it would be this "I-proc" (I'm just making up a name here for a new ISM band protocol that can do the sorts of things I mentioned earlier). It could all be centered around a module that costs around $5 to buy "ready to plug-in".

The problem is I'm seeing projects like the Berkley wireless "dust" or the scottish version called Specks, but they base everything on some hardware and slow protocol that costs in the range of $100 per sensor, when the technology is here today to have this sensor module for $5. TI will probably mix it's MSP and chipcon technology for a 1 or 2Mbit/sec chip for $2 or so. This on a circuit board with a few bits of glue hardware could provide such as $5 module. We'd need a common protocol though. Problem with this is that TI uses simpliciTI, while Microchip has something called MIWI and there are a dozen others out there. We need a single standard so that everyone . This is probably not the community to put this out there as it seems like this community is already based on zigbee. I'm saying we need to replace zigbee or change it to do what I've proposed.

 As for your comment on spread spectrum, you should be able to get that bandwidth using chips like nordic semiconductors. Note that I'm not necessarily saying use spread spectrum in the conventional sense. I have ideas for using a frequency hopping mode. Note that the nordic chip can receive on 2 bands at once. You could use this to measure strength of noise on which frequencies to determine the next frequency to use and only jump on a long time basis or if the noise on the current band is too high (checksum can tell you this). A beacon signal once every 5 minutes or something could start the necessary algorithms running from a common point. I'm getting into more detail than is necessary here. I'm really just trying to present this from a 10,000 foot level.

I think what I'll have to do is just watch and find a standard or when I see something that might be good, maybe push for it, or present my SDES encryption algorithm to open source and build on this with a proposed protocol. I feel I must provide it for free now though as this is the only way it will become a standard is if everyone buys into it.

 Thank you for your response though "FreakLabs". :-)

-Donald

Actually, this is what I meant by decreasing the spread...

Standards are great, there are so many of them... :-)

Seriously, the reason there are so many wireless standards is that various applications vary so much in their requirements. You have to juggle range, power consumption, complexity, data rate, latency, different network topologies, cost and so and so on. Everybody has different ideas about what kind of trade-offs need to be done, and that's why you have a lot of standards and even more proprietary solutions.

Now, there have been some attempts to make a "universal" wireless standard, the best example is Bluetooth. Now, you can do a lot of different things with Bluetooth and I believe you could do most of the things you are asking for (not mesh networking, though), but it is very complex to deal with. Doing everything for everybody is difficult, and often ends up as "design-by-committee".

 You hit it on the nose Karl. That is exactly the problem. I can implement a version of Bluetooth using these ISM chips I believe. It's just a form of FHSS (Freq Hop Spread Spec), that could be implemented in software. The question is if I take a 2Mbit/s ISM chip, whats the max throughput I could maintain if I connect lets say from a device in one's pocket to a relay device in the current room to reach the main network (lets say the main network is 802.11a/b/g). Such a relay box could be very cheap. Your low cost bluetooth module with a powerful IR interface for remote controls (I have some ideas on the usefulness in such a box and it's really low cost) and then maybe a cardbus connection for something for 802.11. Problem there is you have to make assumption like prism chipset or something like that to support only a finite set of cards. It does allow the user to make the box cheap and break out the cost, so the box costs $20 (also has hard ethernet). So you could plug ethernet into the box directly if you have it. If not, you can then buy a compatible 802.11 card.....problem solved.

 It's an idea I should take a closer look at.

Thanks Karl

-Donald