kelbro Posted April 26, 2005 Report Share Posted April 26, 2005 I'm getting a string formatted like this: Q Quote Link to comment
Kurt Friday Posted April 26, 2005 Report Share Posted April 26, 2005 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. Quote Link to comment
i2dx Posted April 26, 2005 Report Share Posted April 26, 2005 I'm getting a string formatted like this: Q Quote Link to comment
kelbro Posted April 26, 2005 Author Report Share Posted April 26, 2005 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. Quote Link to comment
AnalogKid2DigitalMan Posted April 26, 2005 Report Share Posted April 26, 2005 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: Quote Link to comment
kelbro Posted April 26, 2005 Author Report Share Posted April 26, 2005 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. Quote Link to comment
regisphilbin Posted April 26, 2005 Report Share Posted April 26, 2005 does this string represent the numbers 0537 or 7350? Quote Link to comment
kelbro Posted April 26, 2005 Author Report Share Posted April 26, 2005 does this string represent the numbers 0537 or 7350? 4664[/snapback] Hey hey! It was 5.37 VDC Quote Link to comment
regisphilbin Posted April 26, 2005 Report Share Posted April 26, 2005 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 Quote Link to comment
regisphilbin Posted April 26, 2005 Report Share Posted April 26, 2005 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 Quote Link to comment
AnalogKid2DigitalMan Posted April 26, 2005 Report Share Posted April 26, 2005 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. Quote Link to comment
regisphilbin Posted April 26, 2005 Report Share Posted April 26, 2005 Thanks... if anyone knows how to handle the last 2 values, i'd be curious to hear how to decipher them... Regis Quote Link to comment
kelbro Posted April 26, 2005 Author Report Share Posted April 26, 2005 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. Quote Link to comment
regisphilbin Posted May 18, 2005 Report Share Posted May 18, 2005 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 Quote Link to comment
Megavolt Posted December 29, 2005 Report Share Posted December 29, 2005 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? Quote Link to comment
regisphilbin Posted January 3, 2006 Report Share Posted January 3, 2006 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 Quote Link to comment
Megavolt Posted January 7, 2006 Report Share Posted January 7, 2006 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. Quote Link to comment
Rolf Kalbermatter Posted January 9, 2006 Report Share Posted January 9, 2006 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 Quote Link to comment
Megavolt Posted January 14, 2006 Report Share Posted January 14, 2006 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. Quote Link to comment
Oslo Posted April 6, 2013 Report Share Posted April 6, 2013 Megavolt, can you help me with solve the mistake for the last package: CHECKSUM+0x57... Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.