how to convert BCD from serial to decimal

[LV_Enthu]

hello everyone, probably a dumb question. i have timestamp data in BCD format from serial port, which i want to convert to display as LV based timestamp. 

i have spend almost 4-5 hours trying to figure out how to do this - probably my brain has frozen now... 

can anyone help?

ex of data:

43(BCD) - should be displayed as 43 itself 

[GerdW]

Hi Enthu,

timestamp data in BCD format from serial port

Can you explain this with more details? The serial port usually gives you string data…

43(BCD) - should be displayed as 43 itself

So you get "43" and you want to display "43"? What's the problem? 😄

(You really should provide better examples!)

When you get a hex value (or a byte with a value of) 0x43=0d67=0o103=0b01000011 you could

- convert this byte to a hexadecimal formatted string (NumberToHexString)

- use quotient&remainder (aka modulo) to divide the byte by 16 to get both nibbles…

[RavensFan]

What have you tried.  (i.e. attach your VI).

Do you have an example of the string that comes in from teh serial port with an explanation of what it means?  Is each byte representing 1 digit?  Or are 2 digits packed into one byte?

[LV_Enthu]

i have attached the vi. it looks messy, however, if you look at the indicator (normal display -1) & (normal display -2), they indicate the format of data as is read by serial port. 

now, if i right click on the indicator and select display as hex - i see the numerical value of the data (which are element 3 till element 6).

i would like my data to be seen/captured/saved as is seen in element 3 to element 6. hopefully, it is clear now what i would like to do

[crossrulz · Accepted solution]

Sounds like you are looking to do something like this.

The Quotient & Remainder is used to seperate the upper and lower nibbles.  The upper nibble is then multiplied by 10 and added to the lower nibble.  From there, it is a matter of putting the data into the right location in the cluster.

[LV_Enthu]

That worked, thanks a lot. no way i would have come up with that logic... 

just out of curiosity, what is the palm -> labview symbol on the top of your snapshot? seen that lot many times 

[RavensFan]

Those symbols are put there by the Code Capture Tool.

I've never thought about specifically what they mean before, but now that you've asked, I 'm guessing it represents a Drag To LabVIEW since you can take that image and drop it into a LabVIEW block diagram.  (You may need to drag the image to the desktop first so it creates a graphics file, then drag that file to LabVIEW, depending on your browser and windows settings.)

[GerdW]

Hi Enthu,

another solution with less math and more string formatting:

On your VI:

- Why do you set a timeout of 100s on your COM port? Do you really want to wait for >1½min to receive a single byte?

- What's the purpose of the wait function in the loop? You either wait for a byte or you have to process this byte: no additional wait time needed!

- Why do you read byte by byte when your data consists of atleast 6 bytes (of the timestamp)?

- What's the purpose of BytesAtPort? You don't need it…

- When it comes to handle hex/BCD/decimal conversion: always, ever show the radix of numbers and display mode of strings! (As the string constant in my snippet)

- You don't need to wire the constants at IndexArray function, it automatically starts to index with the first array element…

- There's a special comparison function to check for empty strings!

- When the received string is empty you should have received a timeout error: do proper error handling!

[crossrulz]

---

@GerdW wrote:

- What's the purpose of BytesAtPort? You don't need it…

---

I'd argue that he does, just not the way he was trying to use it.

So I'm assuming the data comes in whenever it feels like it (not a continuous stream of data).  And based on the timeout (100 seconds!), it is rare to actually get any data.  So what I do in these situations is use the Bytes At Port just to see if a message has at least started to come in (ie see if there is any data on the port).  If there is data, read the entire message (in this case, 6 bytes).  If there is no data, put in a wait.  That 100ms sounds like a good wait time.  But this way we are making sure we process a complete message instead of a mixed up soup from two different messages.

The 100ms wait is in the FALSE case.

And a side note: That is a really odd baud rate being used.  Many serial ports likely will not support it.