LabVIEW
Reading and decoding binary packets with serial communication
Solved!
So you changed from the XSens sensor to the UM7_IMU? Why that? Ease of protocol can't be the reason, both offer NMEA talk only and a proprietary binary protocol.
As far as serial port communciation goes you have already discovered that there is ASCII and binary communication. And both have their own specific ways of dealing with it. Have you watched this presentation?
https://labviewwiki.org/wiki/VIWeek_2020/Proper_way_to_communicate_over_serial
The protocol is explained in the Datasheet linked on the site the UM7_IMU link points too. It's many pages and covers many messages. The basic structure however is fairly straightforward.
First there are three bytes consisting of the characters 's', 'n', 'p', (arbitrary marker standing for "Start New Packet") followed by a byte that contains the type of package and the number of databytes encoded if any. Then there follows a byte specifying the register address and 0 to 16 4-byte data integers. After that there are two bytes as a 16-bit checksum that is simply the byte sum with carry over of all previous bytes including the header.
Principally the minimum message length is 7 bytes, but can be up to 7+ 4 * 16 bytes. It's not very difficult to put together if you know the difference between byte, character and its ASCII code.
@constructionworker wrote:
The reason I switched from X-sens to UM7 is because I try to generate labview codes for all the IMUs I have. X-sens has some advantages and disadvantages and now I prefer the UM7 as the way of use has changed. After purchasing the compatible cable of X-sens, my job will be a little easier. Because I have a piece of code created for RS-232.
for UM7;
I looked at the link you suggested, but I don't know exactly how to use it as I can't read a more meaningful package.
Watch the video tutorial I linked to, not once and not twice but several times. Try to understand what Tim tells in there. It is uttermost important that you really understand his points before you wire up even one more LabVIEW wire for this project!!!
A byte is a byte is a byte is a byte! But there are a multitude ways to interpret it. As decimal number, hexadecimal number, binary number, but also as ASCII character according to the ASCII character table (which for more than half of the possible 256 values will show as gibberish like in your image, or as a sort hybrid form, which a LabVIEW string can also display, called backslash escaped mode. Right click on the string control and explore the options under Display Mode. In this backslash mode the string control will display printable ASCII characters as characters and the rest with special codes that start with a backslash.
What I don't fully understand is this: Do I need to call packet to read any value I want here? Or can I just read directly?
I can see the 's', 'n', 'p' characters when read as strings. I have attached a photo of the output in the picture below.
This is a command response protocol. The device will only send you specific data after you send it a command to return that data. You seem to currently have it in some shout mode where it sends some data continuously. I'm not sure that is how I would want to use such a device, it can overflow your serial port buffer very quickly and you always end up having to resynchronize onto the data stream. That makes writing a driver function much much harder, even though the "snp" string is a fairly easy way to find the start of a message.
Personally I prefer communication where I send a device a command and then will receive a fixed already known number of bytes or packets.
Check the manual. On page 47 is descripes the CREG_COMM_SETTINGS command which specifies that the 32-bit register has two bits called GPS and SAT which when enabled will cause the device to continuously spit out data whenever the GPS device provides a new GPS position or SAT position. I'm pretty sure you can disable that in the manufacturer software too, to not get spammed with messages from the device while experimenting to communicate with it.
Same for the CREG_COM_RATES1 - CREG_COM_RATES7 which all also configure batch messages being sent automatically. Until you have some basic communication working, you do not want your device to spit out messages on its own and making it hard to test if your communication even works.
But you should be able to also send this packet out yourself to the device with a VISA Write by writing the bytes and afterwards flushing the port to get any still pending bytes from previous device spewage out of the way. As to doing binary device communication, I told you in the other thread, get your caffeine reserves stocked up, and your stress relieve ball ready! You will need it!
Well that information certainly can be read. It's just how to get the information out.
If I would have to work on it, my first step would be to disable ANY automatic talk only traffic to not have to bother about finding a package in the incoming data stream. Then I would write a VI to write a package to the device for sending it a command and then one to decode the according response. This way you can concentrate on getting the actual package encoding and decoding right.
Only when that all works satisfactory can you think about going to enable the data spewing again although I would think very hard about that. With the batch message mode you can request a whole bunch of subsequent registers (up to 15) in one single read operation and that may be more than enough for your position and accuracy requirements. It's much easier to send out a command "Give me all the current readings for register 21 to 35" and then decode the according single resulting message, than having to continuously poll the serial port for messages, to try to find the start of the first package, decode it, determine if there is enough data present for one more package and decode that too and so on. And if you keep some data over at the end do we just throw it away or stash it somewhere to prepend to the next bunch of bytes to hopefully get a full package there too?
If you then decide that you do not want a command response request because that is not giving you the desired position update rate, then you can go and enable its automatic chatty mode and then start to bother about trying to make sense of all the incontinent data spewage of the device.
