Hello

dataTaker is a powerful and versatile device and it's able to get data from almost any sensor type. This comes handy when designing new serial sensors with custom protocols as you can use existing well proven hardware for actual data acquisition. However the serial channel doesn't support any kind of data packet integrity check. It would be great to get computed CRC16 or even CRC32 from the RS485 data packet and get the datalogger sending a reading request again in a case of corrupted data. Operation would be obviously fully autonomously with specified retry count.

Although it’s possible to calculate the CRC afterwards like in a spreadsheet, but you may miss some data more likely since the method is able only to reveal errors in a downloaded data.

The protocol, timing, code/dT-config and wiring among other things must be well and properly done to minimize a such errors, but if the acquired data is important all considerations must be taken into account.

Is there any change to get more comprehensive CRC support for digital sensors?

Good morning bladE,

I fully agree with you on this one.
When I asked for this in the past I was told it was too hard as there are many ways to do a crc.
But surely they could have a list of the most common ie crc16, crc32, crc64, sum8, sum16, sum23, zhash and thash.
I've had a number of jobs now that I've had to turn down because I can't send a check sum.

Cheers

Roger

Hello Roger,

Nice to hear some mutual thoughts. I have asked this from Cambell Scientific too and yes, CRC support does exist. Like you have already figured out the remedy is a bunch of different CRC's. Implementing even some of those would help in a certain cases and shouldn't be that hard. After all we are just speaking about general purpose dataloggers here. I like the dataTaker loggers even I had to struggle to get CEM20 working with RS485 signals properly and independently. However many things has been done quite well and somewhat clever, but we are hungry and want more. A set of CRC's and CEM20 transparency are couple of those things on a wish list.

Sample set of CRC's

CCITT CRC16 x16+x12+x5+1 (Xmodem, seed of 0)
CRC16 used by ModBus
CRC16 used by ModBus with 0 initializer
CCITT CRC32 used by CSI BMP3 protocol
Sum all the bytes and mod by 256
Sum all the bytes and mod by 8192
Checksum which performs exclusive OR on all the bytes; e.g., first byte XOR second byte XOR third byte XOR… last byte
CRC16 with seed of 0 and XOR polynomial of &hA001
CRC16 with seed of &hFFFF and XOR polynomial of &hA001
CRC16 with seed of 0 and XOR polynomial of &h8408
CRC16 with seed of &hFFFF and XOR polynomial of &h8408
CRC16 reverse bit order with seed of 0 and XOR polynomial of &hA001
CRC16 reverse bit order with seed of &hFFFF and XOR polynomial of &hA001
CRC16 reverse bit order with seed of 0 and XOR polynomial of &h8408
CRC16 reverse bit order with seed of &hFFFF and XOR polynomial of &h8408
CCITT CRC16 ITU/X25
Returns the sum of all bytes with no masking
SHA1. This option requires an additional parameter that is a destination array that can hold 20 bytes.
SHA1, base 64 encoded. This option requires an additional parameter, typed as a string that can hold 29 characters. The result is null-terminated.
HMAC SHA1. This option requires three additional parameters...
HMAC SHA1, base 64 encoded. This option requires three additional parameters...
MD5. This option requires an additional parameter that is a destination array that can hold 16 bytes.

Good evening bladE
And there you highlight the problem.
There are so many which ones would deliver the most benefit?

Given that with all the projects I have done over the years there is only one project where it was an issue is there a requirement and return on investment?

Cheers

Roger