{"action":"created","issue":{"url":"https://api.github.com/repos/gioblu/PJON/issues/27","repository_url":"https://api.github.com/repos/gioblu/PJON","labels_url":"https://api.github.com/repos/gioblu/PJON/issues/27/labels{/name}","comments_url":"https://api.github.com/repos/gioblu/PJON/issues/27/comments","events_url":"https://api.github.com/repos/gioblu/PJON/issues/27/events","html_url":"https://github.com/gioblu/PJON/issues/27","id":136991232,"number":27,"title":"Better CRC?","user":{"login":"TeeTrizZz","id":2567594,"avatar_url":"https://avatars.githubusercontent.com/u/2567594?v=3","gravatar_id":"","url":"https://api.github.com/users/TeeTrizZz","html_url":"https://github.com/TeeTrizZz","followers_url":"https://api.github.com/users/TeeTrizZz/followers","following_url":"https://api.github.com/users/TeeTrizZz/following{/other_user}","gists_url":"https://api.github.com/users/TeeTrizZz/gists{/gist_id}","starred_url":"https://api.github.com/users/TeeTrizZz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TeeTrizZz/subscriptions","organizations_url":"https://api.github.com/users/TeeTrizZz/orgs","repos_url":"https://api.github.com/users/TeeTrizZz/repos","events_url":"https://api.github.com/users/TeeTrizZz/events{/privacy}","received_events_url":"https://api.github.com/users/TeeTrizZz/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-02-28T01:33:25Z","updated_at":"2016-02-28T02:23:33Z","closed_at":null,"body":"Currently, the CRC doesn't take the position of a byte into account. This can lead to problems when bytes are missing (e.g. when a device starts to read the stream at an unknown time and misses the first few bytes). I used my little app to test messages with 5 bytes of content (8 bytes in total). With the current CRC calculation method there are a lot of potential issues (and I mean **A LOT** if one uses more than one device). \r\n\r\nExample: The message 3-8-2-6-4-15-13-9 could be received by a device with the id 6 as 6-4-15-13. The CRC is correct, the device sends a faulty ACK, and the device 3 gets a wrong message because two bytes are sent over the channel at the same time.\r\n\r\nThe CRC calculation needs to be very simple, I guess. Any ideas?"},"comment":{"url":"https://api.github.com/repos/gioblu/PJON/issues/comments/189766050","html_url":"https://github.com/gioblu/PJON/issues/27#issuecomment-189766050","issue_url":"https://api.github.com/repos/gioblu/PJON/issues/27","id":189766050,"user":{"login":"gioblu","id":764497,"avatar_url":"https://avatars.githubusercontent.com/u/764497?v=3","gravatar_id":"","url":"https://api.github.com/users/gioblu","html_url":"https://github.com/gioblu","followers_url":"https://api.github.com/users/gioblu/followers","following_url":"https://api.github.com/users/gioblu/following{/other_user}","gists_url":"https://api.github.com/users/gioblu/gists{/gist_id}","starred_url":"https://api.github.com/users/gioblu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gioblu/subscriptions","organizations_url":"https://api.github.com/users/gioblu/orgs","repos_url":"https://api.github.com/users/gioblu/repos","events_url":"https://api.github.com/users/gioblu/events{/privacy}","received_events_url":"https://api.github.com/users/gioblu/received_events","type":"User","site_admin":false},"created_at":"2016-02-28T02:23:33Z","updated_at":"2016-02-28T02:23:33Z","body":"Hi, I don't think what you are describing is a problem of the CRC, it is not failing, it is working correctly, the problem I think is upstream. Also if you bring CRC more convoluted on byte position you can't avoid to get that correct number in the correct position in the pseudorandom bytestream. The responsability to identify if a chunk of the stream is a packet for a certain device I think is of the standard itself, and in this case seems it could lack a packet start symbol. Adding some overhead maybe a start symbol could save some time to listeners that could bounce all bytes are not a start and do something else, and I think reduce much the chance to have a false positive from an arbitrary chunk of pseudorandom bytestream. ie: (lets say 99 is our start symbol)\r\n`99-3-8-2-6-4-15-13-9` so device 6 is safe from false positive\r\n`99-3-8-99-6-4-15-13-9` yes this can happen\r\n`99-3-8-99-6-4-15-13-9` but after 6 should come a number between 4 and MAX_PACKET_LENGTH\r\nand obviously after that should come a series of bytes long as length with the correct CRC value in its place. \r\n\r\nCould you please run your app to see what comes out with a setup with start symbol?\r\n\r\n"}}