Remote Activation of Appliances using USB Interfaces

Group 5

Chris Hydak

Vanessa Cox

Kaori Wada

Abstract

Our focus in our project is to remotely activate a device on the USB port of a desktop computer using a remote device, a NEC 800 handheld, connected through RF signals. The device which we have chosen to control is a QuickCam camera. To achieve this we will need also to convert the USB signals to a standard parallel signal.

I. Introduction to the project and background research

There are two main sections that our project consists of: (1) the interface between the QuickCam VC camera and the USB port of the computer. (2) the remote communication between the NEC 800 and the desktop computer. We chose to interface using the following parts.

  • An XC4003E Xilinx FPGA (to see a pinout see Appendix A)
  • A Paradigm PDM41256 256KB RAM
  • A National Semiconductor USBN9602 Full Speed Function Controller with DMA Support
  • A Logitech QuickCam Vc camera with parallel port.

To see the wiring diagram see Appendix B.

The second major part of our project is the communication between the NEC 800 handheld and the desktop computer. We don’t have the exact specs on which transmitter/receiver pair or transceiver that we are going to use yet.

For the software side of our project, there are five major components: (1) The USB driver that talks to our USB controller on the desktop PC. (2) The serial driver on the PC which talks to the transceiver. (3) The serial driver on the NEC which talks to the transceiver. (4) The camera viewer on the PC. (5) the camera viewer and camera controller on the NEC.

A.XC4003E Xilinx FPGA

The Xilinx XC4003E FPGA, is a Field Gate Programmable Array which allows the user store programmable logic on the chip. This particular model has 84 pins and accepts a 5 Volt input source.

  1. USBN 9602 Full Speed Function Controller with DMA Support

The USBN 9602 is an integrated USB Node controller compatible with USB Specification 1.1. Integrated onto the chip are USB transceiver, Media Access Controller, USB endpoint FIFO’s, MICROWIRE/PLUS, and an 8 bit parallel interface. There is one mandatory control endpoint and six unidirectional endpoints that support USB interrupt, bulk and isochronous transfers. For this project, we will be using the parallel interface and only the bulk transfers. With the USBN 9602, 2 24ohm resisters and one 1.5k ohm resisters will be used on the USB D+/D- connection (Figure 1).

The chip is controlled by setting up the register values on the chip. There are 28 pins on the chip with 8 data or address lines, 2 GND, 1 Vcc, 1 V3.3m, 6 control pins and 10 setup and clock pins. We used the parallel interface of the chip and the Xilinx to interface with the chip. The address, functionality and the setup values we used for this project of each register is given in the appendix.

C.Paradigm PDM41256 256KB RAM

PDM41256 is a 32K x 8 CMOS static RAM chip. It consists of 15 address pins, 8 I/O pins, chip enable, write enable, and output enable. Writing to the RAM is achieved when the write enable and chip enable are set LOW. Reading from the RAM is achieved when write enable is asserted HIGH and chip enable and output enable remain LOW.

D.Logitech QuickCam

The camera we will be using is the black and white version of QuickCam, since the camera has already been reverse engineered and the commands for the camera is already known. The camera has a parallel interface that we will be using to read the data.

It operates in six different capture modes, 80x60, 160x120 and 320x240 with either 4 bit color or 6 bit color (shades of gray). The memory requirements are from 2400 bytes for 80x60 resolution for 4 bit color to 57600 bytes for 320x240 resolution with 6 bit color.

E. Verilog Code

The verilog code that is downloaded into the Xilinx chip supports 3 different functions. The first function is the interface for the USBN9602 chip. The USBN9602 has an USB transceiver that can transmit and receive USB data and convert it to parallel. The USBN9602 interface will use the parallel interface to transmit and receive USB data to and from the host. The second component is the Camera Interface. This code will generate the correct control signal to control the camera and read the picture data. The third component is the address generator/memory controller. The address generator will generate the address for reading and writing to the 32K RAM and the controller will implement the timing of the reaad and write.

For example, if the user would like to take a picture, the user will click on the PC. The PC will send the correct signals through the USB to the USBN9602. The USBN9602 will read the data and send it to the camera interface. The camera interface will decode the data and send the appropriate command to the camera. After the camera has taken the picture, the camera notifies the camera interface. The camera interface will start the address generation for the 32K RAM and start to write the data into the RAM. After it is done, the camera interface notifies the USBN9602 interface that it is done. The interface then setsup the USBN9602 for bulk data transmission and transmits the data to the PC through the USB. The PC will receive the data and then display it on the screen.

