Maker Pro
Maker Pro

Serial communication problem.

Hello everyone.

I am working on a project that requires computer serial RS232 communication and i am getting some weird behavior on it.

I have a source of rs232 serial data (idle low -15V) that feeds data to a PC and at the same time (in parallel) to a card that reads TTL rs232 (+5V idling at 0V if i remember correctly).

I use a max3232epe chip to convert the idle low rs232 signal to TTL. When the MAX3232 chip is powered on everything is normal but when i kill power to the max chip the computer that is in parallel with the max3232 chip's input reads gibberish.
When i remove connection to the max chip or restore power to it then the computer starts to read correctly again... Weird, right ?

Ofcource this is a part of a larger circuit... i could just use a relay to isolate the pc input from the max chip when the max is not getting power but then i would have to redesign my pcb and that i dont want to do unless i find no other solution (that would be by absolute last resort).

Here is the diagram of my circuit.

Im really not an rs232 expert but i know some here are ! Any ideas ?
 

Attachments

  • max chip.png
    max chip.png
    15.7 KB · Views: 217
Last edited:
You should use bi-directional data buffers for each serial data path and enable them as required via the power line (and an inverter gate between both enable lines).

Paralleling serial data lines is a 'no-no' (technical term)
 
I am not familliar with what you are suggesting me... Again i would like to investigate why that is happening and why it is ony happening while the Max3232 chip is switched off.

I put them in parallel only because both the PC and TTL device are "receivers" and they would not send anything back.

I would like you to explain me in a little more detail your method if you could please.

Thankyou.
 
The MAX device will only operate in a known state whilst powered up. When powered down you don't know what condition the various pins attain (the datasheet may well reveal all) but it's obvious that the device, in it's powered down state, is affecting the data lines (loading them).

The use of a buffer device will electrically isolate the pins on the MAX device and prevent any effects from disturbing the serial lines.
 
The net effect you're looking for is to replace SW3 and SW4 (or add in series) with the bi-directional (tri-state) buffers, the enable line(s) of which are connected to the supply feed to the MAX device such that when the power is off the buffers are in their tri-state mode and thus 'isolating' the data lines to/from the MAX device.
 
1. Rs232 or TTL is communication between 2 devices and if you try to connect more things on the bus, you could get weird behavior.

2. Secondly, you can use pull up or pull down depending on what MAX datasheet suggest to keep the signal stable on the power up.
 

hevans1944

Hop - AC8NS
Here we are in the 21st Century and some people are STILL farkling around with "RS-232" serial data protocols. I once worked with a technician in the 1980s who seemed to make a career out of connecting two devices using "RS-232" cables he would custom wire for the purpose. He was your "go to" guy if you had two devices to connect together and both supported some version of the RS-232 standard. Back in the day, the only real confusion was what to do about the DTR (Data Terminal Ready), DSR (Data Set Read), CTS (Clear to Send) and RTS (Request to Send) "handshaking" lines after you got the RD (Receive Data) and TD (Transmit Data) sorted. But if you really wanted to "make his day" ask him about RS-423, or RS-422 or (my all-time favorite, pre-Ethernet) RS-485. Surely by now there are fiber-optic alternatives that seamlessly integrate into multi-drop low bandwidth serial receivers?
 

davenn

Moderator
The 74LS series won't do true serial due to supply line limitations (no ability to go 'negative') but is ok for 'fake' serial lines (i.e. TTL levels) but there are many dedicated devices that do.
...............

so, why mention the need for tri-state buffers then ??

those MAX chips are switches, not buffers
 
Here we are in the 21st Century and some people are STILL farkling around with "RS-232" serial data protocols.

The way i see it is that the RS232 is a fairly simple protocol. In my case though the way the rest of the system is designd(not by me), it can accept nothing else but RS232 and RS422. The RS232 suits my needs better.
In other words, i had no option about the comm protocol :) .
 
I was always amazed at how they came up with 25 wires to do 2 way 1-bit communication. RS-232 has to be the the best example ever of what is euphemistically called "design by committee."

Bob
Thats right...
The systems i have seen so far only use TX,RX and GND pins :)
 
so, why mention the need for tri-state buffers then ??

those MAX chips are switches, not buffers

Well... Im not sure what a tri-state buffer is... I dont think a "switch chip" is what i need because i need it to keep the RS323 input hooked on the PC when there is no DC voltage present.

I guess a buffer would be the way to go since it would isolate the rs232 input from the max chip thus enableing me to have both the max chip and pc phisically connected in parallel with the RS232 source at all times.
 

hevans1944

Hop - AC8NS
Well... Im not sure what a tri-state buffer is...
TTL (and, earlier, DTL) used so-called "totem pole" outputs that could either source a small current (for logic 1 level) or sink a somewhat larger current (for logic 0 level). That means any given output was either driven high toward Vcc or driven low toward ground or logic common.

If you needed multiple outputs, acting independently, to drive one or more inputs, you also needed some way to disable (disconnect) all inactive outputs, placing those outputs in a third state that neither sinks nor sources current and therefore, logically, has NO DEFINED LOGIC STATE. Such a device is said to have tri-state outputs: logic zero, logic one, and undefined.

