Jump to content

data conversion problem


Recommended Posts

Here's how i did it....

Convert the text string you provided to a byte array.

assume each element in the byte array was a "packet" element as defined by the PDF provided.

Use the for loop to handle each array element and convert that into a boolean array so that I could determine which bits were ON/OFF.

Everything after that was just manually interpreting the PDF file. I didn't know which direction the data went so thats why I mentioned

the 2 choices....

If you want to automate the number recognition process, you'll have to relate the bits that are triggered to a specific "number" (ie. if bits 0,4,6 are ON, then the number '7' is displayed on the DMM. On the PDF file attached, Bit 0 corresponds to LED Seg A, Bit 4 = LED Seg B, Bit 6 = LED Seg C)

Regis

post-127-1114547981.jpg?width=400

Link to comment
  • 3 weeks later...
  • 7 months later...

OK, I got the meter for Christmas (RS22-812). It seems to spew continuous readings at about 4 per second with no apparent way to tell where one ends and the next begins except a small time pause. All my previous instrument experience is with equipment that answers to a response. Any ideas on how to pick the current reading out of the stream of bytes?

Link to comment
OK, I got the meter for Christmas (RS22-812). It seems to spew continuous readings at about 4 per second with no apparent way to tell where one ends and the next begins except a small time pause. All my previous instrument experience is with equipment that answers to a response. Any ideas on how to pick the current reading out of the stream of bytes?

can you post the VI that you're using to read the multimeter? Sometimes Tabs, Linefeed, or Carriage Return characters are used to separate data points....not sure in your case...it might be in the MM manual though...

Regis

Link to comment
I figured out one way. There are no characters between output strings, just a delay. I am doing a fast read and taking the 9 characters after blank read. If there are other methods or ideas I would like to try them.

You say 9 characters. But the string according to the earlier decoding only has 6 relevant characters. So those extra 3 characters might be some information but just as much one or two termination characters too. Depending on delays is a very unreliable operation and will fail sometimes. If you would capture a string or five and then display it in a string control configured to Display Hex Codes you could post that Hex code string and we might guess at what could be a good solution to detect the end of string.

Rolf Kallbermatter

Link to comment

There are no termination characters and no hardware hand shaking, just nine characters and a pause. The last character is a "CHECKSUM + 0x57". It is said that the documentation is incorrect and it is actually decimal 57 (0x39). I found a method that takes a sliding 9 bytes and computes the checksum. When the checksum is good the packet is passed out of the function (VB). I am going to give this method a try and report back.

Link to comment
  • 7 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.