mmr/Livox-SDK
Archived
1
0
Fork 0
Code Issues 105 Pull Requests 11 Actions Packages Projects Releases 9 Wiki Activity

Heartbeat Packet Format #9

New Issue
Closed
opened 2019-05-14 15:54:17 +02:00 by ryan-brazeal-ufl · 4 comments
ryan-brazeal-ufl commented 2019-05-14 15:54:17 +02:00 (Migrated from github.com)
Copy Link
Copy Source

Hello,

I am a graduate student in geomatics at the University of Florida and I have just begun development of a Python3 driver for the Mid-40 sensor. I am using a Mac computer and hence don't have the ability to run the binaries that Livox provided and therefore I can not thoroughly packet sniff the valid UDP communications. I have been able to follow the SDK documentation and acquire and parse the broadcast message (coming in on port 55000). I have tested the CRC16 and CRC32 checks using the initial values stated in the SDK and everything in my code agrees with all the broadcast messages coming in over all 255 frame sequences.

This is the command (hex) that I send to the sensor as a connection/handshaking request, which sets my IP to 192.168.33.1 and the point cloud port to 1981 and command port to 65000:
AA 01 17 00 00 00 00 64 39 00 01 C0 A8 21 01 BD 07 E8 FD 1E 25 F9 12

Upon sending the connection request, I receive the following response message (coming in now on port 65000, as excepted):
AA 01 10 00 01 00 00 64 53 00 01 00 F1 34 3C 29

The content of this message is as expected and the 5th last hex char (00) indicates to me that the connection request was successful, as per the SDK. At this point in time I send a heartbeat request command. The following command is what I send:
AA 01 0F 00 00 00 00 04 D7 00 03 38 BA 8D 0C

I am under the assumption that the hex chars in this command will always remain the same every time a heartbeat request is sent? Unfortunately, after sending this heartbeat request command, I do not receive a response message. After the heartbeat timeout occurs I once again receive the broadcast message over port 55000.

My question is, are you certain that your documentation is correct for the heartbeat command format? I am hoping that you could examine my command messages and ensure that my understanding is correct and that they conform to your standards.

Thanks,

Ryan

P.S. You have a mistake in your SDK documentation in section 2.1, Frame Format. You state that the Size (bytes) of the crc_32 Whole Frame Checksum is 2 bytes when it should be 4 bytes (i.e., 32 bits).

Hello, I am a graduate student in geomatics at the University of Florida and I have just begun development of a Python3 driver for the Mid-40 sensor. I am using a Mac computer and hence don't have the ability to run the binaries that Livox provided and therefore I can not thoroughly packet sniff the valid UDP communications. I have been able to follow the SDK documentation and acquire and parse the broadcast message (coming in on port 55000). I have tested the CRC16 and CRC32 checks using the initial values stated in the SDK and everything in my code agrees with all the broadcast messages coming in over all 255 frame sequences. This is the command (hex) that I send to the sensor as a connection/handshaking request, which sets my IP to 192.168.33.1 and the point cloud port to 1981 and command port to 65000: AA 01 17 00 00 00 00 64 39 00 01 C0 A8 21 01 BD 07 E8 FD 1E 25 F9 12 Upon sending the connection request, I receive the following response message (coming in now on port 65000, as excepted): AA 01 10 00 01 00 00 64 53 00 01 00 F1 34 3C 29 The content of this message is as expected and the 5th last hex char (00) indicates to me that the connection request was successful, as per the SDK. At this point in time I send a heartbeat request command. The following command is what I send: AA 01 0F 00 00 00 00 04 D7 00 03 38 BA 8D 0C I am under the assumption that the hex chars in this command will always remain the same every time a heartbeat request is sent? Unfortunately, after sending this heartbeat request command, I do not receive a response message. After the heartbeat timeout occurs I once again receive the broadcast message over port 55000. My question is, are you certain that your documentation is correct for the heartbeat command format? I am hoping that you could examine my command messages and ensure that my understanding is correct and that they conform to your standards. Thanks, Ryan P.S. You have a mistake in your SDK documentation in section 2.1, Frame Format. You state that the Size (bytes) of the crc_32 Whole Frame Checksum is 2 bytes when it should be 4 bytes (i.e., 32 bits).
Livox-SDK commented 2019-05-16 10:06:10 +02:00 (Migrated from github.com)
Copy Link
Copy Source

Hi,Ryan:
you are right, there is an error in section 2.1 , the size of CRC_32 should be 4 bytes!
thanks a lot!
and we will test your command!

Hi,Ryan: you are right, there is an error in section 2.1 , the size of CRC_32 should be 4 bytes! thanks a lot! and we will test your command!
Livox-SDK commented 2019-05-16 12:10:35 +02:00 (Migrated from github.com)
Copy Link
Copy Source

We tested your heartbeat command and sent it without recurring your problem according to the process specified in the sdk communication protocol. Suspected that the destination port of the heartbeat command you sent is incorrect, you can do the following verification:

  1. Use the Wireshark tool to capture the communication network package between the Python3 driver and the Mid-40 sensor.
  2. Confirm whether the destination port of the heartbeat command sent by the Python3 driver is the cmd_port in the handshake command.

cmd_capture

We tested your heartbeat command and sent it without recurring your problem according to the process specified in the sdk communication protocol. Suspected that the destination port of the heartbeat command you sent is incorrect, you can do the following verification: 1. Use the Wireshark tool to capture the communication network package between the Python3 driver and the Mid-40 sensor. 2. Confirm whether the destination port of the heartbeat command sent by the Python3 driver is the cmd_port in the handshake command. - [Wireshark Download Address:](https://www.wireshark.org/download.html) - The normal Wireshark package is as follows: ![cmd_capture](https://user-images.githubusercontent.com/45850995/57845827-5eabd580-7805-11e9-9c4b-60aae094c223.PNG)
ryan-brazeal-ufl commented 2019-05-16 15:50:38 +02:00 (Migrated from github.com)
Copy Link
Copy Source

Thank you very much for the quick and helpful reply. My heartbeat commands were being sent to the correct destination port (65000) on the Mid-40. However, my error was that I was not sending the commands using my local/host port as was defined in the connection request command. I mistakenly thought that the connection request command only informed the Mid-40 as to which port to use when it transmits command acknowledgements back to the host. I didn't understand that it was also defining which port to be listening on for my transmitted commands (which of course makes sense now). I don't have a lot of experience with UDP but with your help here, it's starting to become clear! Thanks again.

Thank you very much for the quick and helpful reply. My heartbeat commands were being sent to the correct destination port (65000) on the Mid-40. However, my error was that I was not sending the commands using my local/host port as was defined in the connection request command. I mistakenly thought that the connection request command only informed the Mid-40 as to which port to use when it transmits command acknowledgements back to the host. I didn't understand that it was also defining which port to be listening on for my transmitted commands (which of course makes sense now). I don't have a lot of experience with UDP but with your help here, it's starting to become clear! Thanks again.
Livox-SDK commented 2019-05-21 03:21:17 +02:00 (Migrated from github.com)
Copy Link
Copy Source

Hi,Ryan:
You can also try to develop the python interface based on our SDK core. We will soon provide the installation on Mac in the wiki.
Please inform us anytime if there is a question and you can share your progress with us!

Hi,Ryan: You can also try to develop the python interface based on our SDK core. We will soon provide the installation on Mac in the wiki. Please inform us anytime if there is a question and you can share your progress with us!
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something isn't working
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
eeeck (Erick)
No Assignees
1 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mmr/Livox-SDK#9
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?