Categories
Uncategorized

Wi2Wi W2CBW003 Wifi/Bluetooth module review

The Wi2Wi W2CBW003 is a highly integrated module that provides both Wifi and Bluetooth radios for embedded designs. This module is ideal for embedded designs, as it provides a lot of functionality in a small package and includes standard interfaces like SPI, SDIO and serial that connect with most embedded CPUs. With the availability of modules like the W2CBW003 and standard drivers in the Linux kernel, including radio functionality in an embedded device is very doable, even for low volume products. Wi2Wi provides an evaluation board for the W2CBW003 with a SDIO connector, UART connector, and BT Audio Connectors. For this review, the eval board was connected to a Marvel PXA270 ARM processor, and evaluated with current Linux and associated software.

W2CBW003 Overview

The W2CBW003 module integrates both WiFi and Bluetooth functionality in a 12mm x 12mm x 1.6mm package. The WiFi portion is based on the Marvell 88W8686, and the Bluetooth on the CSR BC04. Both of these components are well supported by Open Source software. Some other features include:

  • Separate Antennas for WiFi and BT.
  • ROHS compliant
  • Single Supply at 3.3V
  • 802.11g support (54Mbps)
  • Both SPI and SDIO interfaces for WiFi
  • UART interface for BT
  • PCM audio interface for BT

Pictures of the module and the demo board are shown below.

img_1798_small

img_1800_small

Evaluation System Configuration

The test software included with the Wi2Wi eval board is for a Windows PC, is provided in binary format only, and was not used in this review. For this review, I plugged the W2CBW003 demo board into a Compulab cm-x270 board (PXA270 cpu) running a 2.6.29-rc7 Linux kernel and a recent OpenEmbedded Angstrom distribution. With the exception of the Marvell Wifi Firmware, all software in this setup is Open Source and is available in the Linux kernel, and as packages in the OpenEmbedded Project.

When booting the kernel, you will see the following messages:

mmc0: new SDIO card at address 0001
libertas_sdio mmc0:0001:1: firmware: requesting sd8686_helper.bin
libertas_sdio mmc0:0001:1: firmware: requesting sd8686.bin
libertas: 00:19:88:06:0b:2e, fw 9.70.3p25, cap 0x00000303
eth2 (libertas_sdio): not using net_device_ops yet
libertas: PREP_CMD: command 0x00a3 failed: 2
libertas: PREP_CMD: command 0x00a3 failed: 2
libertas: eth2: Marvell WLAN 802.11 adapter

The “command 0x00a3 failed” messages are harmless, and have to do with features that are not supported. After the system boots, you will now see a new ethX network device:

root@cm-x270:~# ifconfig -a
...
eth2      Link encap:Ethernet  HWaddr 00:19:88:06:0B:2E
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:65902 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1758 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:13550002 (12.9 MiB)  TX bytes:251627 (245.7 KiB)

The “iwlist eth2 scanning” command will list available access points.

Connecting to Open WiFi Networks

A connection to an open wifi network can be accomplished by placing the following in /etc/network/interfaces:

/etc/network/interfaces:
iface eth1 inet dhcp
    wireless_mode managed
    wireless_essid any

And now execute “ifup eth2”:

root@cm-x270:~# ifup eth2
udhcpc (v1.13.2) started
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
Sending discover...
Sending select for 192.168.1.115...
Lease of 192.168.1.115 obtained, lease time 86400
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
adding dns 208.67.222.222
adding dns 208.67.220.220

