Go Down

Topic: Thumbs way down for Arduino WiFi shield. Read before you buy (Read 144430 times) previous topic - next topic


I followed those steps and didn't get a working shield afterwards :)

I then inserted that extra step and the flashing worked. I use usb cabel to power my shield and disconnect it from arduino. It works like this:

1) flash the "antenna firmware" with jumper wire in place
2) remove jumper and power cycle the shield (now the firmware in the shield MCU actually flashes the antenna firmware) just kind of wait for some minutes to be safe.
3) insert jumper again and flash the wifiHD firmware
4) remove jumper and connect shield to arduino.

Please confirm you can get your shield working with the above 4 essential steps.
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter



Your procedure worked well for reflashing.  I got a blue light on the wifi shield when I did the power cycle between the two actual reflashing steps.

I still do not have a shield that works.  It connects to the LAN (shows in both serial debug readout and on the LAN router), but does not respond to a browser input.  I am using a known good program that works on my 2 other wifi shields.  I think my wifi shield is probably just defective.

I don't understand why that would be because the at32uc responds properly to FLIP program and verify, and the network sees the wifi radio working at the proper address.



Have you noticed that the MAC address that is printed on the sticker attached to your wifi shield does not match the actual MAC?  When I look at the MAC on the router it is totally different than the sticker.



Have you noticed that the MAC address that is printed on the sticker attached to your wifi shield does not match the actual MAC?  When I look at the MAC on the router it is totally different than the sticker.

The MAC address is different from the sticker. I think the sticker is just a serial number. I have 10 shields that I documented both MAC addresses and stick values. One of my shields always returns EE:EE:EE:EE:EE:EE as MAC address with any sample code and connection conditions and I was able to return it for an exchange at sparkfun. One other shield also had a broken inductor and I returned it for exchange. Your shield may be defective as well. I am not ranking the wifh shield Quality Control process very high. 2 defective against 10 working out of a dozen shields is a bit too high to be good quality on my book. What I have been doing the last week or so is to find a way to compile projects to run on raspberry pi. Took a lot of hacking and code borrowing to get serial port to work. I still can't get the millis() to work yet. I was able to run this camera on my Debian box so I will test it on pi too. Wifi is cheap with a dongle when there is driver for the pi. The pi has much better network connectivity. What type of project are you using the wifi shield in? Maybe try a pi + arduino combo?

Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter



I've been gone but not forgotten!  I have been working with my three wifi shields over the last two months.

I requested an exchange of my one totally dead wifi shield.  That one had been DOA.  It connected to the LAN but never had responded to the browser.  The vendor verified that the shield was not working and arranged an exchange with Arduino.

When I received the exchanged unit it worked, but still had reliability problems

On all of my shields I have been running the firmware that is currently in the GitHub repository that is linked from the Arduino official web site page that documents the update procedure.

From a poster on another topic I learned about the new firmware needed for IDE 1.0.5.  As near as I can tell the only place to find these versions is in the hardware folder that comes with the IDE 1.0.5 install package.  The old stuff seems to still be up on GitHub in the firmware repository.

I updated wifiHD.elf and still had poor reliability on all three shields.  Then I found somewhere in the documentation that BOTH wifi_dnld.elf and wifiHD.elf should be reflashed with the versions of IDE 1.0.5.  I did that and have seen a significant improvement in reliability.

Reliability is much better, but not good enough.  I put two shields on life test in server mode using the 1.0.5 firmware.  Both did much better than with previous firmware.  Previously both repeatedly failed within two days.  With the new firmware I have gotten 5.5 days on one shield and it is still operating.  The other shield ran 3.1 days and then failed.  The symptom is the same as previously, browser timeout and it never recovers.

I think the new firmware is a big step in the right direction.  I will keep the still operation shield on life test to see how long it goes.  I could have variation of reliability between shields due to manufacturing tolerances.  If so, one should consistently do better than the other.

How is your project going?


The old good news / bad news story:

I put two shields on life test using IDE 1.0.5 after reflashing both wifi shields with the firmware that came in the IDE "hardware" folder when I downloaded version 1.0.5.  They performed far longer than any tests I have done before.

One stayed up for 14.5 days and handled 190 hits.  The other stayed up 8.8 days and processed 169 browser hits.  The bad news is that they both locked up almost simultaneously.  Since they were both on the same power strip and on the same LAN I think there was a glitch either in the AC power or the LAN.  My uninterruptable power supply did not record any anomalies.  Whatever happened it did not knock them off the LAN, but caused both to stop responding.