When the outputs of one or more devices with tri-state outputs are "wire-ORed" together, only one device can have its outputs producing legitimate logic zero and logic one levels. ALL other devices must have their outputs placed in the "tri-state mode" where their outputs neither sink nor source current. It's as if a SPST switch, connected in series with each output, was placed in the open position.

ANY integrated digital logic circuit can be equipped with tri-state outputs, along with one or more "enabling" inputs that allow an output to behave like a normal logic-level output, or force that output into the "tri-state mode" and effectively disconnect that output from whatever inputs it is attempting to drive. Since tri-state operation is a Johnny-come-lately to digital ICs, many complex ICs that need tri-state functionality simply have their outputs connected to buffers (either inverting or non-inverting) with tri-state output capability. This is clearly a waste of valuable board space if an equivalent IC that already has tri-state capability is available. But, back in the day, this wasn't always the case, and many digital logic circuits were developed on wire-wrap boards, which made it fairly easy to add the requisite tri-state functionality... even late in the design cycle. Just add another socket and move a few wires.
 
Hello everyone.

I am working on a project that requires computer serial RS232 communication and i am getting some weird behavior on it.

I have a source of rs232 serial data (idle low -15V) that feeds data to a PC and at the same time (in parallel) to a card that reads TTL rs232 (+5V idling at 0V if i remember correctly).

I use a max3232epe chip to convert the idle low rs232 signal to TTL. When the MAX3232 chip is powered on everything is normal but when i kill power to the max chip the computer that is in parallel with the max3232 chip's input reads gibberish.
When i remove connection to the max chip or restore power to it then the computer starts to read correctly again... Weird, right ?

Ofcource this is a part of a larger circuit... i could just use a relay to isolate the pc input from the max chip when the max is not getting power but then i would have to redesign my pcb and that i dont want to do unless i find no other solution (that would be by absolute last resort).

Here is the diagram of my circuit.

Im really not an rs232 expert but i know some here are ! Any ideas ?

There should be no problem with your basic design,
there is no "collision" and thus no need for buffers etc.

You have one transmitter feeding 2 receivers and that should basically work (see drawing).
Although it is not strictly according to the RS232 standard.

There are some issues with your design:

1.You don't show the GND-signal wires of the transmitters.
Did you connect them,and how?

2.Caps values are too high(space and price!)
If you are indeed using the max3232epe you should use 0.1uF (not 10uF).

3.No need to connect resistors on the unused transmitter inputs of the IC,
leave them open.

4.R2 is not needed

Lastly do you have a scope to measure signals?
 

Attachments

  • 232.JPG
    232.JPG
    50.6 KB · Views: 100
I was always amazed at how they came up with 25 wires to do 2 way 1-bit communication. RS-232 has to be the the best example ever of what is euphemistically called "design by committee."

Bob

Bob,
You shouldn't be ,not at all!
The DB-25 connector is indeed a "design by committee" 'it is a design of the early 60's and held for 40+ years.
There was a great need for "supporting signals" to the basic Tx,Rx,GND signals

It was designed that way for simplicity and with a global look at the future needs.
At that time computing power was very limited and very costly,the era of large computers no PCs etc.
Thus the need for the simplest H/W handshaking and timing(synchronous mode) was essential !!!
Remember the communication speed of 300baud modems???

Let me say they did a great job ,and as the saying goes,the proof is in the pudding !
The connector existed from the 50's,was available and low priced.

Most pins are used for H/W handshaking protocols(with DCEs like dial up modems etc.),
some are used for synchronous signal transmission,
Other for testing(loop-backs),
and some for a secondary com. channel.

They all had there very good and lasting use!
 
Dear dorke generally speaking, you are right but i disagree with your opinion about leaving unused inputs "floating". here i explain in more detail:

You have one transmitter feeding 2 receivers and that should basically work (see drawing).
Although it is not strictly according to the RS232 standard.
Well on my project i use two wire communication (TX and GND from source RX and GND to receivers) but the block diagram you made is correct.

1.You don't show the GND-signal wires of the transmitters.
Did you connect them,and how?
You are right, I have indeed connected all grounds together, both the transmitter,receiver and max232 hooked together.

2.Caps values are too high(space and price!)
If you are indeed using the max3232epe you should use 0.1uF (not 10uF).
Max232 datasheet suggests 1uf not 0.1 but i used 10uf because it was suggested on the datasheet of the system im working on. I dont think that is causing the problem though.

3.No need to connect resistors on the unused transmitter inputs of the IC,
leave them open.

4.R2 is not needed
In my opinion it is never a good idea to leave unused iputs floating... On the max 232 if you leave unused pins floating they tend to force the chip to oschillation overheat and eventually falure, see here:
https://electronics.stackexchange.c...3232-overheating-burnt-after-connecting-to-pc
After hours of testing, i came up with this diagram that has actually never made the max chip overheat and fail.

This problem makes me scratching my head... On one hand i know for sure it is the max232 chip that is causing the problem and that alone... On the other hand i have no idea why.

Lastly do you have a scope to measure signals?
I have one but not around right now... i may be able to take some scopings on thursday.
 
Top