Maker Pro
Maker Pro

Help needed for transmitting 15V signal to 10 metres at 8KB/s using RS232 or RS422 cable

I'm trying to send and receive data using micro controller connected with external peripherals. Data line is equipped with 15V so I want to send 15V data over 10 metres with 7 data lines at 8KB/s. Can I modify the dedicated pins in RS232 or RS422 cable and can we change voltages to these cables to 15V? For example can I change the default pin operation of RS232 (DB9) to 5 pins act as output, 2 pins act as input and these 7 pins transmit at 8KB/s and remaining 2 pins are +15V & 0V.
 
Last edited by a moderator:
Why don't you simply use a serial connection RS232 with 56 kB/s (7*8 kB/s)?
Hi,
I just confused with pins and voltage levels in these standards that's why I asked with my requirement. Most of the RS232 interface IC max voltage is 15V in IC parametric search so can I use IC with 15V? Or can I use transistor or MOSFET for individual signal line?
 

hevans1944

Hop - AC8NS
I'm trying to send and receive data using micro controller connected with external peripherals. Data line is equipped with 15V so I want to send 15V data over 10 metres with 7 data lines at 8KB/s. Can I modify the dedicated pins in RS232 or RS422 cable and can we change voltages to these cables to 15V? For example can I change the default pin operation of RS232 (DB9) to 5 pins act as output, 2 pins act as input and these 7 pins transmit at 8KB/s and remaining 2 pins are +15V & 0V.
Where did you get the idea that RS232 or RS422 standards specify a nine-pin DB9 connector and nine-wire cable? And why do you want to waste seven data lines to transmit data at such a slow rate as 8000 bits per second? And why do you think that supplying power (+15V & 0V) over the wiring between your micro controller and external peripherals is a such a good idea, because it isn't?

Why don't you tell us what you are trying to DO, and let someone here give you some advice on how to do it? The usual way to implement a slow data link is with a serial asynchronous data protocol. This is done with a pair of dedicated UARTs (Universal Asynchronous Receiver Transmitters) at each end of the data link. A typical data protocol is 8-bit or 7-bit ASCII (American Standard Code for Information Interchange). Baud rates of several hundred thousand bits per second are supported in dedicated hardware UARTs, as well as in software emulations of UARTs executing on high-performance microprocessors.

As for changing the default pin operations of an RS232 or RS422 cable... it's your project, do whatever you will.
 
On the micro end, just use a RS232 MAX232 for example, the charge pump provides the 8.5+/- v.
The transmitting end can be any RS232 device.
Now it is not customary to use the handshake lines, just the TX/RX lines.
M.
 
Hi heavens1944,
I just customized RS232 standard to DB9 for my project. I'm in need to alter the existing project so in that system 7 data lines carrying 15V signal and 8 KB/s is new requirement. Peripherals connected with 15V so I need to carry 15V is must here and I have to use voltage level converter to interface with micro controller. For this reason only I didn't use single line UART.

You can use the pins/wires in a cable with D-SUB 9 connectors in any way you want.
As for changing the default pin operations of an RS232 or RS422 cable... it's your project, do whatever you will.
I got a big relief with above two quotes.

Hi Minder,
the charge pump provides the 8.5+/- v
Please explain above quoted, I didn't understand.
 
Any particular reason for 15v?
The power for each Conversion IC's is derived at each source and IC's such as the MAX232 is typically used now.
Power +ve is not included in RS232 transmission.
That distance is not overly far for RS232 unless going super high baud rate.
M.
 
Any particular reason for 15v?
At peripheral end 15V is powering the shift register(CD4094BC) and this IC gives the ON/OFF signal to peripherals. Data line from micro controller connected with shift register so I'm in need to give 0V, 15V to input of this IC . That's why I'm asking 15V data line is required. Am I understand correct with datasheet?
 

Attachments

  • Datasheet.jpg
    Datasheet.jpg
    64.1 KB · Views: 4
I assume the external peripherals have their own contained RS232?
If so and you are using a microcontroller, why the CD4094 if using standard RS232 protocol?
There are other ways of producing RS232 with dedicated IC's.
Doesn't matter what the peripheral end is using, either IC or voltage.
I must be missing something?
M.
 
In peripheral side not having RS232, it just having ULN2003 and in micro-controller side, data was carried by each IRF540 via data lines in existing system.
Why I choose RS232 standard means, there would be loss of data at 8KB/S in future system. In existing system speed rate was nearer to 70B/S. Will the existing system(IRF540+ULN2003) is enough to carry data without loss?
There are other ways of producing RS232 with dedicated IC's
I lag with choosing IC's
I must be missing something?
No, you missed nothing
 

Harald Kapp

Moderator
Moderator
This schematic is incomplete. Where does the clock for the 4049 come from?
Why would you replace the transistor driver in the existing circuit by an RS232 interface?
If the existing circuit works as expected, all you need is a matching cable. As said before, you may use any cable, including an RS232 cable as long as the connections match your transmiter's and receiver's connector.
 

hevans1944

Hop - AC8NS
@Prakash123:

Methinks you don't have a clue about what you are doing, or attempting to do. Why are you using a POWER mosfet as a data transmitter? The diagrams you uploaded are BLOCK diagrams, NOT schematic diagrams. A schematic diagram shows ALL the terminal connections between each and every part or component, typically with labels identifying the function implemented by each connecting wire. You use a SCHEMATIC diagram for information on how to wire a particular circuit. You use a BLOCK diagram to convey the "big picture" conceptual ideas, with details (such as a schematic diagram and bill-of-materials parts list) to follow later AFTER a design is completed. It appears to me that you are nowhere near the design stage of this process and are still exploring concepts... concepts that were more than adequately covered, in considerable detail, in the previous century.
 
