RS232 data consistently corrupted when reading from a TMA-1

Hi,

I'm trying to read the active audio channels from my (Audio/Video) pre-amplifier, which comes with an external interface (the Tag Mclaren TMA-1) that has 2 RS-232 ports. I can talk to it flawlessly with my good of DEC VT420 or a FTDI USB<>RS232 adapter, but not with my Arduino Mega. To simplify testing, I have just wired 2 MAX232 modules (similar to RS232/TTL Wandler mit MAX3232 online kaufen | Pollin.de) to serial and serial3, spliced that between the FTDI USB thing and the TMA-1, and installed the https://www.arduino.cc/en/Tutorial/BuiltInExamples/SerialPassthrough example (with Serial1 replaced with Serial3).

I can successfully send commands (otherwise no response would be sent), but the responses are always corrupted. I get similar corruption with a Philips Pronto RFX9600, but not with the FTDI or the VT420. There are minor variations to the corrupt data, but it is largely always the same. What I'm sending is

TMA AVP 1 STATUS\n

and I expect a response like

AVP: AUDIO:DAB Tuner VIDEO:DVD-S PROC:DIRECT VOL:-27.5dB LFE:+0.0dB BAL LR:L0.0dB BAL FR:F0.0dB CHAN:L/-/R/-/-/-/-/- FREQ:--.- TAPE:N FULL:N NIGHT:N ZONE:1

instead I see a response that contains characters > 128 as shown in corrupt.png. It doesn't matter which port I use to send or receive. The signal the TMA-1 is sending looks OK to me, comparing the output of the Arduino or VT420 and the TMA-1 doesn't show any obvious problems - there's a bit of ripple, but it's tiny compared to the overall voltage swing, the rise and fall times are almost identical.

All interfaces are configured 9600 8N1 in both directions. I get no corruption at all if I just replace the TMA-1 with a short of pins 2 and 3.

Are there any "advanced" options for the Arduino serial ports that might change its behavior regarding possibly not quite spec-compliant signals? Or any hints what I should look for with the scope to determine what exactly is confusing the Arduino (but not the VT420 or the FTDI)?

corrupt.png

tma1-50us-5V.png

arduino-50us-5V.png

vt420-50us-5V.png

corrupt.png

tma1-50us-5V.png

arduino-50us-5V.png

vt420-50us-5V.png

In the stone age they did not use 9600 8N1. They used 2400 7E1 with handshake signals and later on 9600 7E1.
Are you seeing the parity bit ?

Update:
I see now that it uses 9600 8N1, but the output baudrate can be a different baudrate than the input baudrate. Are you sure that they are both 9600 baud ?

The RS-232 voltages are not standard. The maximum is -15 to +15 Volt, but the minimum can be -3 to +3 Volt and some cheat their way into RS-232 with 0 to 5V. Perhaps the terminal accepts everything and perhaps the USB-serial modules do not.

Have you tried directly between the Arduino and VT420 just to see whether they communicate between each other correctly? If they do not, then it might be easier to work out what is happening (or not), for example could it be one of the MAX232 modules is at fault?

8N1 is no parity, and I'm not seeing any. Speed is 9600 both ways, I wouldn't even know how to set minicom to use different speeds for send and receive, the VT420 is explicitly set to "receive=transmit".

I'm kind of surprised how consistent the voltages are. All the devices I've tested idle at around -6 to -7V, and the difference between 0 and 1 is about 15V. Timing seems to be close enough between all the devices I've inspected, the only suspicious thing is the 1/2 period low signal I've captured in the first graph, but that could be the inter-byte pause.

The USB serial module is among the things that work.

Have you tried directly between the Arduino and VT420 just to see whether they communicate between each other correctly? If they do not, then it might be easier to work out what is happening (or not), for example could it be one of the MAX232 modules is at fault?

That should be covered by shorting pins 2&3 at the far end. Any text typed/sent by the VT420 is echoed correctly through both MAX232 modules back and forth. Also, the data that's returned is essentially the same, no matter which MAX232 module is connected to the TMA1. Good point though, because the first module I've tried appears to be completely dead.

When a signal is 7E1 and the receiver is set to 8N1, then the receiver gets all the parity-bits in the highest bit. But I read that it sends 8N1, so that is not the case.

If the RS-232 voltage levels are okay, then we should focus on the timing.
The 1/2 period glitch is a serious problem. It is not allowed as inter-byte.
When a serial communication is idle, then it is the same as the stop-bit. The stop-bit is the pause. Therefor the full period of a stop-bit is the minimal pause between the bytes.

Can you capture more data ? Can you confirm that the ½ period is between the bytes ? Shall we call that 8N½ ?

I can guarantee that the Arduino uses super standard serial communication. If it receives 8N½, that would drive the Arduino nuts.

With a USB logic analyzer, it is possible to capture a lot of data and zoom and shift very easy on the computer.
I'm very fond of the LHT00SU1 in combination with sigrok/PulseView. The software can decode serial and I2C data for example.
They used to be 25 dollars: Geekcreit® lht00su1 virtual oscilloscope logic analyzer i2c spi can uart Sale - Banggood.com.
Sparkfun tutorial: Using the USB Logic Analyzer with sigrok PulseView - learn.sparkfun.com.
Those cheap 24MHz 8 channel devices as mentioned in the Sparkfun tutorial work well, but they are build (too) cheap. You can buy them for 10 dollars.

The 1/2 period glitch is a serious problem. It is not allowed as inter-byte.

Looks like the TMA-1 is consistently using 1/2 length stop bits. Raw data from the beginning of one response (actually averaged over 8 samples to remove some noise) is in the attachment. The table below shows the sample number where transitions occur, the duration of the intervals in samples and bits.

Since I’m using a Arduino Mega, it appeared “obvious” to me that I’d use the hardware serial ports. A casual glance at the comments in SoftwareSerial.cpp seems to indicate that that could deal with something as short as 0.25 stop bits. I’ll try that tomorrow.

Transition at Sample # length # periods bits
957 first start bit begins
1023 65 1 first data bit
1088 326 1
1414 64 5
1478 66 1
1544 36 1 9
1580 131 0.5
1711 129 2
1840 66 2
1906 65 1
1971 65 1
2036 65 1
2101 66 1
2167 36 1 9
2203 326 0.5
2529 64 5
2593 65 1
2658 65 1
2723 66 1
2789 36 1 9
2825 131 0.5
2956 64 2
3020 66 1
3086 195 1
3281 131 3
3412 36 2 9
3448 65 0.5
3513 130 1
3643 261 2
3904 64 4
3968 66 2 9
4034 36 0.5

tma1-reponse2.txt (53 KB)

SoftwareSerial doesn't make any appreciable difference, the received data is slightly different, but still corrupt. I'll try tracking down one of the engineers who designed the TMA-1, maybe there's someone who still has the source code and can build a new firmware...