WiServer Lives!

When I originally wrote the WiServer for this project, I figured it might be useful for a lot of other projects. Async Labs thought so too, so I've been working with them over the last few weeks to incorporate WiServer as part of the official WiShield software stack. Today it finally went live and is now in their GIT repository on GitHub. At this point WiServer does pretty much everything that QPID needs it to do, but I'll continue to enhance WiServer by optimizing the code and maybe adding new features.

It's not everyday that tasty bbq results new open source software...

QPID Shield

I've finally made some 'real' hardware for QPID. I created a custom Arduino shield that includes all of the special hardware and connectors required by QPID. It includes connectors for the temperature probes, a connector and power transistor for the fan, and seven SMT LEDs on the foil side that will serve as indicator lights.






I used software provided by ExpressPCB.com to design the board and match the Arduino dimensions and header layout. It was then printed on a transparency and etched via a positive-resist process. Homemade PCBs aren't the best, but they're cheap and easy to make for prototypes like this. And it sure beats a breadboard.

The Full Slab

With the new stack's client mode capabilities and some new code in WiServer, QPID now has all of its communication capabilities! In addition to serving up web pages, QPID can also send periodic status updates and urgent alerts via Twitter, which in turn can be forwarded to a mobile phone via SMS. At this point I've hit about 17k out of my 30k code budget including the favicon, so there's still plenty of room for more enhancements.

I really need to build some more permanent hardware. My plan is to design a PCB that'll plug right into the headers on the WiShield, only I'll place the components on the underside except for some surface-mount LEDs. That way I can mount the entire assembly against the front surface of an enclosure and be able to view the LEDs through a window. I'll also add jacks for the temperature probes and fan, and those will align nicely with the power and USB jacks on the Arduino board.

I'll include LEDs to indicate power, Wifi connection, data transmit, data receive, and three LEDs to indicate temperature state (blue, green and red, of course). One other feature will be feed Vin to an analog input using a voltage divider; in the future I may go with a solar panel and battery pack instead of an AC adapter, so it'd nice to have a way to monitor the supply voltage... and of course tweet if it starts to get low. :-)

Stack Issue Resolved

Sure enough, the stack code was incorrectly calculating the TCP MSS value:

Re: Memory Corruption Bug Found in g2100.c

Now that the WiServer code is nice and solid, it's time to turn my attention to the hardware once again...

Naughty, Naughty Stack

I started noticing some erratic behavior with my code, and after some digging around it looks like the WiShield stack & driver have a memory corruption issue. The default setting creates a 400 byte buffer, but then the driver code writes 417 bytes into it. Hmmm, that's not good. I submitted details to Async Labs, hopefully they can fix it soon.

In the meantime, I've set the TCP window size to 300 bytes and added a 'safey malloc' to put a little space between my data and the stack code.

Stress Test - Passed

With the new stack and the WiServer up and running, I decided to give it an overnight stress test. I configured the web page to have an automatic refresh interval of 30 seconds, and then brought it up on a G1 phone browser connected via WiFi. Eight hours later it's still chugging along and reloading the page every 30 seconds. Next I'll test it with a few different browsers running on different devices, but the results of this first test are very encouraging (the old stack inevitably locked up within an hour at most).

New Stack Software, New Headaches

Over the weekend, Async Labs released a new version of the stack for their WiShield. 'New version' may not be the best choice of words because it's pretty much just 'new'; they ditched their old custom TCP stack and instead ported over uIP to work with the Wifi module. Needless to say, the WiServer code would no longer compile, let alone run. But on the bright side, the use of uIP means simultaneous support for both client and server connections, which means email alerts and tweets from my smoker will be coming soon.

Thankfully, uIP is a very stable and mature piece of open source software, and in addition to lots of comments in the code, there's also a great reference manual to explain the overall design and usage. So it took me a few hours of reading, hacking, reading again, and cursing at odd compilation errors to do an initial integration. I'm glad to report that QPID just served up its first web page using the new stack. It's messy, unstable code right now, but it works! :-)

Over the next few days I'll clean up and solidify the uIP port of WiServer, then I'll get back to working on the QPID-specific stuff.