Weird characters received from instrument using serial communication in labview

[altenbach]

So the most interesting is probably the second word in each set of 8 bytes. If we interpret it as little endian 16 bit integers, here's how the data looks like.

Does this pattern look interesting in terms of the experiment or in terms of what you expect?

[altenbach]

And here's how the data aligns with the various exceptions:

[aj_dee]

Yes, this looks like the open circuit voltage that I expected to receive over the period the data was recorded. 

[altenbach]

I suspect that the groups not starting with x0030 are some kind of marker values indicating a new dataset. Here's how you could graph the data without them.

Of course many thing might need to get tweaked once more information is exposed. For example, it could be that all we need is parse the third byte as U8 since the fourth byte is always zero unless we are dealing with a "marker".

[altenbach]

---

@altenbach wrote:

For example, it could be that all we need is parse the third byte as U8 since the fourth byte is always zero unless we are dealing with a "marker".

---

Here's how the code for that could look like. Same result:

There are dozens of other ways to do all that, of course. So adapt to your situation as needed.

[aj_dee]

Thanks, can you kindly attach the vi in the snippet?

[altenbach]

---

@aj_dee wrote:

Thanks, can you kindly attach the vi in the snippet?

---

it is just a picture, not a snippet! (The term "snippet" has a very special meaning in LabVIEW)

Here's the VI.

[Bob_Schor]

You know, you are asking @Altenbach and others who might be "intrigued" by this question of "data unencumbered by the code that generated it" for help, but have provided almost no information about "what you expect" to see, and from where these data have been derived.  One assumption is these are data you generated with some LabVIEW (?) code, so you know something about what to expect (i.e. "1 channel of 16-bit analog data sampled at 1 kHz" or some other description, even better, the LabVIEW code that produced these data).

To me, just looking at what appear to be 337 8-byte records, I'm going to hazard a guess at the source:

The data appear to be 337 samples consisting of the following 4 16-bit (or "word") quantities:  When I say "row" or "column", I'm using the index 0 for the "initial" row or column.

• Column 0 -- a "marker" or "flag", value of 3 for "Analog Sample" and 0 for "some unknown data type", which occur in rows 153 and 332.
• Column 1 -- 16-bit signed analog samples saved in offset-binary, where 32768 represents 0 V, with higher numbers being positive (up to 65535, which represents 32767 "units" of positive voltage, with 0 representing 32768 "units" of negative voltage).  Exceptions are again rows 153 and 332, where the number is 2561.
• Column 2 -- another "binary flag" column, having the (hex) value 100 (or 256 decimal) everywhere except rows 153 and 332, where it is 0x7900 (row 153) or 0x9200 (row 332).
• Column 3 -- Hex value 0x29 (decimal 41) except rows 53, 157, 187, 235, and 276, where is is 0x28 (decimal 40).

That's my last contribution "for free".  Time for you to be more forth-coming about the source and meaning of these data.  Did you (yourself) obtain them using LabVIEW?  From what sort of instrument?  What do the numbers signify?  Show us the LabVIEW code (as real LabVIEW files, preferably a zip-compress copy of the Project Folder, even more preferably saved in LabVIEW 2019 or 2021 (at the latest).

Bob Schor

[altenbach]

---

@Bob_Schor wrote:

I'm going to hazard a guess at the source...

---

... or basically what I said yesterday. 😄

[Bob_Schor]

---

@altenbach wrote:

---

@Bob_Schor wrote:

I'm going to hazard a guess at the source...

---

... or basically what I said yesterday. 😄

---

I agree with you (with a little more explanation, including the suggestion that the A/D is using offset binary, and probably only Channel 1 is an A/D signal, no idea what the others represent).  I do think the O.P. is abusing the help we are trying to provide ...

Bob Schor

P.S. -- note Message 19 in this chain ...