It definitely looks like there's a discrepancy on output, but it doesn't appear you've shown how you call Serial_TrxRcv() or with what data. There's no way to know what the problem is without that information.

Hi. Thank you for your replys. I think I can be now more specific about my issue of the buffer overflow error. The routine I call for COM5 serial handshaking is Serial_TrxRcv( $commandForTransmission ). In my main routine I have a sub doing this which is below;

sub ProcessPIDs {
    
    # print "Inside ProcessPIDs \n";

    # Process the input arguments
    my ( $nickname, $ref_nicknametocommand ) = @_;
    my %InSubNickNameToCommand = %{$ref_nicknametocommand};   # De-ref
+erence the reference to a hash
        my $ccmd;
    
        $ccmd = $InSubNickNameToCommand{ $nickname };             # ne
+ed further ERROR checking here  !!!!!!
    
    
        my $newcmd = '0101';
        print "\$ccmd; $ccmd ".length($ccmd). " \$newcmd; $newcmd ".le
+ngth($newcmd)."\n";
        # my $newcmd = $ccmd;    # not work
    my $response = Serial_TrxRcv($newcmd);
    my $result;

     ...etc...
[download]

If I use Serial_TrxRcv in the manner as above, I do not have error. If I call the same but with the parameter $ccmd then I get the error. This $ccmd is initialised from a hash structure. The hash is to provide quick mapping from a nickname to the wanted command string. I provide a comparison between these 2 parameters with the just above programs and the console output below;

TPA 
$ccmd; 0101 4 $newcmd; 0101 4
cmd; 0101 x x
MonStatus      Cmd; 0101 Length; 21  Response; 41 01 00 07 61 00 __>.
$nickname MonStatus; 00 07 61 00
TPB
[download]

The non-faulty and faulty parameters both appear the same and have the same lengths. So, do people have any further ideas about my problem ??

Thanks. Regards JC.....

Serial devices usually have a very small buffer, like 16 bytes or something. Could the problem be that the device isn't consuming data as fast as you write it? Is that module supposed to block your script until there is room in the buffer, or does it just throw that exception when the buffer is full?

You might try a quick experiment to see what other cases can give you the same error. What if you write a 17-byte string once? What if you write two 9-byte strings back-to-back without waiting? What if you write 5000 bytes?

There are also flow-control lines on the serial connection, so the device can indicate when it is ready to read or not. Do you have a breakout-box showing you those signals on LEDs? What happens if you write data on the line when the device isn't ClearToSend?

Ah, and I just learned something. (from that StackOverflow post)

RTS/CTS wasn't supposed to ever be a flow control mechanism, originally; it was for half-duplex modems to coordinate who was sending and who was receiving. RTS and CTS got misused for flow control so often that it became standard.

when debugging, I prefer to see my values in quotes (or other markers), and possible control characters (or "extended" characters) "translated". Therefore I'd suggest instead of simply printing the values, perusing Data::Dumper (core module), or Data::Dump or somesuch.
Although it probably isn't a case of homoglyphs, perhaps the different representation by Data::Dumper might help you spot something.