I am trying to capture rs422 data with a proprietary word length and marker set (start/parity/stop). The convertor salesman assured his would do the trick - what I found out was that the pc based system eats the 422 data thinking it is 232 type protocol word frame markers! so for any amount of true data on the 422 side, the 232 convertor port level shifts it bit for bit, but the darn comm port/uart register only gives me 8 bits. Any data outside of the 8 bits will be dropped until the comm port interprets it as the proper start and stop markers used with 8 bit systems.

I have searched for 422 + pci in an effort to find a product - no luck as far as I can tell.

My constants on this project are 422 fixed word definition, the PC and Visual basic.
hoping someone can help guide me.

Thanks

 

If the word length is > 8 data bits + parity the classic PC UART cannot cope with this format.

You could use one of our programmable converter modules (http://www.proconx.com/xnut100/) and sample the RS-422 signal in software and then convert it to an 8-bit sentence which can then be read either on the second RS-232 port or via Ethernet.

We have implemented similar solutions to the read the 26-bit Wiegand proximity reader format.

Henrik Maier
--
proconX - Protocol Converter, Device Server and Industrial Gateways
http://www.proconx.com Tel: +61-402 970 933 Fax: +61-7-3009 0399

 

Standard uarts can be adjusted to data format in a wide range.

If this is not sufficient for your needs, you have to build a decoder of your own, either by software or by hardware, depending on data-rate and speed of your system. Good luck!

LargoD

 

Standard RS-422 uses the same data format as RS-232. The only difference is the voltage levels. If you have some device that produces timing protocol that is outside the definition of 8-bit data with start bits and stop bits, then you will need to make a matching proprietary decoder. Exactly what is the proprietary word length, data format, and bit rate? We can program a PIC for you that would read medium-speed data in a proprietary format and re-send that data out in standard RS-232 format after converting the data format. Contact me through the moderator.

Robert Scott
Real-Time Specialties
Embedded Systems Consulting

 

What is possible is to make a converter yourself. Using a PIC16F628 you can produce a protocol converter. Use bit-bang code for receiving anything you like in any order and length (hey! you are the programmer!) and use the hardware uart to send te data in RS232 to your PC. Is absolutely doable if the RS422 feed is not too fast (say 19k2 on a 20MHz PIC).

just my $0.02

Da fripster

 

RS-485 and RS-422 both refer to electrical standards used for data communications. Neither implies any message or character formatting and the information can be anything the user desires. It is entirely possible to use RS-422 driver and receiver ICs to determine whether a switch at the other end of the wire is opened or closed. The switch might be open or closed for an indefinite period of time. This represents the low end of the data rate that is possible. In normal use, the upper end of the communications link is of more importance. There is a limit as to how fast the signal can change and still be detectable at the other end of the cable. RS-232 is a single wire standard (plus a ground return) that uses +12 / -12 volt levels and is limited as far as distance driven. RS-422 was developed to allow greater data rates and distances. It is a differential signal that uses 0 / +5 volts on one wire and the other wire uses +5 / 0. The receiver then looks at the difference of the two signals to determine whether a "1" or a "0" is being sent.

At a higher level is the data sent across the line. Either "normal" asynchronous or synchronous (SDLC/HDLC/Bisync/Monosync/etc.) bit streams can be sent equally well. All that is important is that the receiver knows how to decode the data pattern sent. All Universal Asynchronous Receiver Transmitters (UARTS) are set up to follow a standardized format. There is a Start Bit that should be one bit period long, followed by 5 to 8 data bits, each 1 bit period long, an optional parity bit (1 bit period long), and a Stop Bit (either 1, 1.5, or 2 bit periods long). The start bit is used to notify the receiver that a character is going to be transmitted. The receiver then starts examining the incoming data stream at 16 times the expected data rate and usually will then verify that the stop bit is still valid by sampling it again around the middle of the bit (8 sample intervals). If it is still valid, then the UART will discard the bit (since it is only for synchronization) and wait 16 more sample intervals, which will be the middle of the 1st data bit (D0). The value of this bit is then saved in a shift register and the process repeated until the specified number of data bits has been received. The process is performed one more time if a parity bit has been specified and once received the received data bits are examined to ensure the parity is correct. The receiver then waits another 16 bit times to check the Stop Bit. Since the Stop Bit is actually a dead interval between characters, the line must be idle during the entire Stop Bit period. If not, a Framing Error is declared and the character is assumed to be bad (usually caused by mismatched transmit and receive data rates). The stop bit is also discarded by the receiver since it is not really a data bit but rather an intercharacter interval. This sampling is why the oscillator fed to a UART is normally 16 times the maximum data rate you expect -- i.e. a 1.8532 MHz oscillator is used to allow 115.2K baud communications.

There are some UARTS that support a 9 bit protocol and use the parity bit as an address / data indicator. In this case those UARTS (i.e. Oxford Semiconductor's 16950/16954) will pass this 9th bit back to the CPU in a separate register. The software driver can then pass this information back to the user's application if the program interface allows it.

If you really need to see all of the bits (which is true for RS-232, RS-422, EIA-530, RS-485, etc.) then the hardware needs to use a USART (Universal Synchronous Asynchronous Receiver Transmitters) in a "raw" data capture mode and capture the incoming data stream and decode it manually. While this is possible (and is done routinely on microprocessors that do not have a hardware UART), it is not trivial. Because your application will not have a direct interface to the incoming bit stream, you would have to set the receiver in "raw" mode, receive the incoming stream at a rate at least twice (remember Nyquest) the bit rate (although 4 times or more would be better), and then look at the bit pattern in the bit stream to decode the bits yourself. In this mode if there were 1 Start Bit, 12 Data bits, no Parity, and 1 Stop Bit the incoming data stream could be "1001110001101" (binary) with D0 first while the stream you would then read would be "000...000 1111 0000 0000 1111 1111 1111 0000 0000 0000 1111 1111 0000 1111 0000" (note: spaces inserted for clarity). You would also have to be prepared to be slightly out of sync with the transmitter so some of the fields might be either 3 or 5 bits long.

Sealevel Systems (http://www.sealevel.com) offers a wide range of asynchronous and synchronous serial products that support RS-232, RS-422, RS-485, RS-530, etc. I’m sure they will have something that works for you and their tech support staff has always been helpful.