Fixing 1 in 256 edge-case that can lead to continuous no-output. #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…cksum mismatch and therefore no output. If the last byte of the checksum is 0x42 it can be mistaken for the first start-byte, therefore checking the secondy start-byte is neccessary. The probability of this happening is 1 in 256 and in addition it has 100% probability if testing hepa-filtered air with 0 particels. Reason: All non-zero bytes remaining are: Decimal: 66 + 77 + 28 + 151 checksum: 256 + 66 Hex: 0x42 0x4d 0x00 0x1c ... 0x97 checksum: 0x01 0x42 It is not possible for byte 31 (second checksum-byte) to be 0x42 too, as the sum of the first 30 bytes is at most 30*255 which is less than 66 * 256 which is the smallest checksum that would cause byte 31 to be 0x42 (=66). The sequence 0x42 0x42 0x42 0x4d with the last two being the start bytes is therefore impossible. Though it is not impossible for the sequence 0x42 0x42 0x4d or 0x42 0x4d to appear at another position in the sequence it can only happen with particle count above 16896 = 66*256 and then this event is extremely unlikely itself and will extremely likely lead to a checksum mismatch therefore be discarded.
Setcover
changed the title
fixed formatting
this time using clang-format
|
@dherrada wanna test? |
Setcover
changed the title
|
Would switching to passive mode be an easier way to deal with this? It looks like the issue relates to determining the start byte(s) from a continuous stream of serial data (active mode). Datasheet is a bit sparse, but it looks like passive mode is more of a request/response setup.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the last byte of the checksum is 0x42 it can be mistaken for the first start-byte, causing a byte-shift which leads to checksum mismatch followed by no ouput (continuously in the HEPA edge-case).
Therefore checking the secondy start-byte is necessary.
The probability of this happening is 1 in 256 and in addition it has 100% probability if testing HEPA-filtered air with 0 particles.
Reason: With HEPA-filtered air all bytes are zero except:
start 1 + start 2 + frame-length + reserved
Decimal: 66 + 77 + 28 + 151 checksum: 256 + 66
Hex: 0x42 0x4d 0x00 0x1c ... 0x97 checksum: 0x01 0x42
Testing with hepa-filtered air, an arduino nano, software serial (2,3) the byte-shift with continuous no-output happened repeatedly after less than 10 measurement cycles. With disabled checksum-check the 15 uint16_t components of data then look like this:
Byte-shift.txt
---- considering & disregarding further edge-cases ----
It is not possible for byte 31 (second checksum-byte) to be 0x42 too, as the sum of the first 30 bytes is at most 30*255 which is less than 66 * 256 which is the smallest checksum that would cause byte 31 to be 0x42 (=66).
The sequence 0x42 0x42 0x42 0x4d with the last two being the start bytes is therefore impossible.
Though it is not impossible for the sequence 0x42 0x42 0x4d or 0x42 0x4d to appear at another position in the sequence it can only happen with:
which is both really unlikely and very likely not a stable condition with a low chance of multiple byte-shift leading to checksum-mismatch and continuous no-output.