So you are converting a non standard RS232 to customary RS232 format.
The Micro end (TX) end should be no problem, i.e. MAX232 etc, the RX end appears to require a conversion to standard RS232, typically the voltage range to achieve this is ±9v with max ±25v. You need a bi-polar supply.
I would suggest studying up on RS232 and IC versions in order to achieve it.
M.
 
This schematic is incomplete. Where does the clock for the 4049 come from?
Clock, data and other control signals are came along with data lines. I'm replacing transistor driver with RS232 because I already said there might be data loss in increasing data rate and this is my doubt.

Methinks you don't have a clue about what you are doing, or attempting to do
I'm in starting stage of my project and I had doubts to clarify before going into project. Because of starting stage I just have only idea of this system so only I didn't have schematic and sorry for mentioning block diagram as schematic.
you are nowhere near the design stage of this process and are still exploring concepts...
Yes I'm in design state and I need to clear my unknowns. Without clearing unknowns I don't want to take part into this project. That's why I asking doubts and doubts.

So you are converting a non standard RS232 to customary RS232 format.
Yes and I would start learning of RS232 and I have to concentrate on RX side.
 

hevans1944

Hop - AC8NS
Why I choose RS232 standard means, there would be loss of data at 8KB/S in future system. In existing system speed rate was nearer to 70B/S. Will the existing system(IRF540+ULN2003) is enough to carry data without loss?
Seventy bits per second (70B/S) is a very slow (and non-standard) data rate. Even 8000 bits per second (8KB/S) is considered a very slow (and non-standard) data rate. Commonly used baud rates for RS232 are 1200, 2400, 4800, 9600, 19200, 38400, 57600 and 115200 bits per second. All of these are faster than your 70 bits per second, and all 9600 and up are faster than your 8000 bits per second. That DOES NOT MEAN that you NEED an RS-232 data link!

If you are losing "data" with your existing low-performance system there is something wrong with it's design, perhaps a fault in your signaling integrity... for example too slow of a transition on data edges, not enough setup time before clocking data into a register, excessive timing jitter between the data and the clock signal, noise on the data signal lines, lack of hysteresis in the data inputs to the receiver... yada, yada, yada. All of these things can be measured, quantified, and compared against device specifications. Sometimes just looking at the data signal line with an oscilloscope triggered from the clock line will reveal where the problem lies. It is necessary to have adequate instrumentation BEFORE attempting to design, much less build, a reliable data communications link. What tools do you you currently possess? Can you obtain the tools you need?

Clock, data and other control signals are came along with data lines. I'm replacing transistor driver with RS232 because I already said there might be data loss in increasing data rate and this is my doubt.
"Might be data loss in increasing data rate" is not sufficient reason to replace the mosfet drivers in the existing system with RS-232 bi-polar drivers. On what facts and information do you base your doubt? You need to examine the signal integrity of the existing system and determine why it isn't performing as expected. A single-ended, high-level, serial data stream should easily communicate error-free data at speeds exceeding 9,600 bits per second. Find out what it wrong before attempting to "fix" it with technology you do not yet understand.
 
On what facts and information do you base your doubt?
Before this conversation I thought that without a suitable communication protocol there would be a data transfer problem and now I realized that there would be no problem at lower speed if circuit design and programming will be in perfect. This is the panic I have because I have to implement in real time

Find out what it wrong before attempting to "fix" it with technology you do not yet understand
Because my electronics knowledge is up to beginner level and I have to keep upgrade.

And I have to work with existing system to troubleshoot.
 

hevans1944

Hop - AC8NS
Before this conversation I thought that without a suitable communication protocol there would be a data transfer problem and now I realized that there would be no problem at lower speed if circuit design and programming will be in perfect. This is the panic I have because I have to implement in real time
Circuit design and programming do NOT have to be perfect. Correct circuit design and correct programming is good enough. There have been many different communication protocols developed since the telegraph was invented. Some, such as serial ASCII, are still being used today because they are adequate for the task at hand. RS-232 and RS-422 define signal levels, not the communication protocols that use them. Your mosfet drivers should provide adequate signal level for reception at the end of ten meters of twisted-pair cable.

Virtually ALL communication channels have to be implemented in real time to avoid loss of data. To be both iron-clad and bullet-proof requires considerable effort and the definition of what is an acceptable UN-corrected error rate in the communications link. If a zero corrected-error rate is desirable AND required, some sort of data verification protocol must be incorporated in the design. You probably don't need to do this with your short path length and high-level signals.

The only thing I would question at this point is the choice of ULN2003 Darlington transistor drivers for use as data receivers. Better would be something with hysteresis on the input transition levels, perhaps this quad CMOS receiver. You can retain the use of the ULN2003 transistor drivers, connecting their inputs to the outputs of the DS14C89A data receivers if you need the high-current capability.

If possible, using an oscilloscope, check the data lines for evidence of overshoot and ringing at the receiver inputs. If either condition is occurring it can cause data errors, but it can often be eliminated by terminating the receiver input with an appropriate resistive load that approximates the impedance of the data cable. Once you have verified the signal integrity of the data, proceed to increase the data transmission rate until either a successful 8 KB/sec data rate occurs, or failure to communicate occurs.
 
Top