Unable to read 9th bit value

[VenuGopal@57]

There is no such manual for the device. it's an R&D device which was made according to the customer requirement. i have highlighted the bit.

[GerdW]

Hi Venu,

---

VenuGopal@57 wrote:

Simplified my code and attached the screenshot. In row row 8 9th pin should be 1.

---

• Use JoinNumbers to create an U16 from your two U8 values after the StringSubset. Then convert the U16 to a boolean array and you will be able to access the 9th bit…
• Use BuildArray to append the second boolean array to the first one (after the NumToBoolArray functions). You will get a booelan array of 16 bits and will be able to access the 9th bit…
• Use UnflattenFromString after the StringSubset to convert the 2 bytes into an U16 (with correct byte order). Then convert to boolean array…

So many options: learn about bytes, words, longwords (aka datatypes) to handle your data correctly!

---

VenuGopal@57 wrote:

it's an R&D device which was made according to the customer requirement.

---

Ask your R&D department for a manual!

[VenuGopal@57]

Join numbers doesn't work as expected. it throws error. correct me if I'm doing wrong

[Yamaeda]

Do a build array on the boolean arrays and you should get 16 bits/row

[Bob_Schor]

---

VenuGopal@57 wrote:

Hi Bob, 

Good morning,

Currently i don't have the hardware with me. But i can explain how it works. I request data from board with a fixed command. The hardware sends me the data at VISA read i receive data in Hexa. it is only clearly visible when we use typecasting. The data in the array3 contains info of pin numbers at 7th position. i have requested hardware for 9 pin data so in the array 3 you can see the data received at serial port for 9 times. for the next iteration i might request 15, 25 upto 78.

---

You didn't read or understand my message.  Array 3 contains (at least) information for 16 (not 8, or 9) positions.  The first byte (shown as going 01, 02, 04, ..., 80, 00) represents one more than the u8 value whose bit position is encoded (so it would be "bit 0, bit 1, bit 2, ... bit 7", i.e a byte with exactly 1 bit set), and the value of this strange number corresponds to the bit number that is set (i.e. the values are 0, 1, 2, ... 7).  The second byte does the same thing, but now (when you consider the two bytes together, with the first byte being the low 8 bits and the second being the high 8 bits, again exactly one of which is set), you can extend the values encoded in these 16 bits as the "values of the set bits", 0 .. 15.

I have no idea why someone would want to adopt this odd encoding (you have to order N bytes in the proper sequence, low byte first, set exactly 1 bit in those N bytes, and thereby encode a number from 0 to 4N-1 -- extremely confusing, extremely inefficient, but that's what your data are suggesting.

Bob Schor

P.S. -- please, do send us the (binary, I suppose) data (in whatever form it comes to you) that makes up the input array, Array 3.  I need to "see this to believe it".

[crossrulz · Accepted solution]

---

VenuGopal@57 wrote:

There is no such manual for the device. it's an R&D device which was made according to the customer requirement. i have highlighted the bit.

---

Here's how I would handle this.

[Bob_Schor]

This is so badly screwed up!  Your device is "talking to you" in binary, not in text form.  The "strings" that you are processing are the "Hex Display" of the 8-bit binary characters you are getting from your device.

What this probably is due to, especially if the device is supposed to communicate in text, is that you have the Communications settings messed up, probably the Baud rate (if you had the number of bits wrong, 7 instead of 8, you'd see things that look like text but not quite making sense).

A Big Fat Clue that this is the case is to put a cursor on, say, the string "AA99 0005 A201 0100 94" and attempt to move it one space to the right.  It jumps 2 characters, from "AA" to "99", and another move takes it to "00" (skipping the what-looks-like-an-obvious-space").

Now, rightc-click the string, take it off "Hex Display", and look at the "string" in "Normal Display".  Here's what I see:  ª™  [There are really more characters than that on my Front Panel view, but they aren't legitimate Ascii, so they aren't displayed here.] 

Look at line 6, which ends in B5.  B5 in Hex = 181 in decimal.  If you open Character Map (in Windows) and look at the character mapping shown, look for the symbol µ (Greek lower case "mu"), 6 rows down.  That's the character represented by 0xB5, and if you express line 6 with "Normal Display", it will show "µ" at the end.

So you need to set the Serial Port settings appropriately for your device.  It is trying (I think) to send you strings, but it is talking either "faster than you are listening" or "slower than you are listening", and bits are going astray!!

Bob Schor