Electronic – Connect fingerprint sensor to serial PC

If your "electronic device" has a name and/or a webpage then telling us it may help us help you.

Not all Serial-USB converters are the same.

IF your photocell system used standard RS232 serial communications AND did not rely on "hardware flow control" (RTS/CTS) then it should work correctly in most cases.

As it does NOT work correctly, you need to determine how it differs from the most simple version of RS232 use.

Several main possibilities are worth looking at. There are others.

Voltage levels:

• Your device may use non standard RS232 levels. Correct levels are in the order of -12V/+12V but it could eg use 0 / +5V and still work with some (nit all) serial ports.

Break signalling:

• Some systems that use a serial port do not use the actual TXD/RXD serial system at all but use what is sometimes referred to as "break signalling". A break occurs when the data TX line is held i the non-normally-idle state for a longer than usual period. It is possible to transmit data using this method. This non standard and a poor use of the system but some equipment uses it. Some USB-serial converters do not support break signalling.

A discussion of "break" is given i this useful RS232 tutorial in section 1.4.1 & 1.4.2.
Summarising from there:

• 1.4.1 In RS232-C, a value of 1 is called a Mark and a value of 0 is called a Space. When a communication line is idle, the line is said to be “Marking”, or transmitting continuous 1 values.

  1.4.2 RS232-C also specifies a signal called a Break, which is caused by sending continuous Spacing values (no Start or Stop bits). When there is no electricity present on the data circuit, the line is considered to be sending Break.

  The Break signal must be of a duration longer than the time it takes to send a complete byte plus Start, Stop and Parity bits. Most UARTs can distinguish between a Framing Error and a Break, but if the UART cannot do this, the Framing Error detection can be used to identify Breaks.

The PICAXE microcontroller development system uses break-signalling with all the hassles that go with it and discussions of how these are overcome will be useful in solving your problems IF your problem IS break signalling

Here is a typical PICAXE break signalling discussion

Hardware flow control madness:

It may be that some of the hardware control signals used by your original system are not being dealt with properly by the converter. Below I've provided some comment and a link to a comprehensive reference BUT the easy was around this is to examine the non-data lines on your interface in the original mode (serial-serial) and with the USB-serial interface in place and see if there are any differences. It is often possible to "loop back" or hard wire signals that are not properly being handled.

RS232 implements various means of determining if the transmitter and receiver are ready to send or received data or allowed to send or receive data. These use lines such as RTS, CTS, and maybe CD, DSR, DTR, and in really nasty cases SCD, RI and more.

This utterly superb but massively overwhelming RS232 tutorial discusses these issues in depth with many excellent diagrams, pin descriptions etc.

From here: http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html

In case anyone's keeping score, we picked a different solution.

Our product is based on an LPC1768, and we built the software in such a way that it can support both USB Device mode (the original mode, before we developed the need for a bridge), and Android Accessory mode. Mode selection is based on a jumper setting.