Home › Forums › GP9 Product Support › Partial Data Transmission?
This topic contains 5 replies, has 2 voices, and was last updated by Caleb 12 months ago.
-
AuthorPosts
-
For some reason, when I choose to have the “Euler Angle Broadcast rate” reporting in the broadcast rates - states section of the configuration utility, the only registry item coming back is 78, with the roll and pitch. I need to get the yaw information, which is in registry 79.
When I look at the log file that the configuration utility puts out, It only provides line items beginning with “0x736E70CC78,” with the last “78” being the registry for only the roll and pitch. The configuration utility, however, is able to accurately and responsively chart the yaw, so somehow the data is actually being picked up by the configuration utility.
In my own c++ code on Linux, I am also able to grab the data, but the only data that is coming back is that from registry 78, just like the utility log file.
Just for a sanity check, I turned on reporting for all the data I could and checked the log file from the configuration utility. I only had about 6 different registries coming back, and I would have expected more. I tried different baud rate and reporting frequencies, but to no avail. It’s as if only the first packet of the group of associated packets is being picked up by the utility log and my code.
Why doesn’t the configuration utility or my own code get the “79” registry? And how can the configuration utility be accuratly and responsively graphing the yaw anyway?
-
The data transmitted by the GP9 is sent in batch packets, where more than one register is transmitted in the same packet. You can find details about the communication protocol in the datasheet here: http://www.chrobotics.com/docs/GP9Datasheet.pdf
-
How can I get all the registers in the log generated by the CH Robotics configuration utility?
-
Consider, for example, the packet that you provided in your example: 0x736E70CC78…
The packet-type byte in this packet is 0xCC, which in binary is 0b11001100
As specified in the datasheet, this means that the packet has data and that it is a batch packet, with a batch length of 3 registers. The register address of this packet is 0x78 and contains register 0x78, 0x79, and 0x80.
-
This reply was modified 1 year ago by
Caleb.
-
This reply was modified 1 year ago by
-
OK, so in the example of 0x736E70CC78F2FE008BC0D7000044596B0CBB07, according to the information in the datasheet, I would interpret this as meaning:
“736E70” is SNP,
“CC” is information about the packet, being translated from hex to binary as 11001100 and meaning (1XXXXXXX) has data, (X1XXXXXX) is a batch, (XX0011XX) batch length is three, (XXXXXX0X) it is not hidden, and (XXXXXXX0) the command has not failed.
“78” is the one and only time that a registry is named in this package
“F2FE” is roll,
“008B” is pitch, completing the information in registry 78. We know that 79 is the next registry to come, because it is the next registry of a total of three starting with 78.
“C0D7” is yaw from 79,
“0000” are the unused bits identified for registry 79. this ends registry 79 and we now start registry 7A.
“44596B0C” is the time.
“BB07” is the checksum.-
That looks correct. Yes, the registers go from 0x78 to 0x7A, not 0x80 as I mistakenly indicated.
-
-
AuthorPosts