Linux redirect to Nano on /dev/ttyUSB corrupts/loses beginning of data

I've written a simple USB to TTL serial passthrough bridge, using examples I've found as inspiration, but I'm having trouble sending data to it using the Linux command-line. I'm connecting to a TTL serial thermal printer using software serial, and relaying data received on the hardware serial to it. When I send data to a Nano on /dev/ttyUSB0 using a shell redirect it corrupts or loses the beginning of the data. However, if I connect using "screen" or the Arduino IDE serial monitor, it works correctly.

It's connected like this:

PC ---[USB]---> Nano --[TTL-Serial]--> Printer

This is how I need to be able to send data for printing:

cat testfile.txt > /dev/ttyUSB0

I have tried changing the serial comms settings using stty, before sending data but it doesn't seem to make any difference, with this (and several other variants):

stty -F /dev/ttyUSB0 cs8 9600 ignbrk -brkint -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke noflsh -ixon -crtscts

The contents of testfile look like this:

12345678901234567890123456789012345678901234567890123456789012345678901234567890
22345678901234567890123456789012345678901234567890123456789012345678901234567890
32345678901234567890123456789012345678901234567890123456789012345678901234567890
42345678901234567890123456789012345678901234567890123456789012345678901234567890
52345678901234567890123456789012345678901234567890123456789012345678901234567890
62345678901234567890123456789012345678901234567890123456789012345678901234567890
72345678901234567890123456789012345678901234567890123456789012345678901234567890

... and the resulting output something looks like:

!£$%^&*22345678901234567890123456789012345678901234567890123456789012345678901234567890
32345678901234567890123456789012345678901234567890123456789012345678901234567890
...
72345678901234567890123456789012345678901234567890123456789012345678901234567890

(The "..." indicated lines I've edited out for brevity. The garbage characters at the start, represented by "!£$%^&*" vary in length and glyphs: they include random accented, box characters and symbols. If need be, I'll put up a photo, but I didn't think it was necessary to show it exactly at this stage).

To me, it looks like a baud rate problem, but any text I print directly from string literals in the Arduino program prints correctly, so it appears to be a problem on the receiving side.

The code is:

#include "AltSoftSerial.h"

AltSoftSerial PrinterSerial; 

void setup() {
  // start serial port at 9600 bps:
  Serial.begin(9600);
  while (!Serial); // wait for Serial to become ready
  PrinterSerial.begin(9600);
  Serial.read();

 // set print density parameters
  PrinterSerial.write(ASCII_ESC);
  PrinterSerial.write('7');
  PrinterSerial.write(char(0x00)); // max dots to heat, in multiples of 8
  PrinterSerial.write(char(0xFF)); // heating time
  PrinterSerial.write(char(0xFF));  // heating interval/ cooling time
  PrinterSerial.println("Ready.");
}


void loop() {
  if (Serial.available()) {
    char inByte = Serial.read();
      PrinterSerial.print(inByte);
  }

  if (PrinterSerial.available()) {
    char inByte = PrinterSerial.read();
      Serial.print(inByte);
  }
}

I'm currently using AltSoftSerial, though I started with stock SoftwareSerial, because I wanted to confirm that the problem was not with the stock library, and force myself to re-code it a bit to clear up any bad assumptions I'd made in the code. The "Ready." telltale prompt prints out correctly when the Nano is reset, so communication with the printer seems to be ok before data is piped through from the Linux host.

I'm probably missing something silly, but I can't see it, and I'm out of google search term permutations!

Any help or hints gratefully received. Thanks.

Opening a serial port results in a reset of most Arduinos (Uno, Mega, Nano, Mini and possibly some others). The reset takes a bit of time while the bootloader waits to check if you want to upload new code.

If you can suppress the activation of the DTR line from the command prompt / tty settings, you will not have the problem. Alternative is to hack the board and cut the DTR line between the usb-to-ttl converter and the 328P; side effect is that you no longer can upload with ease.

That's brilliant, thank you. I had noticed that my tell-tale prompt, printed during setup() was printing, but hadn't thought about the length of time it takes. I'll work out how to suppress the reset then - even if I have to cut the line it's fine, because I'm programming it via a USB ASP programmer anyway.

I've done some experiments, and have a solution of sorts. I was hoping stty might offer a solution, but the version of Debian I am using (9) has a version of stty which doesn't support modifying the dtr/dsr handshake. I'm using a non-geniune Nano with a CH340 USB chip, and after reading a few posts, found these:

https://www.meteocercal.info/forum/Thread-Disabling-auto-reset-on-Arduino-Nano

http://www.raspibo.org/wiki/index.php?title=Arduino_Auto_Reset:_Disable_and_Enable_at_run_time

Which both suggest modifying the board by replacing the capacitor that goes between pin 14 of the CH340 and the reset pin of the AT368. I don't have any surface mount resistors (of any value, let alone the 120 ohm one suggested) but I wondered if simply removing the capacitor would work - disconnecting the CH340's DTR pin completely. Since I'm programming by using an ASP programmer, and this still leaves the RST pin of the ICS header connected to the MCU, it does indeed work.

Edit: The capacitor I removed is nearest to the GND pin on by the Analog pins, on the underside of the board.

Obviously, if I ever need to reprogram using USB, I'll have to use the reset button manually to do it, but I can live with that!

So, I guess the final question is, will this have any other long-term (negative) effects other than what I have stated above?

Thanks once again for pointing me in the right direction.