For all three components to work properly, timing issues are very critical. Since all three components, USBN9602, 32K RAM and camer, have their own timing constraints, synchronization must be implemented. An internal 8MHz clock on the Xilinx will be used. The RAM and the USBN9602 can use faster clock for optimal performance but for our project the 8MHz clock will be fine.

E.GUI
A.File Menu
  • New – dumps the current displayed image
  • Open – open an existing image
  • Save As – save the current image
  • Exit – exit the program

B. Help Menu

  • Contents – tells basic operations and what the error messages mean
  • About – displays project title and team names
C. Take Picture Button
  • gets an image from the camera and displays it below

D. Status Box

  • shows what operation the user has selected
  • displays any errors possibly encountered

(i.e. during the image transfer, etc.)

III. Individual Achievements

A.Vanessa Cox

Responsibilities

  • learn how to read the images that are
  • coming in on the USB port
  • create the GUI for the NEC
  • create the GUI for the PC
  • write the device driver for our camera
  • test and debug all of the above

Accomplishments (semester)

  • Read about USB
  • Located the Paradigm RAM specifications
  • Designed a schematic of how the RAM would interact with USB and the camera
  • Helped the group in designing and hooking up the interface between the USB and camera
  • Read about Visual C++
  • Decided on how the GUI would appear and
  • the functions that it would perform
  • Created the GUI with Visual C++, giving it partial functionality
  • Read about writing USB drivers

The first couple of weeks were spent finding any possible information on USB that was relevant to our project. I searched the internet, library, and book stores. This included looking for possible hardware that could be used.

The third and fourth weeks were spent doing much of the same. I found the specifications on the RAM that is to be used and created a schematic for how the USB and camera would interact with that RAM. However, in the group, we got a better idea of how the interface should be designed, so the schematic was updated. Kaori took on the task of writing the Verilog code dealing with the RAM, due to the fact that the code for the USB controller that she was working on called for intense interaction with the RAM module.

For the fifth and sixth weeks, I have been learning Visual C++. I created a basic GUI for the camera operation so that it can be used on WinCE and the PC. There will be a difference in the functionality between the WinCE and PC GUIs because the function for taking a picture will change. The GUI does not have complete functionality at the present time. Among the available functions, are File|Open, File|Save As, File|Exit, and Help|About. Right now, when the take picture button is pressed, a message is displayed in the Status box that a picture is being taken. The take picture function is where the image transfer will be instantiated.

I found some source code that will display the information that is being transferred at the parallel port. I believe that this will be a useful debugging tool in regards to the QuickCam.

The C++ libraries available do not support jpeg format. To display an image on the GUI in jpeg format, I searched and found a C++ library that will aid in displaying jpeg images at

Further, I have been learning about writing USB device drivers. Our USB device needs a driver to talk to the device and respond to kernal or user application requests.

  1. Chris Hydak

For this project my responsibilities are:

  • Drivers from the NEC 800 to the serial port.
  • Drivers from the desktop computer to the serial port.
  • Wiring the project to the breadboard and ensuring that the hardware works
  • Along with Kaori, testing the USB converter design using the logic analyzer
  • Creating the webpage for this project.
  • Research and integrate the camera into the design.

I have accomplished the following:

  • I have wire wrapped the project to the breadboard
  • I have created a sample webpage of our design at
  • I have set a listserve, which we could communicate through.
  • I have researched the camera interface

For such an enormous project, I felt that it was necessary to break up the project into three subsections: the USB converter, the NEC conversation with the desktop, and the Desktop interface with the USB converter.

Our initial focus has been getting the USB converter to operate correctly. We have tried to research each part thoroughly to make up for lack of experience in the hardware aspect of our project.

Most of my work is to reinforce Kaori and Vanessa. Even though I have not done much on my own I have been apart of numerous discussions on theory and application.

  1. Kaori Wada

For this project my responsibilities are:

  • My main responsibility consists of writing the verilog code that is used in the Xillinx. This includes the USBN9602 interface, camera interface and the address generator.

I have accomplished the following:

  • Understand USB and how it works
  • Understand USBN9602 and how it works
  • Written a test program that will initialize the USBN9602 chip and will allow the PC to recognize it. The program was test on the Xilinx simulation.

My main responsibility in this project is the design of the verilog code that will be downloaded into the Xilinx chip. The first couple of weeks, I spend reading the USB specification and books on USB interface and USB architecture. I also read the past projects on NetCam and the problems they had. The functions of the verilog code and the Xilinx chip is given in section II.

