pps status ok,but not detected

[daniellukeahead]

Thank you for the openpylivox library. It is really cool!

Can I ask you a question here?

When I run the livox-controller-demo, I get the status information ok except for the pps, which shows"Ok, but not detected".

I am using Raspberry 3 + Livox +Ublox GPS. I can see the pps pulse from Linux command( "ppstest /dev/ttyAMA0"/ "gpsmon /dev/ttyAMA0"). So the pps should be working.

Do you have any suggestions about the problem?

[ryan-brazeal-ufl]

Hi Daniel,

With the recent release from Livox of firmware 03.07.0000 for the Mid-40 sensor, a new time sync feature has become available. Unfortunately, I have NOT YET had time to add this new feature to OpenPyLivox. The new feature is the Lidar Command 0x0A - Update UTC synchronize time which now allows the exact UTC microsecond to be sent and applied directly within the Mid-40 sensor (assumingly, I haven't tested it yet).

However, instead of just relying on the new 0x0A lidar command to precisely sync the sensor's clock, it is recommended to use a GPS Receiver produced Pulse Per Second (1PPS) signal along with the 0x0A command. I would recommend connecting the 1PPS signal directly to the Mid-40 sensor via the included Sync cable. I'm assuming your Ublox GPS receiver is using Transistor-transistor Logic (TTL) for it's 1PPS signal, in which case you will need to convert the TTL signal to RS485, a piece of electronics hardware will be needed to performance this operation (something like this). Then the wired connections can be made to the Mid-40 sensor via:

IMPORTANT NOTE: it is your responsibility to ensure that everything is connected correctly and that the proper voltage levels and current supplies are used.

With only the RS485 1PPS signal attached to the Mid-40 sensor, the status information should now report the OK message. However, this type of time sync will precisely reset the Mid-40's clock to zero upon receiving each and every 1PPS signal pulse. Therefore, it would be your responsibility to know the correct UTC second that corresponded to each clock reset (aka., each 1PPS signal pulse).

The best scenario (which again, I have not yet implemented the necessary functions into OpenPyLivox), would be to connect your computer to a GPS Receiver's output data stream, most likely using a TTL or RS232 serial connection, and extract the UTC time. The UTC time only needs to be to the correct second (no microseconds needed). I'm not sure if you are already doing this on your Raspberry Pi or if you are just connecting the PPS signal line from the GPS Receiver? Then, upon receiving the serial data at 1Hz intervals (which will be very closely in sync with the ultra precise 1PPS signal pulse), you could strip the UTC time info and then send it to the Mid-40 sensor using the new 0x0A command. The relative timing between when the Mid-40 sensor receives the 1PPS signal pulse and when it receives the 0x0A command must be within a specified interval. According to the Livox SDK:

Therefore, you have up to 0.5 seconds upon receiving a serial data packet, to strip the UTC data and transmit the 0x0A command to the Mid-40 sensor.

I hope to find time to add the new function(s) to the OpenPyLivox library very soon. However, I will not be including direct support for reading and parsing data from a serial connection (at least for now). Supporting serial connections across multiple platforms would require a fair amount of work and testing, and reading serial data is a very common task and there are several Python libraries that handle the task.

If you haven't already done so, you should investigate serial connections between your Raspberry Pi and your GPS Receiver, being mindful again of correct voltage levels, RPi uses 3.3V logic while most GPS Receivers will use 5V logic or even RS232.

Hope this helps,

-RB

[daniellukeahead]

Hi Ryan,

1. I did use the TTL to RS485 connecting my Rpi and Mid40. the status information report ok.I can see around 200000 points for 2 pulses within 2.5 seconds. I guess the PPS is working well with the script so now I just ignore the "Ok, but not detected" message.

2. I did not upgrade the firmware, it is still 03.05.0000

3. I've already used Rpi receiving the UTC time from Ublox Gps.

4. As to "you could strip the UTC time info and then send it to the Mid-40 sensor using the new 0x0A command"

I am wondering how to do that in the script. Unfortunately, I have no idea how to use the 0x0A command in the script. Anyway, Here is my try though it does not work out.

First, I use Ublox library to retrieve the GPS time in Openpylivox.py. Then, I tried to read the UTC time during the loop, which I am not sure where to do in the script (i.e, I put "UTCTime=gpsInfo.read().iTOW" just before line 202). It sacrifices some time from the data capturing 'duration', so it seems to interrupt the loop and generate some sampling discontinuity.

I guess I am not on the right track, could you give more advice to use 0X0A in the script?

[daniellukeahead]

I work it out by changing the way of reading GPS time. Instead of reading GPS time within the python script(which seems to affect the sampling amount), I choose to read the UNIX time (second) as the starting time. Then when the time of starting sampling is recorded, it increases by 10us. every time the pulse is detected, the Unix time will plus 1. It is slightly different from the pseudocode provided by Livox, but it works well for me now.

[ryan-brazeal-ufl]

I'm glad you were able to piece things together and getting the PPS timing working in your project. I still haven't implemented the new functions for firmware 03.07.0000, but you would first need to update your sensor's firmware in order to use the new 0x0A command. I hope to be working on the next round of development soon.

[fabricedu41]

Hi ! thanks for this driver openpylivox! it's super cool :) with python I can easily use my lidar MD40 and my Rasperry 4, it's practical for testing. I have an idea and I would like to add a RTK GPS sensor to time stamp the points. If I use openpylivox and just the PPS signal at GPS output + reading UTC time via RS + a python script, would it be possible to readjust the poiint with my RPI? I don't understand how the 0A command is used? do I have to send the command + connect the PPS signal for it to work? or just the PPS signal is enough? Why are the times between the points 17us apart with openpylivox? I thought it was 10us? Thank you very much :) fab

[ryan-brazeal-ufl]

Hi Fab,

In order to directly georeference your lidar Mid-40 data you need to know the position (within a desired/mapping coordinate frame) of the origin of the scanner (i.e., defines the translation/shift between the scanner's own coordinate frame and the desired/mapping coordinate frame). RTK can certainly provide you with an accurate position (ignoring the concept of lever-arm offsets). However, RTK alone cannot provide you with the accurate orientation (a.k.a., attitude) of scanner's own coordinate frame with respect to the desired/mapping coordinate frame (i.e., a set of Euler's angles or a quaternion is needed to define how one frame must be rotated in order to align with the other). Inertial Measurement Units (IMUs) are routinely used for this purpose. Hopefully this 30,000ft explanation helps you understand the problem a bit better.

The PPS signal is used by the Mid-40 to precisely reset its internal clock to 0.0000000sec upon receiving the pulse. In theory one would only need to know the full (UTC or GPS) time for a single PPS pulse and then keep track of when the Mid-40s timestamp approaches 1.0000 and then immediately resets. However, in applications the full time for each PPS pulse is usually recorded.

Lastly, the ~17us time differences only occur when using the triple return firmwares (03.03.0005 and 03.03.0007, I think these are the correct F/W no.). All other firmwares (including the double returns) observe 10us between lidar observations.

Hope this helps,

Ryan

[fabricedu41]

Hi Ryan, Thank you for your clarifications I understand :) As an uINS is very expensive, I am looking for a solution with a flight controller like pixhawk or other .... -Actually I use the FW version 03.03.0007 which confirms the 17 us between each points.

-I have another question : ReturnNum always stays at 1 with openpylivox 1.03? I thought it was the number of lidar echoes?

Thanks for your help fab