It is the matter of view. This parser works like following

• read *ESE #B and now, only allowed characters are 0 or 1
• read 01010 and finish parsing this parameter, because next character is not 0 or 1
• except , to separate next parameter or end of string, but 2 is found -> invalid character
• read two more unexpected characters until end of command -> both cause invalid character

Same problem will be in all other parameters. If you write unexpected character, it will just responds with SCPI_ERROR_INVALID_CHARACTER and not more specific error.

To solve this, I must introduce "allowed but erroneous" characters for every parameter type and handle this completely different.

So

• It is not ideal behavior, but I think, it is valid behavior - do you agree?
• I don't want to solve this only for binary number, same behavior is for all other parameter types - it should be conceptual change
• I don't have much time to solve this. If you have some ideas or pull requests, I will be happy.

I understand the problem. This is certainly minor issue and also I just checked SCPI specification again and found following:

-101 Invalid character
[A syntactic element contains a character which is invalid for that type; for
example, a header containing an ampersand, SETUP&. This error might be used
in place of errors -114, -121, -141, and perhaps some others.]

So, technically scpi-parser is right here because -101 might be used instead of -121.