Try this version.

#! perl -slw
use strict;

sub checksum {
    my( $string ) = @_;

    my $chk_sum = 0;
    $chk_sum += $_ for unpack 'C*', substr $string, 0, -5;

    my $twos_comp = hex( substr $string, -5, 4 );
    return ( ( $chk_sum + $twos_comp ) & 0xFFFF ) ? 1 : 0;
}

print "$_ : ", checksum $_ for "\x019999FF1B\x03", "\x019998FF1B\x03";

__END__
P:\test>283701
?9999FF1B? : 0
?9998FF1B? : 1
[download]

As for what is going on. The encoding routine adds up the (7-bit) ascii values of the message, takes the 16-bit twos complement of the total and adds the result to the end of the message.

eg.

9999 = 57 + 57 + 57 + 57 = 228.
~ 228 = -229 decimal = FF1B hex (16-bit)
Add the header and trailer characters = <SOH>9999FF1B<ETX>
[download]

To check the transmission was uncorrupted, the checksum routine totals up the (7-bit) ascii values of the message - the last 5 characters.

1 + 57 + 57 + 57 + 57 = 229
[download]

Converts the last 5-1 characters back from hex

FF1B = 65307
[download]

Then adds the two together (discarding any bits greater than 16 which could happen with longer messages)

(65307 + 229) = 65536
65536 & 65535 = 0x10000 & 0xFFFF = 0
[download]

If the result is 0, the checksum matched and the function returns 0 to indicate success--or perhaps a lack of failure:)

A perl implementation of the encoding routine might look like this

sub build_string {
    my( $string ) = @_;
    my $chksum = 0;
    $chksum += $_ for map{ $_ & 0x7F } unpack 'C*', $string;
    $chksum = (~$chksum & 0xFFFF);

    return chr(1) . $string . sprintf( '%4x', $chksum ) . chr(3);
}
[download]

HTH.

If the result isn't 0, then the checksum didn't match and the function return 1--to indicate corruption occured?

Note: The return value is backwards from your expectation, and mine, but that is what the code is doing (unless I am completely misinterpreting it, which is always possible!).