Would this be more reliable than including a crc8 byte?
There's no way to absolutely ensure that it is correct, so it really comes down to how low does the risk have to be of accepting bad data has to get before it is acceptable.
This will fail to detect many 1-bit errors. It also makes it so that errors in some bit positions are more detectable than others, which is generally not preferred.
That's true, but from there I couldn't proceed to the full paper. Therefore the next link, which leads directly to an HTML version of the original article.
as a general rule
Facebook
Google
GitHub
Linkedin
/*
* check the BMC CSV data string for proper format, size and check-mark
*/
char * validate_bmc_text(const char * text, bool * valid)
{
char tmp_test_ptr[SYSLOG_SIZ], *tmp_p = (char *) text;
uint32_t len = 0, starts = 0, checkmark = 0;
bool end_data = false;
char *jtoken;
validate_failure = 0;
strncpy(tmp_test_ptr, text, SYSLOG_SIZ - 1);
valid[0] = true;
if (tmp_test_ptr[0] == '^') {
starts++;
tmp_p = (char *) &text[0]; // return pointer to start of possible data
if ((len = strlen(tmp_test_ptr)) >= VALIDATE_LEN) {
for (int i = 1; i <= len; i++) {
if (tmp_test_ptr[i] == '^') {
starts++;
end_data = false;
tmp_p = (char *) &text[i]; // return pointer to start of possible data
}
if (tmp_test_ptr[i] == '~') {
if (starts) {
end_data = true;
}
}
}
if (end_data == false) {
valid[0] = false;
validate_failure = 3;
}
strncpy(tmp_test_ptr, tmp_p, SYSLOG_SIZ - 1);
jtoken = strtok(tmp_test_ptr, ",");
if (jtoken != NULL) {
for (int i = 0; i < CSV_COUNT; i++) {
jtoken = strtok(NULL, ",");
if (jtoken == NULL) {
valid[0] = false;
validate_failure = 4;
}
}
jtoken = strtok(NULL, ",");
if (jtoken != NULL) {
checkmark = atoi(jtoken);
if (checkmark != CHECKMARK) {
valid[0] = false;
validate_failure = 6;
}
} else {
valid[0] = false;
validate_failure = 5;
}
}
} else {
valid[0] = false;
validate_failure = 2; // data frame length error
}
} else {
valid[0] = false;
validate_failure = 1; // no/incorrect ASCII data-frame character
}
return tmp_p;
} const char log_format1[] = "^,%d,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%d.%01d,%d.%01d,%d.%01d,%d,%d,%d,%d,%d,%llu,%7.4f,%7.4f,%7.4f,%7.4f,1957,~EOT \r\n";
#define LOG_VARS1 BMC4.d_id,((float) em.vl3l1) / 10.0f,em_tmp.al1, ((float) em.wl1) / 10.0f, ((float) em.wl2) / 10.0f, \
((float) em.val1) / 10.0f, ((float) em.varl1) / 10.0f, ((float) em.pfsys) / 10.0f, em_tmp.hz,vw, vf, pvw, pvf, bat_amp_whole - 128, \
bat_amp_frac - 128, bat_amp_panel - 128, panel_watts, BM.FM80_online, cc_mode, C.data_ok,BM.node_id, \
ha_daq_calib.scaler4, ha_daq_calib.scaler5, ha_daq_calib.A200_Z, ha_daq_calib.A200_S
const char log_format2[] = "^,%d,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%d.%01d,%d.%01d,%d.%01d,%d,%d,%d,%d,%d,%llu,%6.4f,%6.4f,%6.4f,%6.4f,1957,~EOT \r\n";
#define LOG_VARS2 BMC4.d_id,((float) em.vl1n) / 10.0f,((float) em.vl2n) / 10.0f, ((float) em.vl3n) / 10.0f, ((float) em.al2) / 1000.0f, \
((float) em.wl3) / 10.0f, ((float) em.wsys) / 10.0f, ((float) em.pfl1) / 10.0f, ((float) em.pfl2) / 10.0f,vw, vf, pvw, pvf, bat_amp_whole - 128, \
bat_amp_frac - 128, bat_amp_panel - 128, BM.benergy, BM.FM80_online, cc_mode, C.data_ok,BM.node_id, \
imd_tmp.wl1, imd_tmp.wl2, imd_tmp.wl3, imd_tmp.varsys
why not send it continuously as is. no CRC needed. on the receiving side treat data as valid if two consecutive telegrams match. it does not get simpler than that.
CRC or no CRC, packet should contain unique bytes to indicate start-of-frame and end-of-frame.
I don't want to send continuously as I have other applications using 443MHz, But I could send three times and do a majority vote.
Sending three times is a great simple way in theory.
