Thumbs way down for Arduino WiFi shield. Read before you buy

As a very senior member of this forum, I usually refrain myself from ranting in a subforum other than the bar/sport but this is going to change for the Arduino WiFi shield R3. It is an expensive piece of DIY hardware but has so much unfinished business that has made my time very miserable. I tried to work around its limitations but would like to warn any newcomers of these before you make your purchase. If you have experience that is very opposite of mine, please be sure to share.

(1) Here we go. The version control of this product is horrible! The Arduino WiFi shield is not just a shield. It contains at least two (if not 3) microcontrollers that run programs just like Arduino itself, but more complex. The operation of the shield depends on the operation of these firmwares AND your Arduino WiFi library. I found that there are many versions floating around, both firmware (coming with the product and updates) and library (Arduino IDE 1.5, and other places). One library that dates 1/19/13 works with my shield R3 out of the box but the library in Arduino IDE 1.5 fails to work. Then I had taken a chance at updating firmware 3 weeks ago (late April) that crippled one shield. It was able to connect to router but can't contact any servers while the other one without upgrading was. Then I encountered a major hurdle described in (2) but I will deb into it here. There is a hard limit on the size of string you can send with client.print, being around 90 bytes. Anything longer will not make it to the server or client at all. I contacted Arduino team and was told it was already resolved while back and I just had to flash firmware and use the "latest" library. OK, as of today (5/13) I went to github and was only to download the entire arduino master (no button for just wifi stuff). The download yields the firmwares and library. Again there is no version number or which dated library is compatible with which dated firmwares. I tested the new library with known working code and server. It was a go for the upgraded shield but no go with original R3 shield. Notice the situation has entirely flipped. What the heck?! Can someone maintain library version numbers and post readme on what version of lib works with what version firmware? I guess answer is NO.

(2) As I said, the client.print has a hard limit at 90 bytes. I sent 92 bytes and more per print and it simply doesn't appear on the other side regardless which role Arduino assume (server or client). I was told it was solved with the latest stuff but not. How can I trust them with this firmware/library if the problems they claimed to have been solved is still there?!

(3) Firmware upgrade is difficult even for me, a "veteran", and no description on what the indicator leds should do and length of time taken to do the antenna firmware. It just needs to be rewritten or videotaped for clarity.

(4) Sample code not working. Just search forum for "wifi shield not present", you see too many of those popping up, why? Sample code is not working. All sample codes does one time check on wifi shield presence and if not presents, hangs the program. I don't know how quickly the wifi shield boots up but I had a very hard time pinpoint the solution to this problem until I added delays such as:

  // check for the presence of the shield:
  unsigned long start=millis();
  while (WiFi.status() == WL_NO_SHIELD) 
    if ((millis()-start)>30000)
      Serial.println("WiFi shield not present"); 
      // don't continue:

