I am scratching my head on this one...

A little back story: I created a python application that utilizes pyserial and runs on a BeagleBone Black that communicates with a proprietary device that has a PIC24FJ256DA210. This device has an RS232 connection available which goes to an SP3232 transceiver. During the initial building of my app, I was not utilizing the BeagleBone Black and was working strictly in a Windows environment and made my serial connection with a USB-Serial adapter. I built the app out to 100% functionality in that environment and everything worked as expected. I then refactored the application to run on my BeagleBone (which is running debian). This is where the head scratching starts as my memory is a bit hazy on what all happened... Initially, due to my lack of knowledge, I just didn't realize I needed to do anything with the signal that was coming/going to/from the UART on the BeagleBone. When I initially attempted to run my application, connecting my UART lines to the proprietary device, it was not working as expected. I happened to have a MAX3232 breakout board/adapter handy, and I connected the proprietary device to my BeagleBoe UART through that, and started to get the behavior I expected. However, I started to experience inconsistent results with my application and after a bit of code refactoring, a new MAX3232 adapter, and who knows what else I did, I am now at my current situation.

So my current situation is that I can transmit to the proprietary device, but it does not appear that I am receiving back the expected data. (Most of the time I am not receiving any data at all). Initially I was thinking I had a ground issue, a baud rate issue or something along those lines...but at this point I do not believe that to be the case. I can connect my beaglebone to my windows PC and send/receive data as expected.

Here is a snapshot of what my device connection looks like to the proprietary device... (I dont have all of the circuit diagrammed here for sake of noise)



Are there any conflicts with this circuit?

 

Where is the rest of your schematic for the Max232? and SP232? I am not famialr witht he SP232. Looks like it is just a different manufacturer? Why are you using 2 different chips and not just 2 Max232?

Do you have a scope or a logic analyzer to watch the data flow?

 

The SP3232 chip is part of a circuit of a third party device that I am interfacing with and have no control over. I left out the rest of my schematic surrounding the MAX3232 chip as it was just the Vcc, GND and capacitor connections.

I have verified that I can write and read from my BeagleBone UART to my Windows PC, so I believe my circuit is fine. I'm just unable to communicate through my BeagleBone UART to this third party device.

I did just connect a Gigaware USB-to-Serial adapted from my BeagleBone and my app works to communicate with the third party device.

I do have a scope I can use and monitor the signals, so I guess I'll take that step next.

 

Your symptom reminds me of what is suppossd to be RS-232 but the signal is only brtween ground and some positive voltage. Real
RS-232 swings at least to -2.5V .

You can check with a scope or
+ and - diode peak detectors
and a voltmetet.

 

I do have a scope I can use and monitor the signals, so I guess I'll take that step next.

It should have been the step you took before posting.

 

@spinnaker fair enough

I have been able to monitor the signals between my circuit and the 3rd party circuit with a logic analyzer. I captured the signals under two different scenarios:

1) Scenario where I am using a USB-Serial adapter from my BeagleBone to the 3rd party device, and my application performs as expected. (The USB-Serial adapter I am using is as seen here... https://www.radioshack.com/products/gigaware-usb-to-serial-cable I have been unable to find a datasheet on it though. Am half tempted to open it up)

2) Scenario where I am communicating via my own circuit which is connected as seen below (In this scenario, my application does not ever receive the expected response from the 3rd party device):

EDIT: I am using 0.1uF capacitors (https://www.mouser.com/ProductDetail/594-K104K15X7RF53L2)



Unfortunately, I have not had any luck with my scope in capturing the transmissions. My scope is a myDAQ (National Instruments) and I may just not be using it correctly.

I may have some flawed logic with evaluating where I am at with my current issue, but in my mind here is how I am looking at it:

1) I know my application does what is is supposed to do as I can run it with the USB-serial adapter and it performs as expected. The only difference is the serial port I am opening up with pyserial (/dev/ttyUSB0 vs. /dev/ttyO4).

2) Using "my circuit", I can send and receive from my Beaglebone to my Windows PC (In this scenario, my beaglebone is communicating over /dev/ttyO4 which is going through my MAX3232 circuit. I am connected to my WIndows PC via the same USB-serial cable)

3) Based on the signal captures I made with my Logic Analyzer (Saleae Logic 4), the data I am transmitting to the 3rd party device is identical between "my circuit" and the USB-serial circuit, up until the time that the USB-serial circuit starts receiving the correct responses from the 3rd party device and continues on.

4) It appears I am simply not receiving anything from the 3rd party device when connected to "my circuit".

@DickCappels - I tried to dwell on your response but, between not getting my scope to perform as I expected it to, and not really understanding how to implement "+ and - diode peak detectors and voltmeter" (I am just a novice hobbyist), I wasn't sure what next step to take. (I did google "+ and - diode peak detectors" but I just skimmed and didn't really grasp how to implement that. I need to go back and look at this again and see if I can wrap my head around what to do there). When you stated that "Real RS-232 swings at least to -2.5V", should I be measuring that negative value only during a TX or RX event?

 

The signal on the data line should be negative when nothing it being sent.You can read this with a voltmeter when no signals are being sent.

RS-232 logic and voltage levels
Data circuits Control circuits Voltage
0 (space) Asserted +3 to +15 V
1 (mark) Deasserted −15 to −3 V

