I require your help regarding a problem I’m encountering.
Description: I do have four garmin lidar lite v3. 3 of them are running perfecly (in i2c), but one is always busy.
Hardware concerned: lidar lite v3
Software concerned: Matlab
Troubleshooting steps already taken: I permuted all my lidar, . whatever is the position (plug, cabling, i2c master), the fault one is always the same.
before conducting any request, measurement, etc. I always write and read on the register 0x01 to know the current status of teh lidar: it is ending by 0, lidar is free, 1 lidar is busy. The fourth lidar, always the same, is always busy and, therefor, I do not relly on the measurement. i was wondering:
if something changed in the hardware (4th bought two weeks ago, three other one 2 year ago),
if this problem already occur
if there is a way to get a ride of this “busy” status
Here is the answer that we received from Garmin. Let us know if it helps you in anyway.
In the August/September time frame, we released an updated version of the LLv3 sensor that incorporated changes that improved accuracy and repeatability of measurements as well as a few other updates to improve the manufacturability of the sensor. We did make every effort to maintain backward compatibility, but depending on the user application, there may be some subtle differences in operation.
There are 2 registers that contain the device serial number, 0x16 (high byte) and 0x17 (low byte). To read the serial number, it is necessary to conduct a 2-byte read of these registers. The newest versions of the v3 have an updated I2C module. Most of the changes to the module were made to support I2C repeated START transactions. While the updated I2C module is largely backwards compatible but there are a couple differences in functionality. One of the main differences is that first byte of every WRITE transaction is used to update the LIDAR-Lite’s internal address pointer. So, to perform a successful write, a WRITE transaction must contain a minimum of 3 bytes between the START condition and the STOP condition.
Device I2C writes should take on the following format –
START
Byte 1 = Device I2C address (with WR bit)
Byte 2 = Register address to write to (with optional address auto-increment bit)
Byte 3 = Data0
(more data bytes if desired)
STOP
If this process is not followed, device WRITES will fail. Further, if a device READ occurs after a mis-aligned data WRITE and that READ is trying to take advantage of register address setup that occurs in the previously failed WRITE, then that READ will also fail.
Device I2C reads should take on the following format –
I don’t think it is coming from there. The label on the lidar said produced in 01/2020. on top of that, I can access the SN via register 0x16 and 0x17.
It is good to know there was an update of the i2c,
Just to be sure, was tehre any update on the 0x01 regsister with this new version ?
In August of 2018 Garmin began manufacturing LLv3 sensors with an updated FPGA platform. As part of the transition to this updated platform, the I2C peripheral was replaced with a custom interface that allowed access to the non-volatile memory in the FPGA to support factory calibration of a small distance offset that was observed in some sensors. In some applications with higher performance processors it has been found that these sensors will exhibit a behavior where the BUSY flag in the status register (address 0x01 bit 0) remains in a high state. While in this BUSY state, the sensor will not respond to measurement acquisition commands and appears to be locked up or not powering on.
To correct for this condition, the attached document describes in more detail the communications protocols necessary to ensure compatibility across all versions of the LLv3 sensor.
This sounds exactly like that. Really impressed by the support in this forum. many many many thanks !
If you can get this document, this would be lovely.
i will discard this request for all sensors, not asking them their status!
Of these things, the first two should be pretty easy to obtain, so please provide that information as soon as it is available and pursue item 3) as possible.
Thanks for the information. Fortunately, this device is of the most current design!
For the memory dump (item 3), I'm suggesting that when it's in the state that the busy flag is always asserted, please start reading from memory at location 0x00 and continue reading successive memory locations through address 0x7F. It will help us a great deal in our troubleshooting efforts to have all those memory locations' values.
