The gateway to online resources and design support for engineers, powered by RS ComponentsAllied

+Post a new topic

Food For Thought - What wireless technology you prefer for your embedded design and why?

Avatar Posted by jkvasan at

Wireless technologies are forming a part of our life in every manner. In your embedded project, if you need to use a wireless technology , which one will you use? 

Bluetooth, for its various security features?

Zigbee, for its easy networking features?

Wi-fi, for its interference-free characteristics?

Or

any other contemporary technologies?

It would be interesting to have all your views, please.

Replies

  • Avatar

    Posted by leon_heller at

    I like the Nordic Semiconductor nRF24L01+. It is widely used in wireless keyboards and mice.

    Very cheap modules are available from Chinese suppliers on Ebay, which are ideal for development.

    Leon

  • Avatar

    Posted by akhe at

    In the VSCP project (http://www.vscp.org) we will use 6lowpan over 802.15.4. I think that 6lowpan is open enough and solve several critical issues. It uses a well known programming model and can be implemented by small organizations also as oposed to Zigbee and zwave.  This is for units with quite a lot of flash >64K.

    For lower end devices we will se many propritary protocols also in the future. Chibi is a great project.

  • Avatar

    Posted by AtomSoft at

    I guess it all depends on what the application is.

    For instance if i just need to send small packets of data every few seconds i would just IR (SIRC, NEC, PHILLIPS). Its cheaper than most other solutions and simpler to implement.

    If i need a more stable solution i would use bluetooth. As its cheap and more reliable. Also most bluetooth modules use a simple AT command set.

    Another choice is Zigbee since there is more support and tons of info online. Also its not too expensive.

    Like Leon posted above the nRF24L01+ is also a great choice but i have never used it, perhaps because i have read somewhere that its a bit buggy and can lead to problems. Especially those from china. Please dont ask me where i read that. I dont remember and will not look.

    My last choice would be wifi. Its over complicated. I wouldnt recommend it unless your embedded system is running a RTOS. Otherwise prepare for headaches and lengthy code.

  • Avatar

    Posted by blhahn00 at

    Have you ever looked into Microchip's MiWi?  It's a proprietary low data rate, low power wireless protocol.  For more information take a look at www.microchip.com/miwi.

  • Avatar

    Posted by Headhunter at

    I have an embedded project that is also fully encapsulated. Up to 64GB of data exchange may be required during the charge cycle of 120 - 180 minutes. WiFi is the only format I am aware of even approaching my needs.

     

    On another project, great range is important, with robust connection, with only bursts of data required, so Zigbee in sub GHz range seems to fit rather well. It will also have GPRS, for local control, and considering Sat Comms for location tracking/mission status reports, and programming updates.

     

    A third project could use wireless, but mounted inside a steel drum makes for horrendous links. For this I think a data card will have to suffice.

    B

  • Avatar

    Posted by adfranz at

    You cannot anticipate all of the potential future applications, so deferred design principles apply.

    I would rule out Zigbee because it is not ubiquitous. People tend not to use Bluetooth because of the setup (this is purely anecdotal), so I'd choose Wi-Fi. If the chip supports both then you are not completely ruling out Bluetooth. Interference comes down to bandwidth, doesn't it? 

Post a reply