Shaky original code:

  // check for the presence of the shield:
  if (WiFi.status() == WL_NO_SHIELD) {
    Serial.println("WiFi shield not present"); 
    // don't continue:

Maybe this problem is solved by "latest" updates but it was never mentioned anywhere that you may want to wait up on the shield. It normally takes a bit time to boot up from power cycle but maybe quicker from reset.

I have heard good things about other wifi products but thought I should stick with Arduino team due to their support and forum support. My while Arduino WiFi R3 experience is making me flip. Maybe the Team is hitting hard walls trying to maintain too many things? Maybe 3 microcontroller (arduino+2 on wifi shield) is the theoretical limit of open source hardware/software since three things and the result not working implies too many possible errors to solve as open source lacks paid technical support and enough competition?!

Yay open source,

If time was taken to design and produce a reliable product someone else will rip it off and sell it cheaper, so, an idea is had, rushed into production with the idea of clearing up loose ends later with updates and bug fixes.

What is arduino anyway, it's really just the IDE, the boards are just carriers for the Atmega range of chips with the pins broken out into a standard form factor.

"Arduino" the concept should be for even the greenest of noobs to plug in the lcd shield and it work first time, even that doesn't happen with too many 3rd parties making shields with their own libraries and pinouts.

Ouch, particularly for such a high-ticket item. Is there not a formal test suite for pre/post release testing?

What I wish they had were function calls wifi.lib_version() and wifi.firmware_version()
They don’t implement version control and don’t announce when a new version is out then it will be a chaos. Think about how to help a newbie with "my wifi shield is not working " problem.

pylon found source of the 90 byte limitation:

The reset circuit is also buggy. After the server crashes, you can't reset it with reset button. You need to yank the USB cord to power off the shield and then power it back on to detect it again. An the server does get screwed up from time to time. The arduino keeps running, it just no loner do you anything with WiFiClient client=server.available(); The return is no longer valid connection.

Also, after upgrading to the "latest" firmware and library, only my Arduino MEGA R3 with the extra headers (SCL SDA Vref) can detect the shield. My MEGA1280 and MEGA2560 are not able to detect the same shield with the same sample program. According to their diagram, none of these is connected to anything on the shield. Then it might have something to do with the different reset circuits across revisions?!

What I wish they had were function calls wifi.lib_version() and wifi.firmware_version()


I can't agree with the other points in your rant though. The only problems I have had with my official WiFi shield, are of my own making. It was very unreliable, until I read the manual properly and stopped trying to use the SPI pins for I/O. My initial attempt to port Apache to the Arduino didn't go too well either. I am used to coding for full sized servers. Trying to overcome the challenges of processing indeterminate length strings, in just 2KB of RAM, has usefully reminded me how much protocol stacks are taken for granted.

Yes, I would agree the shield can appear to be fragile. Any whiff of a buffer overrun and it will crash. Whether there are other WiFi shields which are more resilient at similar cost, I can not say. I have lost count of the number of times I read good things about something, only to find lots of bad things which had not been mentioned, after I shelled out.

I really disagree with the bad because it's open source propaganda. Perhaps because I spend my day job running business critical web, e-mail and application servers, built on open source platforms. I also have to deal with the commercial brands and they are, in my opinion, far worse when it comes to releasing unfinished products, relentless patches and imposing upgrades of dubious benefit.

With any Tom, Dick or Harry able to fork off their own prototype, publish it on Google with claims it will shift your paradigm, there are bound to be a few open source lemons around to avoid. Such does not prevent World beating projects being open source projects. I am too knew to Arduino to say which it is but I am extremely impressed to date. I have no problem paying just a little more to support the Arduino project, above the cheapest boards I could find listed on e-bay.


Hey Matt,

Thanks for your input. I'm glad that you're alright with your arduino wifi shield (no 90 byte limits?). I should modify my remarks on open source hardware/software a bit to point to the open source hardware that involves microcontrollers and their firmware as the software, plus supporting library. I never meant to point fingers to open source software in general but now realized I did do that with my statement. The open source software that you know of (I don't have your web server experience) is very different from Arduino. With Arduino, you hardly find any documentation of a library beyond basic function calls and simple examples. Most of the basis is not covered in any of their library doc. They don't use doxygen (like AVR library) or other methods like that to document functions so it is left for the users to figure that out. This is probably different in open source software in general. Lots of them are well documented to what each knob does when you turn it 90 degrees to the right under what condition (or state). Arduino has none of that. If you run into the grey area of undocumented states, you figure out the outcome yourself by reading their code. This is not very nice. If you then have the wifi shield or the like, where there are multiple firmware with none of these grey areas explained, you are bound to fail critically when not all stars are lined up in your night sky.

I admit I'm creating my share of problems with my programming, but when the wifi server is stuck and a push of reset button won't bring it back to square 1, then I'm out of ideas how to pragmatically prevent crashes. So I still speculate that the critical point of open source hardware/firmware is 3 microcontrollers, not in star topology but in hierarchy. Say MCU 1 commands/depends on MCU 2, which commands/depends on MCU 3, all of which run software/firmware. I speculate this as the breaking point of Arduino. It's like three lost buddies in the woods all wandering around to find one another. How often do they all show up at the same place? Say you have 95% chance to depend on MCU 1 to work correctly (world not perfect), then all these piled up to (0.95)^3=0.86=86% with 3 MCUs. If you only have 85% trust on any one of these pieces, from your own experience, the final is down to only 61%. My trust on this wifi shield is somewhere below 85% on the Arduino firmware, say 75%, maybe 95% on the antenna firmware, but maybe only 75% on my own code combined with the arduino side of library. My outcome is 50% so fifty-fifty. That is what I feel about my project overall. Reminder, all the undocumented grey areas, such as, if a client disconnects before the complete message is read with, will client.available() still be true since the shield has buffered more bytes of the message than Arduino has read? In Arduino world, only perfect situations are explained, but, what if I push the "X" on my browser to stop transmission/connection? I'm left to find that out myself.

I'd like to add the original WiFi shield R3 (unknown firmware version) and original library (dated Jan 2013, again no version number) are better. See what I got here:

The newest firmware and library seem very unstable especially with iOS clients. Crashes every time. With original version there is no more crashes described by that post.

Documentation is one of the most neglected fields IMO, probably because not many people like doing it at any time much less at the end of a project when you want to get to the next fun thing.

I'm one of the few that actually enjoys documenting things.


Documentation is one of the most neglected fields IMO, probably because not many people like doing it at any time much less at the end of a project when you want to get to the next fun thing.

I'm one of the few that actually enjoys documenting things.


Then we share more than just a hobby in Arduino! I recently started writing very detailed work log, well, not for money or contract or anything, but to document my learning process for my next big thing, arduino server project for a web based cross platform graphical user interface. I have grown to like documenting when I realized I can't possibly remember everything I did the day before. Lots of time I delay library release because docs aren't perfect :wink:

For people are looking for alternate for Arduino WiFi shield;-

We have few threads about it:

Replacement of Arduino WiFi shield - WIFI router(openwrt compatible), Pogoplug, Raspberry Pi .

WIFI router Tp-Link WR703N for Arduino

WIFI router Tp-Link TL-WDR3600 for Arduino

Pogoplug for Arduino wifi and even housing and power supply

The bottom line is to start testing wifi with Arduino , all you need is used/junk PC plus few dollar wifi usb stick.

Hi Luidr

Thanks for the welcome and my apologies for taking a whiles to get back to you.

Documentation, I think it is always a balancing act between too much information and too little, for the target audience. I would prefer to see a little more detail but I am 40, not 14. I might, being kind, describe the Arduino docs as refreshingly sparse :wink: The docs are too the point and they say, what they say, very clearly. In some ways, that makes the documentation better than having reams of distracting information to sift through.

Completely agree reflashing the WiFi shield is a pain in the behing and needs a method to verify which version is on the shield. There is a function in the library but mine is still returning V1.0.0 after I thought I reflashed it. I couldn't find any command for the Atmel DFU which would just report version either. I guess I am just going to have to fork out for an FTDI cable, just to check the version.

As for the WiFi shield. I very quickly lost any expectation that it would 'just work' after my first experiments. I could have blamed Arduino but instead, I sat back and had a little think about what I was asking my tiny Uno board to do. I don't think it is so much the shield might be shoddy, as cramming a Wifi stack, IP stack and DHCP, DNS clients onto an MCU friendly board, is a fundamentally difficult thing to do. When I bothered to think about it, it turns out implementing a web server on an MCU is a pretty big ask.

I can't really say why Arduino have arranged the hardware as they have but the hierarchal arrangement mirrors how network protocol stacks are implemented. In a PC or Mac, the WiFi adapter only looks after the datalink and physical layers, with the rest of the stack residing within software drivers and APIs. Even the cheapest of cheapest WiFi routers has much more RAM and a little more runtime available to it, than an MCU.

I had a quick scan through the code on the thread you posted. I don't know whether this will help you but it is just what has worked for me.

I had some issues with the board crashing when I tried to run the serial at top speed. I am guessing that the MCU is being starved of run time. The crashes stopped after I dropped the serial rate to 9600.

The reset button has locked me out ,once. When I looked at my code, it was entering a tight loop, polling a pin. A rearrangement of the code, to avoid needing the loop and all is well.

The WiFi shield has occasionally refused to start but only immediately after uploading a relatively large sketch. Press of the reset button and all is well. I am not losing sleep over it, because it is a failure mode which should never happen in production.

By far the most common cause of my code crashing, has been buffer overruns. If there is a 90 byte limit, I have yet to trip over it because I have been too busy learning to manage my Uno's memory more efficiently and dynamically.

The way the example web server sketch implements HTTP, is plainly wrong. It works as a proof of concept but enters the realms of undefined behaviour, as far as the HTTP spec is concerned. The example is all a bit confused really. It declares a response as HTTP/1.1 and proceeds to behave as HTTP/1.0

To be perfectly honest, implementing a web server is probably the worse first network project anyone could pick, because there is so little RAM to buffer requests and responses. HTTP is an extensible protocol but it is an extremely vague protocol because of it. It would be much easier to write a raw sockets application with the application protocol designed to fit the limitations of the device. That wouldn't suit what I have in mind though.

Thanks Matt,

I have thought about making an MCU web server might be a difficult project but with my background using MCU and C++ I took on it and think I did it with acceptable results. The server will serve only .htm, .js, and .csv files. It translates .js files according to a rule I implemented so that the static web page gets dynamic contents through running the .js file :slight_smile: I implemented all possible buffer overrun guards (so the server is easy to anger and spits out 404). Soon after I switched to the original R3 (no firmware upgrade) and kind of original library (I have no idea of the version, dated january 2013), the server has been running well for 3 straight days, serving static htm pages with .js files for dynamic content. I can even access it from external network using the router’s external IP address. All is well (but the same can’t be said with the “latest” firmware + library). I think by adding UDP service in the latest thing they created some issues in the firmware or library. Please take a look at this post, where I “solved” the problem of latest stuff won’t work with iOS by reverting to original R3 and lib:

BTW, I am using MEGA 2560 (8K SRAM) and could slap on a QuadRAM for up to 512KB SRAM. I didn’t. I have about 4.7K free ram at the moment, which can further increase after I auto-gen some code with strcmp_P to compare strings with ones in PROGMEM instead of SRAM :slight_smile:

For you to see if the 90-byte limit exists, just do a long string like:

          client.println("HTTP/1.1 200 OK"\r\nContent-Type: text/html"\r\nConnnection: close\r\n\r\n<html>Just a test to see if wifi shield can send a message longer than 90 bytes.</html>");

The above message is about 160 bytes long. You would expect this will not work. According to member pylon, who looked at the firmware, there is a 100 byte buffer on the wifi MCU and it refuses to send if the message becomes longer than 90 (plus overhead will exceed 100).

BTW, the reason I use HTTP is the existing browsers in every mobile device. I don’t have to write a GUI, just need to draft a web page. I think it eventually pays off, if I can make the server into a nice finite state machine.

I agree that the WiFi shield is not ready for serious projects. I bought three of the shields for a project that requires stability and reliability. I run the webduino web server shell and the 1/19/2013 WiFi shield firmware.

One shield consistently runs 10 to 20 days and then crashes. Another with the same software/firmware goes 3 to 5 days and crashes. I bricked the third one trying to update the WiFi_dnld firmware and have not been able to figure out how to recover it. When I run the procedure for updating the firmware from the Arduino web site everything seems to go successfully, but the shield only puts out a red error signal on its led instead of connecting to the LAN.

Also, if there is a power failure my LAN router takes longer to recover than my arduino/WiFi. If the LAN is not ready when the arduino is powered up, the WiFi shield never connects to the LAN. Likewise if the LAN drops out without a power failure the WiFi shield loses connection and never recovers.

Ditto on the comments regarding lack of revision control or even being able to figure out what the revision levels of the various softwares and firmwares are. I have to keep a notebook with the revisions since I cannot digitally read that information from the board.

Also, there seems to be no way to restart the WiFi shield with anything like a watchdog once it drops connection. The only way to know it has failed is that it does not handle remote requests. At that point I am 100 miles away and can't reboot. So my simple fix is to reboot it once a day with a mechanical lamp timer. Doing that, I cannot store any volatile variables in the SRAM for more than 24 hours.

Hopefully this mess will get straightened out by crowd action. In the meantime my project is on hold because the WiFi shield does not operate stably.


Thanks for sharing your experience with me. I for a while I thought I was the only one bothered by various things around this hardware and everyone else is happy.

If you try the basic web server sample code, how long will it take to crash/fail to accept incoming connection? I have not tested that long of a period. I only tested my own web server code for up to 3 days with occasion access from my mobile devices and various PC browsers. I wonder if there is any instability within webduino, which I have not used yet. Plus, have you noticed that once the call to server.available() takes more than a millisecond, rather 25ms, the server has failed to accept any incoming connection? I found that to be very consistent but that was with the "latest" firmware. I was successfully updating the firmware, not so lucky during the first few tries.

What about your experience with wifi shield being a client? My work depends on the wifi shield being a client, not yet server.


I am somewhat new to WiFi shield, but here are my observations:

I have only run in server mode, not client.

  1. I tried sample code and had a lot of trouble when I created my own simple denial of service attacks. I have three computers and would hit the send button simultaneously. Usually I could lock up the WiFi shield in a few tries. That code uses server.available() but I did not do any real time testing of that call.

  2. I found an forked wifi version of webduino on github and used it as my basic webserver. Then I modified the webduino web server code examples in the webduino repository for WiFi instead of ethernet. This was very easy. This setup was much more robust, but still crashed after a day or so.

  3. Then I reflashed the shields with the WiFiHD.hex update that went on github on or about 1/19/2013. I thought there was some improvement.

  4. In the third week of February 2013, the webduino code got a bug fix that also improved the crashing. Now I am able to get 10 to 20 days of operation with my best setup. That's great, but I have not figured out how to debug something that only fails every 20 days! I don't know if my remaining problem is webduino related or shield firmware at this point. I have been sitting it out for the last two months to see if something else popped up in the community that might be the final fix.

  5. I have not gone back to the basic sample code to see if the firmware update improved crash frequency on that. I picked webduino because it did a good job of handling "post" inputs which I wanted for remote control of some lights. I can't use a static server that only returns data. Also, webduino is a "black box" shell that isolates me one level away from having to deal with the ins and outs of controlling the WiFi shield directly.


If I have time I will test my own server code with the original R3 shield. I only had 3-day test periods. Any chance that you are using String class? I think webduino is not using String class. From a quick glance, it seems to be a library you can use to dynamically construct a web page that embed your arduino input values and control arduino outputs. I have a totally different approach to arduino web server so I won't be using webduino much. What I do is a bit of a place-and-switch. I will create a static web page in an HTML editor, then ID all key elements that may be filled with values determined by arduino readings. I then embed a JavaScript to update key element values at the end. It's a huge time saver when it's initially set up. I'm still testing though :slight_smile:


I believe webduino does support string function.

They have these two inclusions in the source code:
#include <string.h>
#include <stdlib.h>

I have read that there were some bugs when using strings in the arduino IDE, but I don’t know if that has been fixed.

My code uses simple strings and I have not had any problems with them.

My web page is pretty simple and therefore easy to directly write in HTML. I have tried using a web page editor, but they put out so many lines that I would have had to implement in a way that webduino could handle that I thought direct writing of HTML is easier.

Currently I am running mega2560 arduino because my program code is 44K size. I have lots of libraries for real time clock, webduino, and other functions. have not tried to squeeze it down for Uno because I also wanted the additional pins of the mega for future expansion of the project.

Folsom Webduino.JPG

The string.h is entirely C-string so should be safe. You want to watch out for the String objects with a capital S.

Just curious, if you hit refresh, how long does it take to reload the page? A second or two, or tens or seconds?