Need help understanding weird checksum or CRC

I encountered another old serial communication reverse engineer challenge from an environment data logger.
This time the challenge is in the verification byte at the end of each transmission, like checksum or CRC, but is weird.

Serial data is in ASCII representation of bytes, kind of weird to start, and the verification byte at the end only has a short multitude of possible values.

Have in mind that:

• STX = 0x02 (Start of text)
• ETX = 0x03 (End of text)

For example:

STX003B800D0003010800000000ETX 0x07

All the data between STX and ETX is in ASCII, the real message in hexadecimal bytes is this:

02 30 30 33 42 38 30 30 44 30 30 30 33 30 31 30 38 30 30 30 30 30 30 30 30 03 07

The verification byte at the end can vary between the following observed values:

0x00 to 0x0f
0x70 to 0x7f

This is very strange and it doesn't follow any type of checksum, CRC-8, or bitwise operation that I know of and tested.

Maybe someone has a bit of insight on how to try and decode this old verification byte from serial communication.

I'll leave a few examples of the communication between the data logger and the computer:

STX003B80000D000000ETX 0x0D
STX003B80010D010028466E000142580000463464003F80000000000000ETX 0x06
STX003B80010D0200183F800000000000004049999AETX 0x0B
STX003B80010D03008000000000441600004561000048A5AC604813ADC0462DD00041F266664720BE004720BE00429E0000474732000000000437A0000000000004416000000000000ETX 0x7E
STX003B80030D020048469E9E0040DCA15C3F88CA7B649E9C0042700000C1E71C72000000000000000000000000ETX 0x77
STX003B80050D010028466E00054248000040E000003F80000000000000ETX 0x71
STX003B80050D020050BF8000004755D700000000004755D70000000000BF8000003F80000042C800003DE13F213F800000ETX 0x07
STX003B80050D03005840E0000000000000000000003F81C61A41C807C0000000003F133333447D00004180000044AAA00048195D4ETX 0x78
STX003B80050D050070471DD10046ECBC00469EA000474483003F81B22D417000003F8000003F800000000000003F0000003FC28F5C000000000000000447D0000ETX 0x79
STX003B8012110000384BC67B2241800000418800003F814F4041C5A20741118FE800000000ETX 0x04
STX003B8012110000384BC969AC41800000418800003F816AF941C383340BEC4EC00000000ETX 0x79
STX003B8012110000104409800040000000ETX 0x7E
STX003B80170E030000ETX 0x09
STX003B800C0003010800000000ETX 0x00
STX003B800D0003010800000000ETX 0x07
STX003B800E0003010800000000ETX 0x06
STX003B800F0003010800000000ETX 0x05
STX003B80040003010800000000ETX 0x77
STX003B80010003010800000000ETX 0x72
STX003B80120E000000ETX 0x0F

So far I've found out a few things:

• Most of the values are in floating point type of variable, 1.5 is 3fc00000.
• The first 3 bytes in the message are the serial number of the device in integer type.
• The 8th byte is the amount of characters in the data of the message.
• The data starts from the 9th byte and ends in the ETX.

So far I tried different types of checksum, CRC-8, XOR, NAND, NOR, NOT, AND, OR, with different bytes. I used online calculators that are very good and helped me in the past:

• CRC Online Calculator
• Checksum Online Calculator

Also I tried weird checksums that make no sense comparing the resulted values with the expected ones.

In summary, I tried to apply all of these calculations to the messages in ASCII and in HEX, with the entirety of the message and with some specific parts like only data or excluding some parts of the message like the STX and ETX bytes.

The check value is the exclusive-or of the message bytes for all but one of your example messages (the one that has a 96). I would guess that there was a transmission or transcription error in that one. In fact, that is the only example with an odd number of message bytes, suggesting a missing byte. (More likely, three missing bytes.)