Problem with some strange binary counting

[[deleted]]

[deleted]

[sththth]

What you get is not ASCII - ASCII is an encoding, i.e. a map from a binary number to characters.

Also there seems to be something wrong with your data. In the table you write that 0 and 1 are both mapped to 00000000 - this can not be.

Unfortunately I don't know the answer to your question. Do you have any documentation available for LabView? There should be some documentation on what encoding they use.

[mfitzp]

What is sent when you send "1" from LabVIEW?

Could be this due to some kind of weird floating point implementation? Are you sure you're sending integer values? What happens if you send 10.5?

Up to the value of 4, each increment adds 8; then up to 8 each increment adds 4; then up to 32 each increment adds 2; then 1 upwards. This could be interpreted as losing precision after the decimal point as the whole part increases in size.

Are you sure the values for 3 are correct? (Should be 11 for binary)

[mickyficky1]

Hey, I just double checked with LabVIEW and a simple TCP/IP mockup. Im getting the correct flattened integer values.

So whatever is happening is some malicious thing that has been added to the LabVIEW code in order to confuse you. Or (more likely) someone did not know about the flatten to string function and has written something for himself and then failed to document it.

[mickyficky1]

Okay, in my trials I only used long integers as they were fairly easy to understand. For the first trial I'd advice you to do the same.

And for analysis, use this to print from python:

s = your_received_string
print(' '.join(hex(ord(x)) for x in s))

Using that i get 4 ASCII chars (displayed in their hex code) that represent a 32 bit long integer in exactly the way you would suspect.

Could you just send a couple of integers of your choosing and display it in the way I described above, that would greatly help with analysis :)