Automated Wireless Testing

Above is a picture of the Cart and Turntable (nicknamed "Saturn"). Since I was dealing with a radio and receiver, all devices had to be constructed out of wood and PVC. No metal allowed within a foot of the table tops. For motor controllers and various sensors I used a brilliant little company's products called Phidgets. I then designed a network protocol so the main device controller could communicate to the on board systems of the Cart and Saturn via Cat-5. Here are a couple pictures of the UI.

Above is the advanced script generator. The script file controls the device's positioning and this program allows users to develop a more complex script in a matter of minutes, opposed to writing it by hand -which would take hours considering most tests have more than 12k different testing positions (over 48 hours worth of testing). Below is a short clip of the Cart and Saturn in action.

A more simple version of the script generator -built into the control application. Most of my users ended up using this feature. The blue circles are the turntables on the devices. They spin according to their corresponding angle settings. Both turntables have a resolution of 15 degrees, and the range (distance down the track) for the cart has a resolution of 25 cm. All in all, the system requires two PC's. One computer for conducting tests, and the other moves the robots. This minimizes USB traffic, a major concern at the time considering we were testing USB devices. The "test name" is merely for logging data and keeping the test unique. The "Batch to Execute" is a simple program written on the remote computer that executes when the devices get in position -it conducts the throughput measurements (a much more advanced script written by the hardware department).

Above is where the user sets up the track specifications for the devices. This keeps the robot from going off the end of the track, which would trigger its limit switch (resulting in a test failure). More about the app: I wrote the program in C/C++ using the MFC library by Microsoft. I started the project not knowing any C++. My experience in Java helped me learn everything I needed to know, and the rest I consulted with fellow co-workers -who oddly enough were developing our products in C++. I learned how to create and manage new threads, how to create AFX messages, compile for multiple platforms, I even wrapped it up into a nice little installer package so anyone could jump in and use it.

Above is a view of the test in progress. All readable text is updated in real-time when an event happens on the devices. This feature really helped debug all the issues I ran into.

A look at some of the error handling in the application. Since the devices are controlled via USB 2.0, a disconnect feature needed to be implemented. This allowed the test to recover in the case a control device decided to re-enumerate. USB in its early 2.0 stages had a nasty habit of not playing nicely on the Windows XP driver stack. Most importantly, this project taught me about error handling (diagnosing a 12k point test is fun), creating a user friendly interface, & multithreading. These devices are no longer in use today, WiQuest Communications Inc. went under in October of 2008. Some of the smartest people I ever met worked there, and I certainly can say I learned a lot. Not just about automation engineering, but also about developing a product and making it user friendly.