by TazzI » Sat Oct 05, 2013 3:28 pm
Cool, I think I get it now.. after staring at 1's and 0's for a while and scrolling through logs.
So the Filter is a quick way of rejecting message based directly on the header bytes. And the mask is a more flexible moderator of what gets rejected and accepted based on the bits.
So using the above example, converting to its bits (10 2E 20 94)
priority|Arbritary|Sender = 1 0 0 | 0 0 0 0 1 0 1 1 1 0 0 0 1 | 0 0 0 0 0 1 0 0 1 0 1 0 0
If I then want to set a Filter of 10 2E 20 00, meaning I want to see messages with 10 2E 20 and dont care about what the "sender" byte. If I then want to further refine my searching, I can set the mask..
Using a mask of 1F FF FF 00, will look like this: (Read = header, Green = Arbitrary, blue = senderID)
1 1 1 | 1 1 1 1 1 1 1 1 1 1 1 1 1 | 1 1 1 1 1 0 0 0 0 0 0 0 0
So what are these 0's and 1's? Any "0"'s mean "I dont care", whereas the 1's mean "The received frame MUST match our mask".
Therefore, the mask is saying the CAN priority must match, the priority and destination must match, but the last 8 bits (SenderID) do not matter.
So in this example, out mask and filter are essentially doing the same thing. Although this can be set up to show things between say: 10 2E 20 17 and 10 2E 20 1F. Which would display info from different modules to the ID "20" from the modules between the values of 17 and 1F
This is what I *THINK* is going on. It kinda makes sense, and follows what Iv found in logs, although this is only an early interpretation and will need to test this out and see if we get messages that correspond to out filter + mask to prevent buffer full problems and look for specific messages.