These tests results were much better than any I recorded previously.  Most of the previous tests failed within a few hours or a couple of days.  So the firmware upgrade did make a big difference.

There is still one thing that the shields don't do: They don't restart themselves after they have become non-responsive.  As near as I can tell they continue to be connected to the LAN, but they just stop responding to a browser connection.  I have a routine in the sketch that loops on reconnecting if the arduino powers up after a power failure, but in this case the power did not fail.

Once I had held the arduino cpu reset buttons down for 5 seconds, both shields began responding normally.

It seems that the wifi shield should have something like an internal watchdog test in its firmware that can determine that the shield is not responding.  Then it could reinitialize itself if there is a problem. 

I don't know of any other device that I have hooked to my LAN that just goes off line and cannot become responsive on its own.

My analysis:  Things are considerably better with the new firmware (good news), but still Thumbs Down because the wifi shield does not have trustworthy reliability on a network (bad news).  This is still just a toy until further improvements are made.


Sep 04, 2013, 04:29 pm Last Edit: Sep 04, 2013, 06:19 pm by pico Reason: 1
Here is a cost-effective alternative to WiFi shields for wireless Internet connectivity:


Some code examples, too, to see how to write an Arduino webserver, send emails, tweets, updates to Xively etc...
WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)


Sep 08, 2013, 11:22 pm Last Edit: Sep 09, 2013, 06:44 pm by pietkuip Reason: 1

This may show the limits of open sourced products.  Unlike a commercial product nobody is responsible if an arduino product does not function.  So they can continue to sell these wifi boat anchors for $90 without risk of market or legal forces.

I do not agree. Arduino must be responsible for the Arduino WiFi shield that I bought recently. Yes, it worked, but only with 1.0.2. So I need to update the firmware if I want it to work with the Due.

The instructions for updating at http://arduino.cc/en/Hacking/WiFiShieldFirmwareUpgrading are terrible. Macports was a huge problem - I only managed to install dfu-programmer after removing all the other ports. The script does not work - keeps complaining that I am not root. Even though the instructions say that the Mac version does not require root and even when I believe that I am root. I gave up and try to borrow a Windows computer, using the Flip program by Atmel.

But was not the whole point of Arduino that it did not require familiarity with Unix and all that?

PS: Problem solved, thanks to Jamel Abiadh: https://plus.google.com/105267239702578406691/posts/7G7D2ra3pQe


Another update:

Running life test on three shields.  One runs for about 10 days before crashing.  Another makes 3 days usually.  The third has never made it more than 36 hours.  All tests were done in server mode.

This is running the latest wifi_dnld.elf and wifiHD.elf firmware and then compiling with IDE 1.0.5.  By the way, after loading the firmware, you must compile with 1.0.5.  Using 1.0.4 will not work.

I would have to say that even with the latest firmwares the official wifi shield is still thumbs way down due to reliability issues.  It does work fine if you only need to run your project for a few hours and then restart it.


I absolutely agree with liudr that the thumbs way down. For me there are to many limitations by the Arduino WiFi Shield. I bought two of them and I will sale them. But I think it is not fair to resale my Shield to a other person with the knowing about all this limitations and my own bad experience. 


Nov 17, 2013, 06:14 pm Last Edit: Nov 17, 2013, 06:28 pm by SurferTim Reason: 1
Running life test on three shields.  One runs for about 10 days before crashing.  Another makes 3 days usually.  The third has never made it more than 36 hours.  All tests were done in server mode.

That sounds like the complaints about the ethernet shield until just recently. Both my client and server sketch examples work good now, even subjected to brutal internet attacks. Read this thread.

I bought two of them and I will sale them. But I think it is not fair to resale my Shield to a other person with the knowing about all this limitations and my own bad experience.

How much would you sell one for if you knew it was going to someone who had at least a chance of getting it up and running?  :)

edit:...and is willing to share with everyone how to do it.


Running the wifi client is not too bad but this is no industrial solution :) I bet raspberry pi can handle longer stretch of time since it runs a full OS. If anything goes wrong, the OS would attempt to restart service, right?
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter


Nov 18, 2013, 11:05 am Last Edit: Nov 18, 2013, 12:35 pm by SurferTim Reason: 1

Running the wifi client is not too bad but this is no industrial solution :) I bet raspberry pi can handle longer stretch of time since it runs a full OS. If anything goes wrong, the OS would attempt to restart service, right?

I don't know about that. With the full OS, you have all those services running that can be hacked and crashed. With the Arduino, there is no full OS to expose vulnerabilities to hackers.

