errors in binary data

[Ashley.w]

Hi

I am getting some errors in the binary data I am reading over a serial link using the vi attached.

The vi removes the first seven characters (which are not part of the data string) then converts the binary data to an array of unsigned 16 bit integers.

There is a regular pattern to the error- every 10th number in the array has an error.

I am very confused and was wondering if anybody has experienced a similar problem. 

Many thanks

Ash

[TCPlomp]

Hello Ash,

there seems nothing to be wrong, but what data are you receiving? could you some data in the VI (run the vi, leave the values in the indicaters, save the VI and post it again.

Ton

[Ashley.w]

Hi Ton

Thanks for your reply

I enclose the vi again with the string indicators and array popualted with data.

Many Thanks

Ash

[altenbach]

bytes 0, 20, 40, etc. are x00 for some reason. What is the structure of the original data? Are you sure the other numbers are correct?

It is easier to see if you use a fixed-width font for the hex display, see attached.

[Ashley.w]

Hi

I am pretty sure the other numbers are correct.  The reason that I believe this is the case is because I can also read the data as a string of ASCII hexidecimal words and the binary data matches this except for where there are errors (0 and the every 20th byte).

The structure of the data is as follows:

I receive a binary string, starting with the Most Significant Bit of the first word, then the corresponding Least Significant Bit, where a word is two bytes long. A carriage return indicated message termination. The number of words returned is set by the value in the FPGA register ‘Bias_Ramp_Num_Steps’, and hence the number of bytes returned is twice this number. The return message starts with ‘bin,’ followed by the number of bytes requested. No delimiters are used to separate the data, but a carriage return is appended onto the end of the data.

bin,<first word msb><first word lsb>...<last word lsb><CR>

Many thanks

Ash

[SachaE]

Hi,

  so are you saying that if you set the instrument you're talking to to return the hex data as ascii versions (i.e. the text "002D" = a 4 byte transmit, rather than 002D a 2byte transmit (or two characters) you get the correct expected data?

As we can see from the data you've included, the 00's are there in the actual original data set, which I'm guessing is why Altenbach was asking if that was the numbers you were expecting.

The start of your actual read string is (using the slash code view) \r\nbin,\00\00,v$v\16 so to get to the first element, you need to skip the first 8 characters to be left at the ,v as the first word you're dealing with. You're currently skipping to position 7 which is \00, or 44 in hex as a word.

Is the ,v definitely the first word, or is it the v$  or the \00v and if you say that the message is
bin,<first word msb><first word lsb>...<last word lsb><CR>
then you should probably do a search for "bin," and work from the offset instead. That means your first two data elements would be 00 (or 0 as a word) then the ,v

The alternative would be to assume the \r\n on the end, and stipr that off the message. Reverse the string, and then typecast. Swap the byte order in the array of U16's, and then reverse the array again. Sounds like you're not gaining anything, but if the instrument definitely transmist as you have put it, then you would be guaranteeing the integrity of the message in words (2 bytes). (When I did this on your message, I got the same as your strip method of pulling off the first 7 elements)

Would that make more sense? What is the source of the message?

Thanks

Sacha Emery
National Instruments (UK)