The direct answer
Is v1.3.1 a fixed public release? Yes. The official GitHub release is non-draft and non-prerelease. Its lightweight tag resolves directly to commit f5d9375f84ef; GitHub reports that commit unsigned.
Does the fixed source contain Mid-360S support? Yes. It declares device type 35, a Mid360s command handler, dedicated ports, six sample configurations and public ESC/PPS calls. That is source-level evidence—not an exact device, firmware or host validation result.
Does the release publish a passed test or sensor benchmark? No. The complete tree contains no explicit test, benchmark or structured result path; it has no public CI workflow, check run or status context at the tagged commit. RCI built no binary and connected no LiDAR.
Livox SDK2 v1.3.1 is a fixed non-prerelease GitHub release whose lightweight tag resolves to an unsigned commit and complete 221-file public tree. Both generated archives matched every fixed Git blob, the API header declares 1.3.1, and the source adds explicit Mid-360S handling, six sample configurations, ESC mode and PPS synchronization calls. The same release publishes no uploaded binary or firmware asset, explicit test suite, CI workflow, public GitHub check, exact firmware/hardware matrix, execution log or device-result bundle. These surfaces support a source-level release-evidence claim, not a LiDAR performance, timing, stability, compatibility or robot-integration validation claim.
Two generated archives match every fixed Git blob
| Surface | Role | RCI check | Boundary |
|---|---|---|---|
| GitHub-generated source tar.gz for v1.3.1 | generated repository snapshot | 341,259 bytes · 221 files · RCI hash | Public GitHub-generated archive; all 221 files matched the fixed tree's declared size and Git blob identity. The SHA-256 identifies bytes retrieved by RCI on the audit date, not a publisher-supplied digest. |
| GitHub-generated source ZIP for v1.3.1 | generated repository snapshot | 524,254 bytes · 221 files · RCI hash | Public GitHub-generated archive; its 221 files, 37 directories and expanded bytes match the tar.gz and fixed tree. Source integrity does not establish a successful build or sensor behavior. |
| Fixed v1.3.1 repository source | versioned source, API, examples and rights surface | Fixed source or linked page inspected; not mirrored | The recursive tree is complete and the public API header declares 1.3.1. Source-level support and sample code are inspectable, but the tree contains no explicit test suite, result bundle, CI workflow or firmware payload. |
| Livox protocol and Mid-360S product pages | living device and communication documentation | Fixed source or linked page inspected; not mirrored | Five links referenced or used by RCI returned HTTP 200 on the audit date. RCI inspected selected pages without mirroring them; living documentation and product specifications remain separate from the fixed SDK release and can change. |
The tar.gz and ZIP each expose 258 normalized entries, 221 files, 37 directories and 1,813,622 expanded file bytes. RCI matched all 221 files in each archive to the fixed tree's byte size and Git blob identity. Their SHA-256 values identify audit-date downloads; neither is a publisher-uploaded artifact or digest match.
What “Support Mid-360S” actually exposes
| Issuer statement | Evidence role | RCI boundary |
|---|---|---|
| Support Mid-360S LiDAR | issuer device-support statement | The fixed tree adds a device type, handler, ports and six sample configurations. It does not publish an exact hardware-revision and firmware matrix or a device-run result. |
| Set Mid-360S ESC mode | issuer API-feature statement | The public header and implementation expose an ESC-mode API and two enum values; no command trace, timing, physical behavior or pass/fail result accompanies the release. |
| Set Mid-360S PPS synchronization mode | issuer API-feature statement | The public header and implementation expose a PPS-mode API and two enum values; no time-error distribution, reference clock, holdover test or multi-device synchronization result is published. |
| Update README communication-protocol links for Mid-360(S) | issuer documentation-change statement | The Chinese and English Mid-360(S) links resolved on the audit date. Living protocol pages are not frozen by the SDK tag. |
| Linux Ubuntu 18.04+ and Windows 10/11, C++11, CMake 3.0+, x86 and ARM prerequisites | issuer build-support statement | The README provides requirements and example commands but no compiler/OS matrix, build logs or release pass table. RCI did not build the source. |
| Livox SDK2 includes three named samples | issuer README inventory statement | The same fixed tree's samples/CMakeLists.txt adds six sample subdirectories. RCI preserves the concurrent documentation difference and does not silently select one count. |
The source defines device-side ports 56100–56500, host ports 56101–56501 and debug point-cloud port 60301 for Mid360s configurations. These constants are integration inputs. They do not demonstrate packet delivery, latency, loss, clock accuracy or long-run operation.
v1.3.1 exposes source support and an upgrade sample but no firmware payload, exact firmware floor/digest, serial or hardware-revision matrix. A device-support statement therefore cannot be rewritten as every-unit compatibility or a successful physical test.
One release, two differently scoped version strings
The public API header defines 1.3.1, agreeing with the release tag. sdk_core/CMakeLists.txt separately defines 0.0.2 variables, but the fixed file does not apply those variables as target VERSION or SOVERSION properties and does not explain their relationship.
RCI therefore does not call this a release-version contradiction or assign ABI meaning to 0.0.2. It publishes the concurrent values and asks the maintainer to clarify their intended scope.
Six sample targets are not six passed tests
The fixed samples CMake file adds six directories: quick start, multi-LiDAR upgrade, logger, debug point cloud, command observer and RMC time sync. Together they contain 40 files and 24 JSON configurations; all six include mid360s_config.json.
The same commit's README says Livox SDK2 “includes three samples” and documents quick start, logger and multi-LiDAR upgrade. That may be a tutorial subset or documentation lag. RCI preserves both fixed statements rather than changing the count on Livox's behalf.
The fixed CMake source builds six sample targets with 40 sample-tree files and 24 JSON configurations, including six Mid360s configs. README names only three samples. The complete tree has zero explicit test/benchmark/result paths and zero public CI workflows, checks or status contexts; examples remain separate from release validation.
Twenty disclosure checks
| Field | Status | Public evidence | Why it matters |
|---|---|---|---|
| release identity and date | disclosed | GitHub identifies v1.3.1, release state and timestamps. | A reader can cite a specific public release rather than a moving branch. |
| tag object and signature | disclosed-lightweight-unsigned | The tag ref resolves directly to an unsigned commit; no annotated tag object exists. | The commit is fixed, while provenance does not include a verified tag or commit signature. |
| recursive tree identity | disclosed-and-not-truncated | GitHub returns tree 7daae4c235a1 with 258 entries and truncated=false. | The audited public source boundary can be enumerated completely. |
| publisher archive digests | not-published | The release has zero uploaded assets and GitHub supplies no publisher digest for generated source downloads. | RCI hashes identify audit-date downloads rather than matching an issuer checksum. |
| archive to fixed tree bytes | disclosed-and-matched | RCI matched 221/221 extracted files in each archive to fixed-tree byte sizes and recomputed Git blob identities. | The two downloaded snapshots are byte-consistent with the selected commit. |
| public api version | disclosed | include/livox_lidar_def.h defines 1, 3 and 1 version components. | The API-reported version agrees with the release tag. |
| cmake version relationship | unresolved-concurrent-value | sdk_core/CMakeLists.txt defines 0.0.2 variables that are not applied to a target; no fixed explanation relates them to API version 1.3.1. | Packagers should not infer binary ABI or SONAME version semantics without maintainer clarification. |
| publisher binaries or install packages | not-published | The release has no uploaded asset; the public tree contains no .so, .dll, .a, .lib, .exe, .deb or .rpm payload. | Users must build source and cannot match a publisher binary digest from this release. |
| mid360s source support | disclosed | Device type, handler, configuration parser, ports, API calls and six sample configurations are fixed in source. | The implementation surface is inspectable, but execution remains unverified. |
| minimum device firmware | not-published | Neither the release body nor fixed README supplies exact Mid-360S firmware bytes, version floor or digest for ESC/PPS support. | An exact software–firmware pair cannot be reconstructed from the release alone. |
| hardware revision matrix | not-published | No serial range, board revision or exact product revision matrix accompanies v1.3.1. | Support cannot be generalized to every physical Mid-360S unit. |
| host build matrix | partially-disclosed | README gives broad OS, architecture and tool prerequisites plus one Ubuntu and one Visual Studio example, but no matrix or build logs. | Declared prerequisites guide setup without proving every supported combination. |
| sample inventory | concurrent-fixed-file-difference | README names three samples while samples/CMakeLists.txt builds six at the same commit. | Documentation coverage and the full example surface should be clarified before making completeness claims. |
| public test suite | not-published | The complete public tree contains zero explicit test or benchmark paths. | There is no fixed public suite from which to reproduce release validation. |
| release test commands and results | not-published | No release test manifest, command list, pass/fail table, coverage output, JUnit record or execution log is included. | Source availability cannot be converted into a passed-release claim. |
| public ci at tag commit | not-published | The tree has no workflow path and GitHub exposes zero checks and zero status contexts at the tagged commit. | Public GitHub metadata supplies no independent build or test outcome. |
| sensor performance protocol and results | not-published-in-release | The SDK release contains no fixed range, precision, point-rate, latency, packet-loss, thermal or power test protocol and result bundle. | Product-page specifications remain issuer claims outside this software-release audit. |
| pps and esc physical results | not-published | API declarations and implementation paths exist, but no clock identity, trace, timing error, mode-transition measurement or physical device log accompanies them. | PPS and ESC functionality cannot be quantified or independently reproduced from the release package. |
| file level rights inventory | partially-disclosed | Root and bundled dependency license texts are present, but the root illustrative scope tree is stale relative to current samples and does not map every file individually. | MIT coverage is strong for named portions, while exact file scope, marks and living external documents remain item-specific. |
| independent lidar or robot reproduction | not-performed | RCI audited metadata, archives, source structure, links and rights only; it built no binary and accessed no LiDAR or robot hardware. | All device, timing, performance, stability and robot-integration conclusions remain outside independent RCI verification. |
15 of 20 checks are narrower than fully disclosed. The missing core is a frozen validation manifest joining exact SDK commit, firmware digest, hardware revision, host/toolchain, commands and structured device results.
Source licensing is visible; file scope still deserves care
The fixed license file publishes Livox MIT terms and notices for embedded RapidJSON, spdlog and FastCRC code. Separate bundled license files are also present.
The fixed repository includes Livox MIT terms and embedded RapidJSON, spdlog and FastCRC notices. The root illustrative file tree is stale relative to the six current sample targets, and external protocol/product pages and trademarks remain item-specific; RCI republishes only original facts, hashes and analysis.
The root license's illustrative tree says sample/ and shows one quick-start example, while the actual fixed source uses samples/ and six target directories. RCI treats that as a scope-clarification question, not permission to relicense upstream code, living documents or marks.
What RCI independently checked
- Resolved the official release, lightweight tag, target commit, complete recursive tree and fixed version files.
- Downloaded both GitHub-generated archives, computed audit-date SHA-256 values and matched every extracted file's size and recomputed Git blob identity.
- Mechanically counted changelog headings and bullets, sample targets, sample files and Mid360s configurations.
- Checked explicit test, benchmark, result, CI, binary and firmware path patterns plus public GitHub check-run and status APIs.
- Inspected fixed API, CMake, README and license surfaces without inferring undocumented version, ABI, firmware or hardware relationships.
- Checked five official protocol/product links for availability while keeping their living contents separate from the fixed SDK tag.
Limits that stay attached
- RCI downloaded only the two GitHub-generated source archives; GitHub publishes no digest for either, so their SHA-256 values are audit-date identifiers rather than publisher matches.
- RCI recomputed and matched every extracted Git blob, but source-control integrity does not prove compilation, runtime correctness, device support or safety.
- RCI did not compile Livox SDK2 on Ubuntu or Windows, install dependencies, execute any of the six samples or inspect private/external CI.
- The fixed public tree contains no explicit test suite, benchmark path or structured result bundle; RCI does not infer that Livox performed no private validation.
- RCI did not download any LiDAR firmware; v1.3.1 does not publish an exact Mid-360S firmware version/digest or hardware revision matrix for ESC/PPS support.
- RCI did not connect a Mid-360S, Mid-360, HAP, clock source, Ethernet host, robot computer or robot platform.
- The README's three-sample statement and the fixed CMake six-target inventory are preserved as a concurrent documentation difference, not silently resolved.
- The API header's 1.3.1 and unused sdk_core CMake 0.0.2 variables have different apparent roles; the fixed project does not explain that relationship.
- Living Livox protocol and product pages returned HTTP 200 on the audit date but can change independently of the fixed SDK tag.
- Root and third-party license texts are public; RCI does not relicense upstream code, external documentation, product specifications or Livox marks.
Download the release audit
Download the immutable JSON release and record-level CSV. Stable aliases are current JSON and current CSV.
Suggested citation: Robot Component Index. “Livox SDK2 v1.3.1 Evidence: 221 Files, 6 Sample Targets, Zero Test Paths.” RCI 035, version 0.1.0, 2026-08-10. https://robotcomponentindex.com/research/livox-sdk2-1-3-1-release-evidence-audit/