root@cm-x270:~# iwlist eth2
iwlist: unknown command `eth2' (check 'iwlist --help').
root@cm-x270:~# iwconfig eth2
eth2      IEEE 802.11b/g  ESSID:"bec3"
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:18:39:C1:AD:4A
          Bit Rate:1 Mb/s   Tx-Power=13 dBm
          Retry short limit:8   RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:off
          Power Management:off
          Link Quality=84/100  Signal level=-37 dBm  Noise level=-87 dBm
          Rx invalid nwid:0  Rx invalid crypt:14707457  Rx invalid frag:0
          Tx excessive retries:58  Invalid misc:3   Missed beacon:0

WPA Secured WiFi Networks

The OpenEmbedded console image includes the WPA Supplicant packages which is used to manage wireless connections to secured networks. To set up the system for WPA encryption, modify the following files:

/etc/network/interfaces:
iface eth2 inet dhcp
   wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
   wpa-driver wext
/etc/wpa_supplicant/wpa_supplicant.conf:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=1
fast_reauth=1

network={
      ssid="bec"
      proto=WPA2
      key_mgmt=WPA-PSK
      pairwise=CCMP TKIP
      group=CCMP TKIP
      scan_ssid=1
      psk="ascii passphrase"
      priority=10
}

Then, execute “ifup eth2”, and you should see something like:

root@cm-x270:~# ifup eth2
WPA: Configuring Interface
udhcpc (v1.13.2) started
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
Sending discover...
Sending select for 192.168.1.115...
Lease of 192.168.1.115 obtained, lease time 86400
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
adding dns 208.67.222.222
adding dns 208.67.220.220
root@cm-x270:~# iwconfig eth2
eth2      IEEE 802.11b/g  ESSID:"bec"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:40:10:10:00:03
          Bit Rate:1 Mb/s   Tx-Power=13 dBm
          Retry short limit:8   RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:<too big>   Security mode:open
          Power Management:off
          Link Quality=64/100  Signal level=-68 dBm  Noise level=-89 dBm
          Rx invalid nwid:0  Rx invalid crypt:-1463809279  Rx invalid frag:0
          Tx excessive retries:22524  Invalid misc:3   Missed beacon:0

Other Observations

With the above networks, the bec access point was much further away than the bec3 AP, so you will notice the difference in link quality. “iwlist eth2 rate” can be used to list the current connection rate. When the network is idle, it sits at 1Mb/s. When downloading a large file, it will climb to 36 or 54Mb/s, depending on link quality.

Production Issues

The review demonstrates that it is fairly simple to set up a demo quality Embedded Linux system with WiFi. Some of the issues that would likely need addressed for a production system include link management, test software for certification, and power management.

There are several ways to programatically control WPA Supplicant including linking to the wpa supplicant control interface, or using DBus. There are several WiFi management applications available including Gnome NetworkManager (used in desktop systems), and connman which seems a little better suited for embedded systems.

Unless you use a completely pre-certified module + antenna solution, you will likely need to do some level of agency certification. As many products use a custom antenna, this is an important issue to consider and plan for. While Marvell provides test software and firmware, it will likely require some work, as their software is designed to be used with their in-house drivers rather than the libertas driver which is available with modern kernels.

Also, if you want to minimize the power usage, some work will be required to figure out the power modes supported, and how to implement/control them. With this module, the Wifi and BT portions run off the same crystal, so if you only want the BT active, you will need to actively power manage the Wifi portion to a low power state instead of completely disabling it.

Conclusion

TheW2CBW003 module is an attractive solution for products that need WiFi functionality. With the availability of modules like this, and mainstream open source software, the technology is available to about anyone, including low volume manufacturers. Standard interfaces such as SDIO make it possible to interface this module with about any modern ARM processor that can run Linux. Software support in the Linux kernel, wpa supplicant, and the Linux wireless tools provide the needed software support to implement a very complex system with relatively little effort.

Categories
Uncategorized

Marvell Embedded SDIO Wifi Success

As detailed in the article I wrote back in September of 2007 (http://bec-systems.com/web/content/view/75/9/), getting  embedded wifi modules functioning is not a simple task.  However, due to recent advances in the Linux kernel, it looks like a viable solution for low-mid volume products is emerging.  This article provides a few details on how to get a Zcomax (Zcom) XG-180MU module working with a PXA270 processor.

System Setup

The setup used includes:

  • Zcomax XG-180MU SDIO Wifi module
  • Compulab cm-x270 + sb-x270 system (includes the PXA270 processor)
  • Linux kernel 2.6.24-rc5
  • OpenEmbedded

Support for the Marvell 8385 and 8686 based Wifi chipsets is now included in the mainstream Linux kernel 2.6.24 release candidate source code.  To use this driver, enable the CONFIG_LIBERTAS_SDIO option.  I also had to enable the CONFIG_WIRELESS_EXT option to prevent a compile error, but this is probably required anyway to build a functioning wireless system.

Firmware

The firmware for the Marvell SDIO wifi solutions is downloaded at runtime, so the next challenge is to find firmware files.  I am working on a project that has access to a driver from Marvell, so I was able to extract this firmware from their source code header files.  I’m sure there are other places where this firmware is available.   The firmware files must be placed in the following location:

root@cm-x270:~$ ls /lib/firmware/sd*
/lib/firmware/sd8385.bin         /lib/firmware/sd8385_helper.bin

The version of udev used in OpenEmbedded determines the location of the firmware files.  The Libertas Linux driver requests these firmware files, and a userspace component of udev provides these files to the kernel.

Success

The following kernel modules are required:

root@cm-x270:~$ lsmod
Module                  Size  Used by
pxamci                  7008  0
libertas_sdio           8488  0
mmc_core               46868  2 pxamci,libertas_sdio
libertas               85288  1 libertas_sdio
ieee80211              29956  1 libertas
ieee80211_crypt         4768  1 ieee80211
root@cm-x270:~$

And the result:

root@cm-x270:~$ modprobe pxamci
root@cm-x270:~$ mmc0: new SDIO card at address 0001
libertas: eth1: Marvell WLAN 802.11 adapter
ifconfig -a
...
eth1      Link encap:Ethernet  HWaddr 00:60:B3:34:77:66
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Very nice!

So it looks like there is finally an embedded Wifi solution for products that sell less than 500,000 units per year.  I also briefly tried this on a AT91SAM9260 system, but it did not work.  So there is still some work to do on the Linux SDHC driver for the AT91SAM9260.

Categories
Uncategorized

The Embedded WiFi module Quest

original article written in Sept, 2007

How does one implement WiFi functionality in vertical, low volume portable products?  This is a good question, and one I’ve been struggling with for the past 3 months.  I have a customer who is designing a portable data acquisition system based on a AT91SAM9260 processor, and needs WiFi functionality.  The fundamental problem is that no one has time to deal with low volume customers, and the task of implementing WiFi functionality is obviously complex.  At volumes of 5000 units a year or less, it makes a lot of sense to go with a WiFi module rather than trying to integrate the WiFi chipset on the board.  This article covers some of the options we have looked at and some of the possible solutions.

How is WiFi done on x86 systems?

With desktop Windows, most devices are well supported by device manufacturers.  With x86 Linux some of the devices are well supported by OSS drivers, but these tend to be PCI or USB devices.  Some of the devices that are not supported can still be used by running the Windows NDIS drivers inside of ndiswrapper, which allows you to run the Windows driver on a x86 Linux system, but this obviously does not work very well on non-x86 processors such as ARM.

WiFi solutions for portable, embedded systems

While there are many off-the-shelf solutions for PCs, Notebooks, etc, the current solutions are generally in the USB formfactor.  The ideal solution for portable systems running non-x86 processors are the small modules that connect to the host processor using the SDIO or SPI bus — like the modules you would find in newer cell phones and PDAs.  Older modules tend to use the Compact Flash interface, but these modules tend to be larger and are not packaged as nicely for deeply embedded applications.  So Ideally we want:

  • a modules with a SDIO or SPI interface
  • packaging options such as solder down for robust packaging

The scope of this article is limited to modules that implement a SPI or SDIO interface.  Why are we interested in modules?  Putting a WiFi chip down on a custom PCB is a lot of work.  Because the WiFi silicon includes a processor, if things do not work, it may be very difficult to debug.  There is also the issue of factory calibration which usually requires proprietary PC based tools that can communicate directly with the WiFi silicon.  If the WiFi silicon is buried in your product, getting all this to work can be a challenge.  The test equipment required for calibration is expensive.  Add to this the difficulty in getting support from anyone who makes WiFi silicon …

Complexity

It should be noted that WiFi modules are fairly complex devices.  They are typically based on a highly integrated IC that includes an ARM processor, Flash memory, and radio circuitry.  The fact that these modules include a significant amount of firmware on the module contributes significantly to the complexity of getting WiFi solutions to work properly.  Hopefully no bugs are encountered in the module firmware, because I can only imagine how difficult it would be to get these fixed for a small customer.   The fact that the module firmware is involved in many of the WiFi functions like authentication further complicates the problem with the abundance of authentication and encryption options available for WiFi.   The worst possible problem is the case where you must design an embedded WiFi system that must operate at the enterprise level in every environment.  It is one thing to design a system that works most of the time in most environments where WiFi is more of a convenience (like a Cell phone or PDA).  It is another thing to design an industrial grade system where it must work all the time and in all environments.

The Fundamental Problems with low volume embedded WiFi

I have never worked with a technology with so many dead ends as embedded WiFi modules.  Many of the companies I email or call never even bother to return emails and phone calls.  This is certainly true of the chipset manufactures.  From what I can gather, the fundamental problems are:

  • WiFi implementation is difficult; therefore, a manufacturer’s scarce resources are dedicated to high volume customers.  Low volume customers are a significant distraction.
  • WiFi companies are very busy right now — they are not hungry for business from small customers.
  • WiFi solutions are very competitive and highly proprietary.  Many companies are very secretive and will not release driver source code.  This is certainly true at the module firmware level.

There are many WiFi module manufacturers and resellers out there, but very few of them offer any type of driver solution for Windows CE or Linux other than binary modules that are supposed to work on perhaps one reference platform.  Sorry, this is not going to cut it.  So, with plenty of hardware available, the gating item is the availability of software drivers and knowledge of how to use the software.  It would seem to me that this is the perfect opportunity for chipset vendors to open source some drivers and develop vibrant support communities so that their modules can be used without a lot of hand-holding by the chipset vendors.

So What are the options?

Atheros AR6001

The Atheros AR6001 seems like a nice solution.  The driver situation for the AR6001 is progressing.  For Windows CE, there is an opensource WinCE 6.0 driver available at:  http://www.codeplex.com/CEWifiDriverAR6000/.  Unfortunately, this project appears to be a snapshot of code and does not have any significant amount of community activity or development.  Perhaps once more AR6001 modules are available, this will change.

For Linux, there are several options:

  • Atheros has released a driver that is available:  http://sourceforge.net/project/showfiles.php?group_id=186068.  There are several issues with this driver in that it is written for a SDIO stack that will likely never be part of the mainstream kernel.
  • A driver is being developed as part of the OpenMoko project.

Embedded Works supplies Atheros based modules and development boards: http://www.embeddedworks.net/wlan/oem_sdio_80211g.html.    AR6001 development boards are also available from Cardaccess: http://www.cardaccess-inc.com/products/index.php?a=wlan_sdio.

Marvell

The Marvell 88W8385 seems to be a very popular IC in WiFi modules available from a number of different companies.  OSS Linux drivers are in progress and are reportedly somewhat functional at this point, so it is probably just a matter of time before these devices are well supported in Linux.  This chipset/driver is often referred to as “libertas”.  The SDIO stack being developed for the Linux mainline (http://lwn.net/Articles/242747/) is where support for this device is being developed.

For Windows CE, it seems the only option is to get the drivers from Marvell, which is a very difficult and time consuming process — at least for low volume customers.  First you have to find a module reseller that can get you the source code from Marvell, and then the process takes about 3 months.

Other Options

There are a number of other WiFi Silicon manufacturers and module vendors, but the driver options from them seem to be very limited in the form of binary only drivers that will only work with certain processors/operating systems.  As noted before there is almost no hope of getting anyone to even talk with you if your volumes are low.  So your only hope is finding a module vendor that can do any driver work for a NRE fee, obtain the source from the silicon manufacturer, or use OSS drivers.

Summary

The Embedded WiFi situation is changing fast, so by the time you read this, it is probably already out of date.  We are currently at the phase where it is very difficult to deeply embedded WiFi in low volume products.  I expect this will change during the next year.  Eventually, WiFi modules re-sellers will figure out that supplying hardware is just one side of the equation.  As things get more and more complex, the software availability and support is becoming the gating item.

Many thanks to James Nahra, Dave Anders, and Erik Strack for sharing information and their WiFi experiences with me over the past few months.