Problem communicating with Inertial Sensor

[arthas]

ninlmartijn, sorry, the sensor that I am using is not an Agile-Link product. The details of the sensor that I am using now  is shown in this link:

http://www.microstrain.com/inertia-link.aspx. 

I have tried testing with the LDC example though.. and it doesn't give any positive results 😞

you mentioned before that It is possible to send the 02 string in MAX and check if the device response. How do I send the 02 string? Sorry, this is actually the first time I am using MAX so I am still not used in using it.

Thank you very much for your time. I really appreciate your help

[ninlmartijn]

Hello Arthas,

Thank you for your reply. There is no need to test the serial pot by MAX. The VI we used did the test, and there was a right response from the serial port device (base station).

I think the program works OK but that the time out occurs because there is no data available at the serial port. I thin (but that is just a thought) we have to select a node address. The example I send was just for reference. The example is for a USB device, so it won't work for you hardware. But it will give us a idea how to put the program for your sensor together.  In the example there is a VI where the node address is selected. Question is if a similar VI was delivered with your sensor where we can select a the node address. I'm beginning to think that we have to put a VI between the serial init vi and the read VI. 

I think at this moment we are talking to the base, but the base is not collecting data from the sensor. I think we have to select the sensor by the node address. Unfortunately I can't test this because I don't have the hardware, and I'm rather new with this kind of sensor. Please let me know if there is a VI to select the node address.

Best regards,

[arthas]

Ok, I realised that the Agile-Link LabVIEW codes provided by the company can communicate with the sensor. There are several subVis that can read/write the base station as well as the sensor itself. I have attach the subVis in this post. I think what you said is right, that I am indeed communicating with the base station so far and not with the sensor. Thanks to your help  ninlmartijn, I am getting much closer on solving this puzzle 🙂

I have problem now on arranging the subVIs attached in this post so that I can get the sensor's response correctly. Just curious, do we normally write/send the command byte to the base station or the sensor itself? Because if I want to send a command byte (xC2 in thsi case) to the base station, I can just use "Serial Write VI" and write a command byte to it right?

Message Edited by arthas on 08-19-2008 04:17 AM

[ninlmartijn]

Hello Arthas,

I'm happy to look into this issue and to expand my knowledge about working with these sensors. So again; thank you for your post!

I think you have to use the node VI's; when you compare base write and node write they are the same; with the node VI you can set the node address. I suspect that with the first screenshot you gave, the node VI's have to come in between the ini and read VI's. But this is just a guess, based on the example I referred to earlier.

Best regards,

[arthas]

ninlmartijn, apparently I have to send the command in a packet form to the sensor in order to get the readings. I have attach a modified "Ping Node" subVI that i have sent earlier. It is basically similar as the previos one except that this time I changed the data to be connected to the write buffer input of "VISA Write vi" in the 2nd frame (1[0..4]) of the Stacked Sequence. I have also attach a screenshot showing the format of the packet structure to be sent to the sensor. Notice that the data i write to the write buffer of "VISA Write vi" (AA 0B 00 <Node adress> 2 0 C2 <checksum value>) is basically the same as the values shown in the screenshot (column 3 of the table). The node address is 87 by the way. The command byte that i am sending is C2. 

The sensor does send a respond but it sends a 0x21 message, indicating that the sensor rejected the request because of the packet error. This error may due to the improper checksum value or perhaps some other problems. I suspect the former one as I am not so sure on how to calculate the checksum value. In the screenshot shown, the checksum is calculated by the sum of all bytes except the SOP one. At the moment, I set my checksum value as 8 (0x08). 

Hope you can help me check if it is really the checksum problem or maybe I have done something wrong that I didn't notice. I have tried asking the company for help but they just dont tend to help me out. Thank you for your time

[ninlmartijn]

Hello Arthas,

So the sensor is responding (at least something), so we are a step further in solving the puzzle. I did had a lok at the library from our web site (the one from a few posts ago), and I think its best to take the ping vi from there and adjust it with our string commands. This one has different commands, but we can easily put the right commands in the string constant. I think the major difference is some calculations in the checksum. Please remember to flush the buffer before setting up a new transmission.

Also I did see a ping table in the link you send me;

Function: The Inertia-Link® or 3DM-GX2™ will echo an 0x02 if the

wireless communications is setup and working properly,

otherwise the base station will return a 0x21

Command Byte: 0x02

Command Data: 2 bytes defined as follows

Byte 1 MSB of node address

Byte 2 LSB of node address

Response: 1 byte defined as follows

Byte 1 0x02 if wireless comm is OK. 0x21 if wireless comm is not

OK

