Reverse Engineering the PLEM 50 C3 Parkside (Lidl) Laser Rangefinder

This is a reverse engineering attempt at deciphering how this cheap laser rangefinder works. If you can understand how this will work, you can ultimately re-use it in another project.

Besides the PLEM 50 C3 laser rangefinder, you will need these for reversing it:

• Soldering iron
• Multimeter
• Soldering wick
• Soldering wire
• Logic analyzer
• 3V Power supply / 2 x 1.5V batteries
• (Optional) Digital microscope
• Spare time

A laser rangefinder works by the time of flight (TOF) principle:

1. A pulse from the laser is sent to an object
2. The object reflects it back
3. The receiver sees it's the same pulse it sent and acknowlodges it
4. The microcontroller calculates the time it took for the pulsed light to reach the destination and come back, then divides it by 2 (since it's a back-and-forth movement, and it's the double of the actual distance)
5. The microcontroller calculates the distance by multiplying it with the speed of light, c, and the distance is found

The second step in reversing a device is either tearing it down yourself, or searching an online resource where the guts of the device are out. The laser rangefinder has 3 big parts, and these are the screen, the keyboard pcb and the laser rangefinder module.

After tearing it down, it's time to understand what makes it ticks. This process can be a long one, since it involves probing around with a multimeter, following PCB traces and trying to see which interface is up.

From my gathering, the obvious 4 pinned connector that's present on the module is an UART communication, since "RX" and "TX" gives it away. Sadly, it's not trying to communicate if you pair a serial device to it and listen to it's baud rate. The other 4 pins that are on the module and on the keyboard PCBare not communicating also, so it's a dead-end.

An idea is to search for ICs, and I did. There are no ICs on the keyboard PCB, so all the logic comes from the laser module, which is weird, from my perspective. That means that all logic is handled on the module itself for sensing the distance, calculating it then pushing it somehow to the keyboard PCB, then to the screen. The big ICs on the module are these 2:

• NM002 2129 - this is the microcontroller, which I haven't been able to find any schematic with this 32 pin chip
• MS5351M - this is a clock generator:
• https://qrp-labs.com/images/synth/ms5351m.pdf
• https://qrp-labs.com/synth/ms5351m.html
• It seems that it's a clock generator configurable through I2C protocol

Knowing that these 2 ICs won't help us much, I started probing around with my multimeter, and discovered that only 2 pins on the screen are connected to the microcontroller. In the picture, the 2 pins are purple and yellow, and this might give us a clue, that the screen is an I2C device.

With this hint, I soldered pins to the 2 pins. I managed to solder one on the screen ribbon connector, and the other on the keyboard ribbon connector to the module. These are thin, and I'm not accustomed to thin wire soldering.

I hooked the logic analyzer to the 2 pins, and powered the device with 3V from the power supply.

After opening Logic 2 software for logic analyzers, I started the capture, and I started the rangefinder. It seems we're in luck, I2C is the protocol that the screen uses to receive information.

SDA pin of I2C is pin 10 from the ribbon cable connector, and pin 11 is SCL.

In this capture, the rangefinder is started, and then 2 measurements are taken.

While searching for data about the ICs again, I stumbled upon this github repo: https://github.com/pavel-rybnicek/esphome-parkside-plem-50-c3. Pavel Rybnicek already did a reverse on this model, but I discovered it too late. At least, I can gather some data from his findings.

We can see that from the data, the MCU is talking to the screen, sending it data for it to update. We cannot sniff only the measurements, we need to understand what's being sent, and how.

In the third photo there is the second meeasurement being taken. The MCU updates the screen for 110ms, then sends it continously some data, as Pavel Rybnicek says, it is updating the screen only. The MCU sends to 0x3F I2C address, the screen, data to update it's segments, and the screen sends data to 0x60, the MCU.

The data can be converted to decimal, ASCII or hex, but ultimately, we need to black-box test it using some known measurements.

Thanks to the github repo of Pavel Rybnicek, I could decode the data in the I2C packets. In the picture above, there are packets starting with 0xc0. The packets have another byte, trailing the 0xc0 byte. In this case, my measurement is "5.568". The digits are decoded from the trailing bytes, concatenating the two in one. In the github repo there is a decodification function we can reuse to understand what's happening:

void ParksidePlem50C3Component::decode_digit_last_line(char result[], const byte digit1, const byte digit2)
{
  const char * digit_string;
  switch (digit1 << 8 | digit2)
  {
    case 0x0000: digit_string =  ""; break;
    case 0x0400: digit_string =  "-"; break;
    case 0x121E: digit_string =  "0"; break;
    case 0x1A1E: digit_string =  ".0"; break;
    case 0x0006: digit_string =  "1"; break;
    case 0x0806: digit_string =  ".1"; break;
    case 0x061C: digit_string =  "2"; break;
    case 0x0E1C: digit_string =  ".2"; break;
    case 0x041E: digit_string =  "3"; break;
    case 0x0C1E: digit_string =  ".3"; break;
    case 0x1406: digit_string =  "4"; break;
    case 0x1C06: digit_string =  ".4"; break;
    case 0x141A: digit_string =  "5"; break;
    case 0x1C1A: digit_string =  ".5"; break;
    case 0x161A: digit_string =  "6"; break;
    case 0x1E1A: digit_string =  ".6"; break;
    case 0x0016: digit_string =  "7"; break;
    case 0x0816: digit_string =  ".7"; break;
    case 0x161E: digit_string =  "8"; break;
    case 0x1E1E: digit_string =  ".8"; break;
    case 0x141E: digit_string =  "9"; break;
    case 0x1C1E: digit_string =  ".9"; break;
    default: digit_string =  "?";
  }
  strcat (result, digit_string);
}

The first digit "5" is composed of 141a, ".6" is 1e1a, "5" is repeated, then "8" is 1613.

Knowing these details, we have succesfully reversed this laser rangefinder, and the next step is to try and repurpose it.