The idea is simple. You just enter into your PC the UPC of everything you throw away or recycle. Why? Because these are the items you are likely going to repurchase when you make your next shopping run. With the list of UPCs, we can create a shopping list. This is accomplished with PantryTech, and the optional PantryPod. With a little more effort, we can create a list that is sorted by Store, and even the Aisle within the Store.

PantryTech

PantryTech is the application program that runs on your home PC. This application actually runs from within a web server. This is really quite easy to setup, and gives you a familiar web interface to work with. You can do everything from your home PC, by entering the UPCs into a form on a web page. Or, you may want to consider PantryPod...

PantryPod

PantryPod is the electronic device that has a barcode scanner attached to it. It is also attached to your home PC via a home network. With PantryPod, you simply grab the scanner, scan the UPC on the product package you're tossing, and listen for a confirmation beep.

Note that in this PantryTech demo, a sample of many, but not all features are demonstrated.

The Step-By-Step When you're ready to toss a product container, you remove the scanner from its cradle. Power to the scanner is then enabled. Scan the product UPC, and then toss it. The UPC code is passed on to the home PC. The home PC program determines if it was a valid UPC (validity is based on it existing within the PC dB). The PC provides a return code to signal success or failure. PantryPod then provides audible feedback to the user of that success/failure. Repeat as needed, then return the scanner to the cradle. Power to the scanner is removed. At the PC, the list of items is viewed via a web page, where it can then be printed or transferred to a handheld.

System Level Block Diagram:

Process Diagram:

Link to a UML like diagram...

Bill of Materials:

• Cue Cat or other Barcode scanner, which connects as a PC keyboard wedge. The data is clocked at between 10 and 40 kHz rate (depending on the site you refer to) as an 11 bit clocked asynchronous frame.
• Sound generator (Piezo speaker, or something more elaborate, but with a 1-wire control). This provides a pleasant beep confirmation feedback of a successful scan and some raspberries if it failed. 
• Local node that can control the power to the keyboard, read the keyboard signals, drive the sound generator, and communicate to the host via TCP/IP.

I/O Requirements

• Clock, Data @ ~40kHz: USART, SPI, or Polled pin and an Interrupt line
• Network Interface
• Pin for tone generator
• Power control to the Scanner if we also have a local wakeup signal (momentary switch). Then, it can go to low power mode until it receives a local wakeup. It can then power up the scanner until 1 minute after the last scan or until it is returned to its cradle.

Local Cache of UPC codes

Ideally, the device should communicate every UPC scan to the host immediately. Then, it can provide audible feedback if the code was in the PC dB.

A performance and data safety plan is that the device should acquire the list of valid UPC from the host and store them in a local cache. It can then take the UPC just read and add it to the local outbound queue of UPC codes. If it can find the new UPC code in the local cache, it can signal success instantly. If the same UPC exists in the outbound queue, it should increment a product count. The next step is to push the entries in the outbound queue to the home PC where a companion program can further collate the list, and signal success to clear the local cache. If the home PC is not available to receive the records, then the trash scanner will periodically try again. If the local cache storage space is nearly exhausted, it should alert the user by some means (perhaps blink the scanner off and on, or a very tiny audible tone).

When the user wishes to print a list, the home computer may interrogate the trash scanner for any pending cache entries, compile the list of UPC codes, then using either an internet database, or a local database, it will translate the UPC codes into a product list and print it. If the product list is not stored locally, then it should perform the internet lookup sometime prior to the immediate need to print this list. This will reduce the delay- to-print time, and increase the user satisfaction.

Candidate Solutions:

Candidate solutions are presented in the order of most appealing, based on a variety of factors, including simplicity to implement and of course the cost to implement it.

Common to All Solutions

All devices are 10 Mb devices, so there are spare wires on that drop. Low voltage power can be passed down the line by creative splicing to a small power supply at the hub. This minimizes the additional wiring and power necessary at the PantryPod.

EtherNut

Turns out this this is the winning solution! It is reasonably small, has lots more I/O than this project needs, is programmable in C, is provided with open source software, gnu compiler and is just a little pricey, but when you consider the cost of tools too, it seems to be quite a reasonable price-point. There is a mailing list as well. Learn more at http://www.ethernut.de 

Notes:

There is a growing community of support. There exists drivers for many I/O types, including relays, MP3 players, IDE and CF hard drives, LCD's and more.

Other Contestants

Here are a few other devices that could be used in this project.

Rabbit

A Rabbit is natively programmable, I would expect it to read the bar code data stream directly. The rabbit has plenty of RAM and so should be able to cache the UPC's locally until the home PC is available to receive them. The Rabbit has plenty of I/O and so should be able to read the keyboard, control power to the scanner, and to drive an audible device as needed.

Notes:

Good support, not too many problems (by monitoring the mailing list). Compiler technology is unique - a custom dialect of C.

Summary:

A good runner up to the EtherNut.

TINI

Using a TINI, it is believed that a native keyboard interface should be possible. If this is the case, then the TINI can operate by locally caching the UPC list, and attempt to push it to the home PC periodically. The TINI has significant resources locally, so this should not be a problem.

Issues:

Can TINI read a keyboard data stream without loss?

Summary:

This device appears to be the most costly solution.

SitePlayer

Using a SitePlayer, which is only just (and with limitations) natively programmable we could have the smallest implementation. This custom software needs to read a clock and data line from the CueCat, cache the UPC locally, and communicate to the home PC.

It needs to be confirmed whether the SitePlayer can initiate transactions with the home PC. If it can, then it could notify the home PC of new shopping list codes. The home PC can then retrieve them from the SitePlayer web site. It is believed that the web page cannot contain an arbitrarily long list of UPC's, so it may have to iterate with a GetNext function. In case the home PC is offline, it will need to be able to cache UPCs locally for a period of time.

Issues:

SitePlayer, from monitoring the mailing list, has way more problems than it is worth, and virtually no support or upgrades for about a year now. The code is proprietary, and it doesn't have the power to do this without another micro.

Can the SitePlayer initiate a transaction to the home PC?
How many codes can the SitePlayer cache?
Can the SitePlayer web site list all of the currently cached codes at one time?
If not, how does the GetNext function interact between the home PC and the SitePlayer?

Summary:

This device is the smallest solution, and probably the least costly, but will require a host microcontroller. Also, this device cannot originate transactions to the host, except by UDP, which would change the entire host side infrastructure.