The ethernet shield is no problem for the Arduinos, especially the Mega 2560. Mine has been running exposed to the internet for over two weeks now without a problem. If programmed correctly, I imagine the wifi shield could be as reliable.

The advantage of the Raspberry Pi would be in security like SSL, but that does not guarantee a hack-free system if you are not a sharp programmer. The more complexity, the more security holes.

edit: I have been offered a wifi shield as a loan to test with by a forum member. I guess we will find out about the reliability of the wifi connection. While we are waiting, feel free to try to crash my Mega/ethernet shield. My only request is if you crash it, please tell me how you did it so I can patch that bug.


Nov 18, 2013, 01:37 pm Last Edit: Nov 18, 2013, 01:44 pm by MattS-UK Reason: 1
Sorry, what I am about to say may sound picky and I don't want to be disparaging, but your code has issues.

First of all.  When I look at what your shield is doing in Wireshark, most of the packets are ~50 to 60 bytes.  Your shield is framing data,  1 character per TCP packet, most of the time.  I got a couple 118 byte packets, so it is possible for the shield to be more efficient.

Second.  You are playing fast and loose with the HTTP protocol.  Most modern browsers are very tolerant but some user-agents are not.
Code: [Select]

//HTTP Request
GET /index.htm HTTP/1.1
Connection: keep-alive
Accept: text/html

//HTTP Response
HTTP/1.1 200 OK

<HTML>// etc...<HTML>

Issue 1.  You declared a HTTP/1.1 response but this is not a HTTP/1.1 response. If it were, you would have to include
Connection: close\r\n
Because the user agent sent you

If you include those headers, you should not immediately close the session but rather, provide the client some time to close the connection gracefully.  If the client does not close the session gracefully, you may then presume it is dead and forcibly close the session.  

The behaviour of your server, closing the session immediately after servicing the request, is much closer to HTTP/1.0  So why don't you declare that ?

Issue 2.  You should not be putting line breaks in your headers.  Headers are name:value pairs with the syntax
header_name: value_1;value_2 \r\n

There is an interesting point about protocol interpretation to be made here.  From what I recall, the RFCs don't specifically say you can not put a line break in a header.  They do not say you should either.  By including the line break, you create an edge case - A scenarios outside of the protocol specification.

I am impressed that you have made your server as robust as you have.  If I can help you with the nuts and bolts of the protocol stuff, feel free to ask.   I would not want to compare the Ethernet shield with a WiFi shield just yet though.  The WiFi shield has some additional failure modes and a nasty 2 Second delay inherent in servicing the transmit buffer.  2 Seconds is an age in network terms.

The WiFi shield is not entirely without merit though.  My NTP clock has been running about 2 weeks now and is happy to roam across non-overlapping access points.   The WiFi shield seems perfectly suitable for blatting a few 100 bytes per minute around using UDP, as far as I can see.

Whether simplicity is it's own security is an interesting debate, verging on being a thought experiment.

On the one hand, for your simple approach, you are having to write bespoke code with, limited trial and error testing, to serve a very simple page.  Your code does not conform with the protocol standard.  You are almost at the limit of your resources and there may still be edge cases you have yet to come across.  So yes, there is not much chance of your Arduino leaking data but there is quite a chance of it not being very robust.  It is robust in the scenarios you have tested, for which I congratulate you.

On the other hand, utilising a Linux SoC provides access to Apache, lighttpd, php, perl, python and all sorts of other sophistication.  Of course one does not have to use all that one could use.  Stopping/uninstalling unnecessary daemons will ensure they don't get hacked.  What packaged code is used, will conform to protocol specifications and is extremely well tested.  Should an exploit come to light in say Apache, it will be found, patched and retested by the Apache team, very quickly.

I am not saying either way is wrong, you understand.  Just you need to make a choice appropriate to the purpose.  For now, I feel the the SoC route is more appropriate to my purposes.


Nov 18, 2013, 01:51 pm Last Edit: Nov 18, 2013, 02:01 pm by SurferTim Reason: 1
Nice catch on the \r\n in the Content-Type. That was my bad. I am fixing that right now.

You correct about fast and loose. But I am working with very limited resources, so...

It returns "file not found" when the correct response should be "bad request", and vice versa.
It can be DoSed easily, but it doesn't crash.

edit: It is fixed.
If the w5100 is sending smaller packets than it should, that would be in the firmware. The SD page uploads should load the tx buffer with 64 bytes, then send the w5100 an exec command to send that packet. ??

Go Up