Burn-In Carts

October 6, 2017
6 min. read

This post is part of the Burn-In Cart series.

Over the last 5 years, I’ve been working on a very small team as the sole Engineer designing a ruggedized Android tablet. The only product option that met our needs would cost 10 times what we could afford. These are to be produced and distributed free of charge in developing nations as a missionary tool. Due to the cost and effort involved in getting them in country, our goal was a tablet with a 10 year service life.

Through many iterations of unique designs for case, battery, and other features, we believe we have accomplished this. The proof will be in the mortality rate, once units are in the field for a long duration.

Part of this goal is to quickly identify issues with the tablets before shipping. In general, electronics will fail quickly or last for a long time. The goal of burn-in testing is to shake out this infant mortality and quickly get those back into rework and identify problems. To accomplish this task, I designed and built custom burn-in carts for our tablet production.

In this article, I’ll go over the general design goals and methodologies I chose to implement this system. Some parts of this system will just be interesting for readers, but others may address certain conditions that may be useful in building your own hardware or software projects. Future articles in the series will cover more detail on both hardware and software implementations.

Tablet Details

Our tablet design started as a USB charged tablet, because that was how things are done. However, in really looking at the problem we were trying to solve, we realized that a USB based infrastructure does not really exist where these are going. With no AC power, old 12V car batteries are often the normal voltage grid. An industry exists to get your battery charged for a reasonable fee. This combined with the low power transfer capable in USB cables, we moved to a 12V barrel plug configuration. For people who have not seen much technology, the barrel plug is easy and robust.

To fully cycle tablets automatically, we will need to provide 12V power and a method to activate the push button power switch. We will also need a method of communicating state back to the cart.

Cart Overview

The physical design is a rolling cart with 208V power and ethernet connectors on top. Each side holds 6 columns of 12 tablets for a total of 144 tablets in 12 columns of 12. We cannot pull enough power to charge every tablet at the same time, so I have individual power switching for each tablet. We also need to actuate the power button on the tablet. This makes for 288 data bits for power state and button state.

The main power for the cart is a 1.5KW (12V 125A) power supply. Each tablet charges at a max of 1.8A at 12V. This is over twice the power capability of normal micro-USB cables and ports. Charging every tablet at the same time, would require almost 260A of current. Discharge time is much longer than charging time, so we really don’t have any cycle time limitation with only being able to charge less than half the tablets at one time.

There is enough space to see the tablet screen at an angle while sitting horizontal in the cart. Early designs did consider having screens green for complete, red for error, and others for cycling. This has limitations of requiring a somewhat dark environment and an operator to walk up and down between the carts to check for issues.

Initial tablet designs did not have WiFi capabilities in the tablet. However, once this was integrated in for other uses, we had a mechanism to communicate with the cart. Now we could have a WiFi access point in the cart and a single display with a 12x12 grid for the state of each tablet.

Although I looked at larger HDMI and USB touch monitors at first, I settled on the Raspberry Pi 7” touch display. It sends display and gets touch over a single flat flex cable and is large enough to convey progress and error conditions for each tablet. This is the same cable used by the camera interface. I was able to test a 6 feet length of cable past some electrically noisy devices and still had solid touch and display.

Tablet Web Service Calls

Custom software runs on each tablet and calls to the cart’s web service for various conditions. If power is applied, power is removed, shut down started, boot up completed, or if 5 minutes has passed and it has not called the web service for other reasons. With each call, we receive data on the tablet and return a configuration for the tablet. This indicates the various settings and tasks the tablet should be operating.

By logging battery condition and temperatures, we can gather statistics for each cycle to see how this tablet measures against previous tablets. We can reject tablets if not within performance parameters and look to see if the issue is battery, display or PCB related.

Web Display and Web Service

Flask was chosen for the Python library to create the web service and web server. We do not need the extra overhead of a larger system, such as Django. The web service will accept a call from a tablet and dump it into a SQL Server database. The web server will have a overview page and a detail page for each tablet. This data is pulled directly from SQL Server.

At first I tested a few frameworks, such as circuits, to tie the web architecture to the workflow architecture. The complexity didn’t yield much gain. By storing data to be displayed on the cart in the DB, we lose a little in speed of update on the cart display. However, we are dealing with a system that will run for 48 hours at a time. Half a minute in screen refresh really doesn’t matter.

By having everything in a database, we can have an aggregating web server that displays the condition of one or all of our carts in progress. Instead of walking to check all carts, this can be done via each user’s desktop browser. This is a huge gain.

Workflow

The workflow process is just an continuous loop until every tablet in the cart is complete. A state machine is used to control the tablets process through the testing plans. This is the heart of the testing operation and fairly complex, so I’ll be dedicating at least one article to this.

That should give you enough of an overview of my goals to see how subsystems will work together. I’ll save any more to further articles in this series.


Part 1 of 3 in the Burn-In Cart series.

Raspberry Pi Hardware Mocking

comments powered by Disqus