Adding wifi is very easy to do (given the right tools). It’s also full of potential pitfalls you need to be aware of. This article will be broken into two sections: how do you add wifi and what do you need to do it, and what to be aware of when designing your system or after something has gone wrong.
How do you do it?
In our example, we’ll show you how to get started with our system and add WiFi to a NetBurner based product (hey, we get to be self serving in these articles, right?). There’s really only three steps involved with this:
- Plug the wifi adapter board into the J2 header of the main dev board.
- Add these two lines of code to your application:
In the headers:
In your main function:
// Use this for SPI
// Use this for serial
- Boot the device, and configure the SSID and password with IPSetup. Fill in the network’s SSID in the SSID field and passphrase in the WEP/WPA field. Once you have filled these fields, hit the ‘Set->’ button to save them to the device.
Congratulations, that’s it. You ‘re now connected to a wifi network with your embedded device.
Unless something went wrong… Maybe, we should talk about why wireless isn’t always just fun and games. How can something so simple ever go wrong? Well, first let’s talk about how wifi works.
Let’s get PHYsical
At the base level, wifi is a collection of technologies that implement a MAC (Media Access Control) and a PHYsical layer. These are the layers that actually send the bits through the air, and are somewhat finiky about not being interfered with by mister giant radio transmitter, or that electric motor next to you, or that microwave, or anything else blasting in the same radio band. Depending on the version of 802.11 you are using, the physical encoding of the bits as they fly through the air varies, with newer versions being more resistant to interference, but it’s like standing in front of a speaker at a rock concert, no matter how loud you yell, your friend still won’t hear you over the music.
Additionally, the devices have to be close enough to communicate as well. The further away from a radiating signal source, the weaker the signal gets (the mathematically inclined of you will remember this as the Inverse Square Law). There’s a limit to both what is pratical, as well as legal, for the transmit power of a wireless radio. This, combined with the receiver’s ability to pick up the signal sets the maximum distance the device can communicate, in open air, in a straight line. Any sort of obstacle in the way (metal cases, cabinets, machinery, shrubbery, rain, etc.) will also absorb some or all of the radiated energy pointed at it, decreasing the overall transmit power.
Halt! Who goes there?!
Well, now that we’ve determined that the signal is indeed getting to where it needs to be, and isn’t being interfered with, what’s happening if we can’t connect to our wireless network? Well… on top of the MAC and PHY layers of wifi is the supplicant. If the network you are connecting to has any sort of security scheme (WEP, WPA, WPA2, anything other than “open”), there’s some sort of encryption and authentication occuring, controlling access to the network.
To be allowed to connect, you have to have the correct combination of network name (SSID) and password (key). You also have to use the right form of security to handle the transactions and the right cipher to encrypt the data. If any of these things don’t match between the two devices, between the client and access point, then the client will not be allowed to connect to the network.
We’re connected! Anything else I should know?
… And they are?
Ohh… you want to know what they are? How curious of you. Well, for starters, wireless in general is slower than wired networking. In NetBurner’s case, our modules have a 10/100 megabit full duplex ethernet connection which can transfer data in and out of the system. If you were to try and build a bridge from the ethernet to wifi, the wifi has about 10Mbit of throughput, which would start backing up the network data and depleting the network buffers, leading to system resource starvation.
There’s also the possibility for routing confusion, sending the data out the wrong interface (ethernet vs. wifi). This is a general class of problem not simply limited to wifi, but becomes aparent when adding a second interface (as wifi is to our users). Usually this won’t happen or matter, as if both interfaces are on the same network, it’s fine. If there on different networks, they probably have different subnets, and so routing is independent. But in the case where you can get shot in the foot, IP stacks often have a way to specify what interface certain communications get routed out (whether by table or by call). In ours it’s done using the “via” calls (connectvia, RouteOutVia, udp.SendVia, etc.).