data conversion problem

[kelbro]

I'm getting a string formatted like this: Q

[Kurt Friday]

What type of meter and what model?

Do you have any documentation?

Check your serial settings as well, if your baud rate is out then your data will be garbled.

[i2dx]

I'm getting a string formatted like this: Q

[kelbro]

It's a Radio Shack 22-812 DMM. No documentation available except baud rate. I can see that the baud is correct because any other setting garbles the data and it is not consistent. RS has an application that displays the output but I can't use it for my application.

[AnalogKid2DigitalMan]

It's 4800 , *, No Parity, 1 stop bit

Here's a link:

http://support.radioshack.com/support_meters/doc68/68424.pdf

I suggest dowloading meter view to test if meter is working, see link

http://support.radioshack.com/productinfo/...Results&Reuse=N

Have fun, looks like the data format is a hoot! :headbang:

[kelbro]

Thanks. Yes, that's the setup and the software that I have that does work. I'm wanting to just pull the values out and graph them in a VI.

[regisphilbin]

does this string represent the numbers 0537 or 7350?

[kelbro]

does this string represent the numbers 0537 or 7350?

4664[/snapback]

Hey hey! It was 5.37 VDC

[regisphilbin]

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

[regisphilbin]

After more playing around....

I realized that Bit 3 corresponded to the location of the decimal point.

I also mapped out the bit - to - numerical string (with and without the decimal point) so that any string you bring in *should* give you the correct output result.

Again, i'll leave it to you to double-check my work and try it out...

Regis

Download File:post-127-1114552006.vi

[AnalogKid2DigitalMan]

Good Work Regis!

Kelbro's got questions, youv'e got answers! :worship:

Looks like the Shack took the easy way out (and cheapest?) by sending each digit's segment status.

[regisphilbin]

Thanks...

if anyone knows how to handle the last 2 values, i'd be curious to hear how to decipher them...

Regis

[kelbro]

Thanks for all of the help. Unfortunately, it will be next Monday before I have a chance to try it out. Heading to the airport. Biz travel the rest of the week and commuting home and back this weekend. 6000 air miles between now and Monday. 3000 of them on Friday.

[regisphilbin]

I wanted to repost the updated VI for this topic.

Correction:

- The numeral 9 wasn't defined correctly in the software.

Regis

Download File:post-127-1116431877.vi

Download File:post-181-1161863433.doc

[Megavolt]

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?

[regisphilbin]

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

[Megavolt]

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.

[Rolf Kalbermatter]

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

[Megavolt]

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.

[Oslo]

Megavolt, can you help me with solve the mistake for the last package: CHECKSUM+0x57...