CRC flexibility.

I think CRC after CR/LF would be a bug. (is this true? Is there some use case where CRLF is inside the CRC data block?)

Is what you want applicable to others eg is it actually NMEA?

You will need to explain it more and give CRC code example or something that can be added to the CRC module, and some sample data.

You may be right about it being a bug, im not aware of any cases where CR/LF would be before a CRC. Unless one was really paranoid about the CR/LF chars becoming corruptm, that is if realterm's CRC is including those chars in the calculation.

Sorry, I realize I did explain my feature request poorly. After some investigation just now I realized that realterm does not have the option to generate a checksum like the NMEA protocol uses. Here is how the NMEA protocol generates a checksum:

The checksum is simply an XOR of every byte in the message. This results in a byte. (This alone may be handy to include in realterm. I think alot of simpler microcontroller communications use simple XOR checksums)

I'm not entirely sure why but NMEA and some other protocols take it one step further and convert that checksum byte into a hex value and tack on the 2 ascii chars that make up the hex value to the end of the message instead of the 1 byte. Im not certain but this may be in order to keep all the characters alpha numeric.

Example GPS NMEA msg from a weather balloon: $GPGGA,182447.00,4230.39209,N,09828.19232,W,1,10,0.86,4456.0,M,-26.1,M,,*52

Take the XOR of all bytes between (but not including) the $ and * chars and you get "R" which is printed as two bytes "52" which is the hex representation of "R".

The $ and * are just formal parts of the NMEA protocol im not certain that it would be necessary to implement their function into realterm unless you see a reason to make a NMEA mode or something.

I will put CRLF outside CRC block at some future version. Please make a bug repport for this.
Hmm-now I am not sure. Perhaps with binary crc, CRLF should logically be included in CRC.
but with Hex-crc, then CRLF should logically be after the CRC text and not included. Any thoughts?

Yes I can see that hex crc's might make sense. The user interface is the main issue. I think that just adding all the modes to the dropdown with HEX eg "SMBUS 8 Hex".
This does bring up the issue of whether uppercase hex is OK for all use cases?

XOR would be an easy addition also I imagine (though its a pretty awful data validity check)

An NMEA crc mode looks easy to do also.
Does uppercase HEX work for the crc?
Are there CR/LF's between NMEA packets?
Is it safe to say the NMEA never has $ and * beginning and ending the packet content?

Hi Kyle,

This has been done:
Add XOR8 crc
Add HEX output of CRC (for ascii data eg NMEA)
EOL CR&LF are now outside CRC (both for bin and hex crc's)
CRC commandline param added (-ve=hex)
NMEA message added, tolerates $ * missing or present

Please test these features and report back:
https://www.dropbox.com/s/uwci0lcucobdncr/realterm.exe?dl=0

Thanks Simon!

I have downloaded and tested all features/fixes listed above. They are spot on, I tested several different sentances including NMEA sentances against "NMEA Checksum Calculator" http://nmeachecksum.eqth.net/ and they all checked out. The xor8, hex, and command line features work as well.

Thanks for your work, I hope many will find these features useful.
P.S: I donated some for your efforts, thanks again!