You say, using RealTerm,

Also transmitting the command "ati\n"

... this implies that your communication protocol expects just LF, not CRLF, assuming that RealTerm doesn't do any EOL translation.

In your code, you say,

$port->write("ati"."\n");

At least in Strawberry Perl (and I think in homebuilt or ActiveState Perl, too, but I am not sure), on a Windows machine, it defaults the STDOUT output layer to translate \n in Perl to \r\n when it prints to STDOUT (effectively, an implied binmode STDOUT, ':crlf'). I don't know whether Win32::SerialPort follows that convention, too, or whether ->stty_eol(...) defines what \n is translated into, or whether ->write(...) automatically appends the ->stty_eol(...) sequence.

The docs say, "The read, input, read_done, write methods all treat data as "raw"." -- That somewhat indicates that they won't apply the CRLF transformation.

But if write automatically appends the stty_eol sequence, then you might be getting ati followed by two LF rather than the one you intended. And, though they don't have a lot of ->write(...) examples in their POD, none of them show them manually appending the newline, so you might want to at least try to not have the ."\n" in your code.

(Debugging communication-protocol on physical wires is so much easier when you've got a way to watch the signals, with the "rs232 breakout tester led monitor" that Marshall suggested, or an oscilloscope or professional-quality logic analyzer, or a hobbiest logic analyzer (like the SparkFun, or Amazon lists a < US$15 "USB Logic Analyzer" which goes up to 24Mbps, which is plenty for your 38.4k signal).)