By: Trenton Wells

What’s in motion at Moetion: Discovery at the speed of light

Recently I sat down to watch a new episode of NOVA on PBS: Angkor: Hidden Jungle Empire. I was quickly drawn in by the engineering marvels of the Khmer civilization. The most breathtaking part was how LiDAR data revealed the true scale of the ancient city hidden beneath the jungle. This set the spark… or maybe the pulse… of curiosity that keeps me up at night.

Seeing its applications, from ancient archaeology to cars, drones, and robot vacuums, I had to crack it open myself. So how does one go from idle curiosity to a deep understanding for invention and implementation? You use every tool at your disposal. Both LiDAR and AI are the new tools in my toolbox, and this is how I added them to unlock a new path through the jungle.

The pulse: From Angkor to Grand Rapids Michigan

Low-cost LiDAR modules can be found in many devices today, so I went and picked up a small, 2D LiDAR module and dove in. The module came from an existing product and lacked a data sheet or even a part number, but I never let that stop my curiosity. After some fruitless online searching for similar models, I decided it was time to disassemble it to see what I could learn.

Hardware Deep Dive: Teardown and Discovery

At first glance, the module appeared unremarkable, but as they say, don’t judge a book by its cover. The internals of the module had some surprises under its cost-optimized exterior.

Removing a sticker on the bottom revealed the first clues for the wiring interface. The white wire was power (thicker trace, connected to a reverse protection diode and switcher). The black wire is likely TX as there is a test point labeled TX further along as you follow the trace through the PCB. The green wire connects solidly to the PCB ground plane so we can confidently say that it is GND. The last wire, Red, I initially assumed was RX because it is labeled R in the silkscreen but as we will see later this is not the case.

Flipping the module over and removing a few screws, I found the main LiDAR module. It has an IR laser diode on the left and an IR photodiode on the right and is what is used to measure the time-of-flight (ToF) of light for the laser pulse, and the reflection time is what gives us the distance to an object. This is a simplification of what is going on but for this project that is all we need to know right now.

Since the top portion of the PCB spins continuously, I expected to find a slip ring connector. Instead, I discovered a wireless power induction coil and an internal IR LED/photodiode pair used to transmit data from the rotating PCB to the stationary base. I also found a photo gate in the corner that served as an encoder, meshing with gates molded into the device’s body. This unique engineering decision removes the issues of friction and wear that you would find in a traditional slip ring. It also shows how as technology becomes more accessible, you find new and interesting ways in which to use it.

Integration: Interfacing with Arduino

After reassembling the module, I worked on getting it connected and functional. To interface with the module, I chose an Arduino Nano 33 BLE Rev 2 which reads the serial data from the LiDAR module and sends it to my computer. Inside this Arduino board we have a uBlox NINA module that is running an nRF52840 at 64 MHz. Soldering up the wire connections and jumpering the 5V USB power to the power of the LiDAR module we plug it in and turn it on.

Once powered, the module immediately begins to spin. Probing the lines revealed that the “TX” line was indeed a 3.3V UART signal, while the “R” line provided an encoder pulse once per revolution rather than an RX line as initially expected. First problem solved and no magic black smoke was released.

The Problem: Decoding the Data Stream

I whipped up a sketch to read the UART data and output it to the COM port. After testing to determine the correct baud rate, I began seeing a distinct pattern: “AA 55”.

Knowing a bit about AI and what the right tool for the job might be, I tossed the UART data into a file and uploaded it to Google Gemini. A few questions later and Gemini comes with the following response:

Immediate shoutout to kaiaai on GitHub ( https://github.com/kaiaai/LDS ), and a lot of help from AI. Identifying the data format as likely matching the CAMSENSE X1 was a huge breakthrough and critical in getting a functional device. The ability of AI to assess the context of the question and the pattern recognition we get to the core of what I believe AI is ready for in a professional context.

Quickly putting together a python script to read the serial data and decode based on the CAMSENSE X1 module format we plug everything in and hit run!

That is something! But it is not what I was expecting. So, I took a step back and came back to it another evening to see if we could make sense of the data.

The Breakthrough: Optimizing Speed with Direct Memory Access (DMA)

Even with the correct format, the initial Python script produced erratic results. The serial data wasn’t uniform in length, and it became clear that I was missing most of the data in each frame. The processing overhead of the standard Arduino libraries was causing the UART hardware buffer to overflow which was causing about half of the data in each header to be lost.

Again, throwing the problem over to Google Gemini, I was able to glean some useful information, but it struggled with the deeper context and the specifics of the problem. Through multiple iterations, it provided improvements to the code and implementation improvements but lost context and broke functionality in other critical portions of the code.

Setting AI aside for some time, I did some reading on the nRF52840 and the Arduino MBED OS. I set up a Direct Memory Access (DMA) circular buffer for the UART input to have better real time management of incoming and outgoing data bypassing the standard Arduino serial library calls. Next, I manually increased the serial buffer to 8x larger than the default setting to make sure we are not losing any more information to buffer overflow.

Once this was done, I was able to bring AI back into the creation process, and it was once again useful as a tool for efficiency and integration. Through another 5-6 iterations, Gemini optimized the header-search logic (0xAA 0x55) to access the circular buffer directly, eliminating the need to copy data or convert it to ASCII strings which again improved the data pipeline from the LiDAR module through the Arduino module and into my computer.

With these changes in place, we could see that the full frame consists of 14 headers, each containing 40 bytes. After updating the Python script to handle the complete data, finally we have success! The starburst dissolved and the point cloud stabilized, leaving a sharp 2D outline of my home office.

Conclusion:

Each additional tool in the kit allows us to tackle more problems with larger diversity across more industries. Quickly moving from ideation to implementation is easier than ever. Whether it’s a 30-year-old module lacking documentation or a new one with unknown origins, AI’s pattern matching capabilities fills in the gaps. AI and LiDAR are now essential tools in my toolbox, each serving a unique purpose. Yet the horizon is constantly moving. Tomorrow may bring new discoveries deep in the jungle via next-generation LiDAR or AI-driven analysis that decode today’s most complex challenges.

Moetion Technologies