Take a look a the waveforms and singnals on Wikipedia
https://en.wikipedia.org/wiki/RS-232

Some inexpensive serial to RS-232 adapters do not go negative.

 

Finally lucked out on a run with my scope. I am definitely seeing positive and negative voltages. This capture is of the T1_OUT pin of my MAX3232 chip during a TX:



Still trying to grab a reading on the R1_IN pin...

 

This is an improvement

 

When not attempting to transmit or receive, my T1_OUT pin on the MAX3232 is at -5V. The R1_IN pin is at 0V.

I have verified this same behavior connected to a different UART on my BeagleBone and using a different MAX3232 chip.

Is this "static" reading problematic?

EDIT: I just measured similar behavior on my USB-serial adapter, so I suspect this is a normal reading for the idle state it is in.

 

Was finally able to spend some time looking at the Rx line with my scope:



So am getting -5 to +5 voltage swings on Rx as well.

 

I've re-read the data sheets (for what that's worth)...not sure what next step to take. I guess I'll search for another chip to test out.

 

Ugh...maddening. I just changed my circuit to use a MAX232IN chip to test that out...same behavior. My circuit works fine in a loopback test. I connect it to the 3rd party display and my app doesn't communicate like it should. But, I feel confident that my app is fine because if I change the RS232 connection from "my circuit" to a USB-to-serial adapter, I can communicate all day as needed.

 

Hi mbxs3, have you checked the actual timing of your pulses? I did some similar communications using an atmel microcontroller chip, they communicated to the com port of a computer fine, but there was some garbled data when they were supposed to talk to each other.
I sent out a specific data packet, and compared the pulse on / off lengths on my scope between working and not working data setups. It seemed there was a slight difference in timing of the pulses, and in the end I had to change the calibration of the on chip oscillator.

 

Hi mbxs3, have you checked the actual timing of your pulses? I did some similar communications using an atmel microcontroller chip, they communicated to the com port of a computer fine, but there was some garbled data when they were supposed to talk to each other.
I sent out a specific data packet, and compared the pulse on / off lengths on my scope between working and not working data setups. It seemed there was a slight difference in timing of the pulses, and in the end I had to change the calibration of the on chip oscillator.

I agree. That check is a must.

 

Was finally able to spend some time looking at the Rx line with my scope:

View attachment 170015

So am getting -5 to +5 voltage swings on Rx as well.

If you spread that out (wider), you can actually read the binary from it to confirm exactly what is in the signal.

 

Hi mbxs3, have you checked the actual timing of your pulses? I did some similar communications using an atmel microcontroller chip, they communicated to the com port of a computer fine, but there was some garbled data when they were supposed to talk to each other.
I sent out a specific data packet, and compared the pulse on / off lengths on my scope between working and not working data setups. It seemed there was a slight difference in timing of the pulses, and in the end I had to change the calibration of the on chip oscillator.

Um.... this isn't right. This is RS-232C 'protocol' (not really a protocol). It establishes timing with each transmission through a handshake process. Make sure you're not dealing with an variant (like 'E').... see link below for details-

https://www.engineersgarage.com/articles/what-is-rs232

 

Are you using the internal RC oscillator? If so, maybe it is time to switch to a crystal instead. Then you will know your clock frequency. After that double check your code and your baud rate calculation.

In the end, your problem might be (or probably is) a tiny problem with the protocol.

 

I guess that question brings up a good point that sadly I am not clear on. I assume I am using the oscillator onboard the AM335x chip that the Beaglebone Black runs on. I do see a crystal on the 3rd party device but I don't quite understand if/how that comes into play with my communication.

I did just run some captures again with my logic analyzer. I ran the working "USB-to-serial" connection as well as the not working "UART Circuit" connection. I strictly captured the initial transmit signal from my application that is being sent to the R1-IN (RS232) pin of the 3rd party device's MAX3232 chip. According to my logic analyzer there is absolutely nothing different in the data. For what it is worth, maybe nothing, the logic analyzer's software has an "autobaud" setting that can be used and when I enable that, it is auto-setting the baud rate to 115200 which is what I am expecting coming out of my application.

Here is snapshot of the capture from my "UART Circuit":


Here is the snapshot of the capture from my "USB-to-serial connection":


Granted, these images don't display the full capture, the "decoded protocol" data from both is identical:

 

Hi mbxs3, there is actually some difference in the timing:

Its not much perhaps but if your clock on one of the units is not very fast compared to the baud rate it could cause problems (maybe?)

I have no experience with PIC MCs, but I guess they should have information about the baud rate generation in the data sheets. For the Atmel they have something like this:


You can see that at 16Mhz clock and a baud of 230.4k there is a large possibility of timing error. So I normally choose to have an additional 18.4320MHz external oscillator which then ensures there is very good data synchronization and no problems with data errors.

A quick fix for you might be to try and find a different, slower baud rate that has a reduced error.

@BobaMosfet most RS-232 (and other serial communications) actually no longer use any of the other data lines or hand shaking, and operate purely asynchronously on the received data pulses only. They use an on-board clock and the preset baud-rate to translate the data. If the timer is a little slow, or the frequency does not divide into the baud-rate easily, some timing errors can occur.