09-06-2018 12:05 PM
You have the keys to the kingdom in your pants pocket and you don't even realize it. 😉
Since you were the one who created the protocol, you are the one that should know how to decode it! The first thing I do is break up the string into pieces that represent each piece of the message. For instance, if I have a message that is 6 characters long and I know the first four represent a U32, the next character represents 8 Boolean values, and the last byte is a mixture of 4 Booleans and a bit-packed number, break it out as 4,1,1.
The next step is to translate the raw data into something fit for human consumption. (Sometimes it's called 'cooked" data because it's something a human can easily digest.) For the U32, use "Unflatten From String" (so you can account for endienness if needed) and unflatten it as a U32. For the Boolean Array, you have to unflatten to a U8 and convert it into a Boolean array. For the last one, you have to get creative. I'd convert it into a Boolean Array then split it at 4 and 4, then take the "bottom" half of the split array and use Boolean Array to Number to convert it into a number. (I would use the smallest data type that can contain the number - in this case, U8.)
Hopefully this gives you an idea of what you have to do.
09-06-2018 12:10 PM
Again, you say "straight hex" which has zero information content. (Hex is a purely cosmetic convention to display binary data in human readable form). You apparently wrote the program that generates the binary data, so it would be trivial to reverse the operation given all specs (data type, header, byte order, checksum, etc. ) Whatever it contains!
09-06-2018 12:14 PM - edited 09-06-2018 12:16 PM
Apologies, I don't think I was clear enough in my original post.
Breaking the stream up into its constituent telemetry is not the problem. Obviously I know how to do that already, and have before when the incoming stream was ASCII hex, as I stated in the original post. Now the stream is hex (bits formatted as such, whatever you want to call it), and I still know how to parse it, but the problem is that Scan from String cannot ingest hex unless it's ASCII hex.
All I really wanted to know is if there is a setting to allow Scan from String to ingest a hex (and not ASCII) string, and if not, what module do I need to use to do that?
09-06-2018 12:23 PM
Apologies, I don't think I was clear enough in my original post.
Breaking the stream up into its constituent telemetry is not the problem. Obviously I know how to do that already, and have before when the incoming stream was ASCII hex, as I stated in the original post. Now the stream is hex (bits formatted as such, whatever you want to call it), and I still know how to parse it, but the problem is that Scan from String cannot ingest hex unless it's ASCII hex.
All I really wanted to know is if there is a setting to allow Scan from String to ingest a hex (and not ASCII) string, and if not, what module do I need to use to do that?
09-06-2018 12:33 PM - edited 09-06-2018 12:35 PM
Apologies, I don't think I was clear enough in my original post.
Breaking the stream up into its constituent telemetry is not the problem. I know how to do that already, and have before when the incoming stream was ASCII hex, as I stated in the original post. Now the stream is hex (bits formatted as such, whatever you want to call it), and I still know how to parse it, but the problem is that Scan from String cannot ingest hex unless it's ASCII hex.
All I really wanted to know is if there is a setting to allow Scan from String to ingest a hex (and not ASCII) string, and if not, what module do I need to use to do that?
09-06-2018 12:33 PM - edited 09-06-2018 12:34 PM
Perhaps it's time to stop talking about "what" you want to do and start talking about "why" you want to do it. That will help us understand the issue better and offer better solutions.
I don't think there's any easier way to parse the binary data than what was described above.
09-06-2018 12:38 PM - edited 09-06-2018 12:39 PM
@lavadisco wrote:
Was looking for a quick solution here, but the quickest thing to do given my greater experience in C vs LabView is to just write an ASCII conversion on the microcontroller that I can comment out later, which I already did and it works. However, in the future when I have time I'd like to re-write the VI to accomodate the hex stream.
Doing a raw to ASCII Hex is pretty simple in LabVIEW. Do note that this is very inefficient compared to directly parsing the raw data, but it will get the data in the format you seem to like.
09-06-2018 12:47 PM
That's wonderful, thank you! It may not be as efficient, but for my experience level it's an ideal thing to easily shoehorn into my existing VI. I'll give it a try.
09-06-2018 12:56 PM
The one "fact" you need is the length of the Hex String that your routine puts out. I'm going to be a bit arbitrary, and assume you are sending a byte at a time, encoded as 2 Hex digits.
One nice way to explore Scan from String is to start with its inverse, Format Into String. Here you see this in action -- I start with the number 123 (OK, not much imagination), see that the correct format for 2 characters in Hexadecimal, 0 padded, is %02x, output it, and pass it to Scan From String, with the same Format String, and out pops 123.
Bob Schor
09-06-2018 01:03 PM
crossrulz, what is the second to last element in the chain in the graphic you posted? The module just before the ASCII output. Can't find it.