Hello, does the file contain literal '1' and '0' ASCII characters? The binary import module will see them as values 0x30 ('0') and 0x31 ('1') in that case.

(In reply to Soeren Apel from comment #1)
> Hello, does the file contain literal '1' and '0' ASCII characters? The
> binary import module will see them as values 0x30 ('0') and 0x31 ('1') in
> that case.

Hello Soeren,
thank you for the swift reply.

Yes it contains ASCII '0' and '1'. And generally it works. The number of '1's and '0's are the number of samples for each trace section. You can try yourself by importing this ASCII file as raw binary. Expected is a square wave with low and high section each 10 samples. But what you get are high sections of 10 samples and low sections of 12 samples. Testing with another sample file it seems that the \n is treated as a logical 0

SO I see it is mor an unexpected feature than a bug. But it would be nice if the counterpart of 0/1 digits logic data would exist. Raw binary import is close to that. There must be a decision in the code to treat the file as ASCII 0 and 1. And then all whitespace characters should be ignored.

Regards, Robert

There is no problem here with importing binary data, neither in the 
interpretation of the data nor in its presentation. The input module that 
you requested to use did exactly what it's supposed to do: take the bytes 
that you feed at their value and interpret them as sample data. It's a mere 
coincidence that the "letter 1" with code 0x31 happens to have its least 
significant bit set, and that the line feed (you did not provide "the file" 
so I'm guessing LF aka 0x0a here) happens to be even with the LSB clear.

There is no way that the raw binary(!) input module would start guessing and 
putting special meaning into the bytes it receives. That'd break the very 
point of this input module. If you want to use different input formats than 
raw binary data, pick one from https://sigrok.org/wiki/Input_output_formats 
instead. If you want to keep abusing an implementation detail of the binary 
input module, consider providing the "proper" input data by applying external 
tools on the input file before feeding it to the sigrok software. They were 
made for this purpose. See tr(1), xxd(1) or similar text manipulation tools 
or format conversion utilities.

I consider this report "invalid" (no problem found, neither a fix nor a 
workaround required). Thus am closing the report.

(In reply to Gerhard Sittig from comment #3)
> There is no problem here with importing binary data, neither in the 
> interpretation of the data nor in its presentation. The input module that 
> you requested to use did exactly what it's supposed to do: take the bytes 
> that you feed at their value and interpret them as sample data. It's a mere 
> coincidence that the "letter 1" with code 0x31 happens to have its least 
> significant bit set, and that the line feed (you did not provide "the file" 
> so I'm guessing LF aka 0x0a here) happens to be even with the LSB clear.
> 
> There is no way that the raw binary(!) input module would start guessing and 
> putting special meaning into the bytes it receives. That'd break the very 
> point of this input module. If you want to use different input formats than 
> raw binary data, pick one from https://sigrok.org/wiki/Input_output_formats 
> instead. If you want to keep abusing an implementation detail of the binary 
> input module, consider providing the "proper" input data by applying
> external 
> tools on the input file before feeding it to the sigrok software. They were 
> made for this purpose. See tr(1), xxd(1) or similar text manipulation tools 
> or format conversion utilities.
> 
> I consider this report "invalid" (no problem found, neither a fix nor a 
> workaround required). Thus am closing the report.
Herr Gerhard,

Thanks for your  response. And it's good that there is no unintended behavior in the code, at least not here. Yes I know that I can use other import methods, and how to transform data into that format. But that seemed to be the most simple style. And it works if the file just contains ASCII 0 and 1 and not other characters, and I limit the input to 1 channel.

I should say that I like that pulseview/sigrok very much and started to use it instead of apps supplied with the respective hardware vendors, especially because of its flexibility. And if you happen to be one of the developers or contributors, let me express a big "Thank you".

Kind Regards, Robert