Serial Receipt Printer Garbage

Question

I connected a vintage serial matrix receipt printer (Datamega DPN-233) via FTDI to my MacBook's USB. It performs its own self-test without problems, prints an example and the RS 232 configuration (19200.8.N.1) I tried 2 different USB-to-Serial adapters, both have the same problem:

1. When I press the "Online Button" on the printer my MacBook receives a "v"
2. When I press the "Online Button" on the printer again, my MacBook receives a "w" and so on...
3. Whatever ESC-Code I send nothing happens, sometimes, after some commands the printer starts to print some garbage
4. The printer can print 24 Characters in one line. After i sent 12 CR Strokes to it, it starts to print a complete Line of "=y=y=y=y=y=y=y=y=y=y=y=y" and performs a line feed.
5. I already tried 9600 but the result is exactly the same.
6. I configured the printer as XON/XOFF, when I detach the Rxd from the printer all the above doesn't work any more
7. All the above happens when I use two different serial terminal emulations on my Mac (Serial and Arduino)

Does anyone have any suggestions? The serial communication seems to work. Is this an encoding problem?

Answer 1

If the printer is offering an actual RS232 port, this should be identifiable by there being an RS232 level converter IC near the connector on its logic board: Usually, there will be a DS232/MAX232 or other MAX23x series IC, or a NEC D4711/UPD4711, or a combination of any of MC1488/MC1489/SN75188/SN75189/GD75189/GD75188/GD75232...

This chip inverts the signal, matches it to RS232 voltage levels, and limits the rate of voltage rise at the signal transitions - a TTL signal tends to go from one voltage extreme to the other in a couple of nanoseconds - it would be "fast" enough to implement a 10 megabit serial line easily. Unfortunately, a signal like that would need to be treated (cabling wise) like it was 10 megabit regardless of the baud rate, otherwise effects like horrible radio interference or phantom signal transistions due to reflections can and will happen.

If such a chip is present, there are two options:

-Use a real serial port or an USB/Serial converter equipped or retrofitted with such a converter chip too

-Modify the printer by disconnecting the serial level converter and hooking the TTL-level signals into the lines that interface between the rest of the printer and the converter. Mind that TTL level signals are not good for long wiring, if not using some termination scheme it is best to run them in shielded wires (or one half of a twist of a twisted pair cable, other wire connected to ground - not optimal but...) and keep cabling length to a feet or two. Or, build the FTDI (or other converter board) into the printer and run USB into it (Don't "mess" with USB wiring BTW, it is even more sensitive than TTL).

Answer 2

Looks like inverse polarity. The CR code is 015, 00001101 in binary. The codes for "=" and "y" are 075 and 171, 00111101 and 01111001 respectively. Note the sequence of four zeros in CR, and sequences of four ones in "=" and "y". With the inverse polarity, the character boundaries will depend on the speed with which they are sent because the start and the stop bits are messed up.

A common source of inverted polarity is attempting to interface a device with a true RS-232 (logic "0" - positive voltage , logic "1" - negative voltage) with a device producing TTL levels (logic "0" - 0V, logic "1" - 5V or 3.3V). The RS-232 voltage ranges are potentially much higher than TTL levels (up to +/- 25V, but nowadays usually +/- 5-6V), so theoretically you could be risking one of the two devices when connecting them directly.

Here's a page describing the problem and ways to solve it in detail: https://www.sparkfun.com/tutorials/215

A commonly used chip to do the conversion was called MAX232. Its currently available version is MAX3232. Many vendors offer little PCBs providing the functionality.

Answer 3

While Leo's answer seems possible, I find a reverse polarity problem relatively improbable when standard off-the-shelf equipment is used. I wouldn't want to rule out Leo's answer completely, though, just point out a possible alternative (even if I would assume that with reverse polarity at least the number of characters sent and apparently received should be equal).

If you look at the bit patterns, another explanation (and the most common one in serial comms) is differing baud rate on both ends. even if you say it's the same.

Double the bit rate on the receiving end can lead to bit duplication (as all bits are sampled twice), and the patterns you observe strongly look like duplicated bits to me.

Apparently, one end of your line is configured to 9600 bps only.

What program are you using on the Mac (what Mac?) to send the characters?