This differs from the command you wanted send. Does ping with this command work? This is the first step. I did see a VI in the library to wake the node; three pings were send before communication was set up. Best thing to do is to ask your vendor if this is needed (because I looked to another sensor). They shold provide you with a flow hart ore something how to set upthis communication. This flow chart isn't only for Labview but is important for all languages.

After that we are going to try to get measurements out of the sensor;

AA - 0B 00 - address (2 bytes) - 02 - 00 2 bytes - C2 - 2 byte checksum

Another important thing to consider is if the sensor is in polled mode or continuous mode (normally the sensor starts up in polled mode, but it is no harm to check). I think for this command you have to be in polled mode. I hope this will give you a good starting point to work further from. Good luck with your application, and please let me know if it works.

Best regards,

Martijn

[arthas]

Thank you for your quick reply, ninlmartijn. The sensor sends a '21' response when i changed the command byte to 0x02 (ping command) instead of 0xC2 (command to read acceleration and angular rates). However, if I remove all the "AA 0B ..." messages and just send the 0x02 command byte along with the node address of the sensor, as shown in the screenshot i attached in this post, the sensor will send 0x02 response.  There is one interesting result; whenever i set the "byte" numeric value in the front panel to 2 (from reading the inertial with labview vi in my previous post), the sensor will respond "AAAA AA".  The sensor is already in polled mode by the way. I believe it is the check sum value that is the problem. 

[ninlmartijn]

Hello Arthas,

AAAA AA is good news; data acknowledge (sensor does respond wit this) and start of packet begin with AA. So the first AA states that the message is ack (by base), the second AA is start of first packet, and the last AA of the last packet (please refer to p12 of the protocol manual ).

You did send only a C2 command and a node address. I think these stings are packetized somewhere later in your VI, It has to be packetized.

The reply should look like this (p11 below);

Base station sends ACK: 0xAA

Sensor sends reply: 0xAA, 0x07, 0x00, <2 byte node add.>, 30,

0, 0xC1, <28 bytes of data>, <LQI byte>,

<RSSI byte>, <2 byte checksum>

I'm not sure if the C1 before the 28 Bytes is correct (you did send a C2 command) so this could be a misstake in this manual. Is it possible to read only the buffer to see if this is true?

We are comming closer and closer,

Best regards,

[arthas]

Yes! the sensor finally responds! :D. It is the checksum value that causes the sensor to send a failed response message. The correct checksum is computed by summing up all the bytes (0B + 02 + C2 + 57(Hex numbers for node address 87)). I must thank you for helping me out to solve this puzzle as your opinions and ideas really help me out alot. Without your advices, I believe I couldnt have get this far. Your idea to use the "ping vi' to send the command byte messages really gave me alot of ideas on troubleshooting the sensor's communication.If possible, can I have your name? I would like to acknowledge you in my report for my project.

There is one more problem. I would like to get an accurate time value when the sensor acquires the data in LabVIEW. The sensor's frequency is 100Hz or 1 sample per 0.01s. So if possible I would like to have a time array value such that the  time array would have a value at 0s in1st element, 0.01s in 2nd element, 0.02s in 3rd and so on till I stop the session. However, I realized that the VISA communication will cause my program to run with delays, so I would like to determine the delay time too to add to the time array. I have tried putting the "timer vi" but it gives me funny values. Then I realized that the sensor too sends a timer response value(Bytes 26-29 as according to the manual page 13 in the C2 command section). According to the manual in page 25, I should divide that timer value by 19,660,800 to get the time in seconds. Again, i got some weird values after doing that.

I have attach the program vi here.  I hope you can help me out with this issue. I would like to know if it is also possible to reduce the delay of the program. Thanks again and hope you have a great weekend ahead.

Cheers~ 

[ninlmartijn]

Hello Arthas,

Great I could help, this was also a good experience for me; I didn't had much experience with communicating with this kind of sensor. Now I can add this to my knowledge. By the way; I'm Martijn Smeulers, from NI Netherlands, where you from?

The interpreting from the timer seems to be correct. I did some tests and the outcome is what I suspected. The timer from the sensor flips over every 219 seconds. In between it counted from 0 to 4,294,967,295 between second 0 and 218. So every second corresponds with 218 / 4,294,967,295 .

I suspect that we have to look how we typecast the data. You did search to CF (within the strings), but you did send the C2 command, is this correct? The type cast is what I should suspect after the C2 string.

I didn't see timing in your loop. If you are building in timing, it gives the CPU some time to handle some other processes (for example your front panel handling), if you don't time your loop it tries to run as quick as possible and consumes all CPU time.

I hope this will help you further. I'm only in the office at the end of this week but if there is a issue I will reply as soon as possible.

Best regards,