Next I read the specification for the USBN9602 and the programming that it will require. Then I wrote a table (appendix B) specifying what each register does in the chip. Then we tried to simulate the program using the parallel interface of the active wire but failed to make it work. Then I wrote a small test program that should initialize the chip and connect to the host. The test program was simulated on the Xilinx simulator and we plan to test it using a logical analyzer this week.

The main problems I have encountered are the bugs on the Xilinx software and timing issues. I have had to create new projects since after too many alterations, the code will not compile anymore. I also noticed that this version does not support some of verilog useful functions, such as “initial” and “wait”.

The timing issues is very complex also, since we use 3 different devices, all with different timing constraints. Therefore one must wait until the other finishes. However, I can not

IV. Modification

The project has significantly changed since our proposal at the beginning of this semester. We have decided to implement a USB hub interface that will connect the QuickCam to the PC. We originally wanted to use a LED for the second device but decided to use the QuickCam for both devices. However, we will not use the two QuickCams but only connect them to a different endpoint. This implementation will not be exactly like a hub implementation since the USBN9602 only has one device id but will be able to simulate hub functionality by using the six endpoints provided by the USBN9602. The hub will use the device id to send the right data to the right device, we will instead use the endpoint address to send the data to the device.

The other half of the project consisted of using an USB RF transceiver to communicate between the PC and NEC. However, since there is no USB RF transceiver available, only a development version which they could only release to us in December, we will use a serial RF transceiver instead.

  1. Conclusion

Most of the technical issues we have encountered were due to our lack of experience in hardware. However, since the beginning of this semester, we all have a much better understanding of hardware concepts. For example, we learned the consequences of pulling too much current, timing constraints for different ICs and the method of reading data off a wire. We were under the assumption, that it would be easy to read data off a wire, however , it is very complicated since one must figure out which voltage cutoff points are high and low and timing is very critical. Therefore, we decided to buy the USBN9606 chip.

Some of the other problems we have encountered during the first part of our semester was trying to find a USB RF transceiver that either did not exist or the source code was not available. Trying to find a USB RF transceiver took up a lot of time, since we thought we were not looking in the right place, when in fact, they do not exist at this time. We tried to get the Bluetooth from Ericcson, which is a developmental USB RF transceiver. However, after playing phone tag, they told us that even if we were able to get the developmental kit, they could not deliver it to us until December. Last, after receiving the QuickCam VC, we found that it would not work with our project since the company would not release the specification of the camera and they were using a proprietary compression algorithm for their data.

The past two weeks we have made major progress. We learned a lot about how to connect all the components of the chip and to read the specification very carefully. This week, we defined our entire chip pin outs and the connections. We also wire wrapped the board and were able to download a test verilog code onto it. We were planning on testing the sample code with the logic analyzer but encountered strange problems with the Xilinx software. The verilog compiler kept getting errors on a line that was commented out. Therefore, we fixed the problem earlier this wee and plan to test it wtih the logic analyzer at the end of the week. However, we were able to test it on the simulator on the Xilinx board. We also solved some of the timing issues for the different chips.

VI.References

Ciletti, Michael D., “Modeling, Synthesis, and Rapid Prototyping with the Verilog HDL”, Prentice-Hall, 1999.

Anderson, Don, “Universal Serial Bus System Architechture.”, Addison Wesley, 1997.

Cant, Chris “Writing Windows WDM Device Drivers”, Miller Freeman, Inc., 1999.

Chapman, Davis “Teach Yourself Visual C++ 6.0 in 21 Days”, Sams Publishing, 1998.

Xilinx tutorial which includes the piout for all standard 256 KB RAMs

USBN 9602 data sheet

A FAQ on interfacing Quickcams

A website devoted to Quickcam development for Linux

Xilinx tutorial on how to connect the Xilinx to a protoboard

A Xilinx tutorial on how to connect to a parallel port

Xilinx tutorial on how to connect to a Connectix Quickcam

The Xilinx homepage

The USB implementor’s forum site

The webpage for our 40 Mhz oscillator

The Paradigm website for the memory module

Activewire

Parallel Port Debug Tool

Appendix A

1 / GND / 42 / Vcc
2 / Vcc / 43 / GND
3 / CS / USBN9602 / 44 / A7 / PDM41256
4 / INTR / USBN9602 / 45 / A3 / PDM41256
5 / RD / USBN9602 / 46 / A6 / PDM41256