Close
0%
0%

Peek inside UNI-T UT390B+

Much cleverer people hacked the orginal UT390B laser range finder but no-one seems to have published what we know about the UT390+.

Similar projects worth following
This project is a start of a repository that will hopefully encourage others to share what we can reverse engineer from the UT390B+.

Here's the datasheet for the STM32F 030C6T8

Software.ino

Test Arduino sketch for NSCE Laser NOT suitable for UNI-T Laser

ino - 2.59 kB - 01/14/2017 at 10:28

Download

Protocol_Overview.pdf

RS232 communication protocol for NSCE Laser NOT suitable for UNI-T Laser

Adobe Portable Document Format - 348.70 kB - 01/14/2017 at 10:28

Preview
Download

Screenshot (32).png

For Iliasam: the IC might be https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351-B.pdf or a copy of it?

Portable Network Graphics (PNG) - 2.09 MB - 11/25/2016 at 11:10

Preview
Download

  • Still testing

    StefanM03/15/2017 at 19:10 0 comments

    My sample device, used for snow depth measurement, is working fine since december.

    I'm still would like to find out what's the actual difference between devices with longer and shorter ranging distances. Maybe someone has a clue.

    Moreover the question is how many people are interested in such rangemeters, because I would have to order at least 100 from the supplier. And I don't want to store rangemeters for $3000 at home.

  • More information on NSCE NS-XX Type

    StefanM01/14/2017 at 10:37 5 comments

    Hi,

    here comes more information about my laser and I uploaded some arduino code.

    The code works for my device, the pin changes are to switch the transistor to supply the device and the other one is switching one the device simulating a push on the soft key.

    If anyone is interested in writing a nice arduino library I would be glad, because I'm the user hacking around quick and dirty until it works.

    My idea would be, since the conversion of the laser lasts upto a second, to write the command and get the result with a UART interrupt, which rises a flag, that can be polled in the main loop.

    Moreover I added a overview of the commands. I got this from the manufacturer and I made it a bit fancier since it was not very clear.

    Concerning costs, I'm still dealing with the manufacturer to get a price for spare PCBs without housing and display. After that I have to check out with customs and taxes...

    I think the price for one part will be around 30 Euros + 3,70 shipping worldwide. I checkd out the shipping costs and it does not matter if the destination is in europe or abrought.

  • Another device

    StefanM01/12/2017 at 19:09 1 comment

    Hi everyone,

    meanwhile I got some samples from another device.

    It's brand is "NSCE Laser" and Type is "NS-XX"

    XX stands for Number 20 to 60 which tells the maximum ranging distance.

    With the device I got the description of the communication protocol for a included serial interface. The device works at 5V and communications works with an arduino.

    On the last picture you can see RX and TX on the left corner.

    It uses also the STM 32F MCU.

    I'm thinking of ordering a bigger number of the device if someone else is interestet in I could organize a collective order.

    The only thing is that I'm living in Germany, so I don't know if it makes sense that someone outside Europe takes part, although I would foreward the devices to other countrys.

  • Going deeper into schematic

    iliasam11/30/2016 at 08:55 1 comment

    Hi everyone.

    Simon found than small IC placed near laser diode and APD photodiode is Si5351. It is dual PLL clock generator, controlled by I2C bus. It can generate two different frequencies from 8 kHz to 160 MHz.

    I think that si5351 generates two high (>100 Mhz) but close frequencies. One of them is used to modulate laser, another - to modulate APD photodiode power.

    These two frequencies are mixed at APD and the resulting low frequency is amplified by sgm8592 IC. The amplified signal (there were photos of this signal at oscilloscope) is analysed by MCU.

    So, I think that it is possible to capture I2C signals and calculate used frequencies. After that it is possible to write new firmware for STM32, which would analyse resulting signal. That way can give an advantage - it is possible to create less accurate (~10 mm) but faster (>10 Hz) rangefinder.


    Now I'm waiting for delivery of Chinese rangefinder module, it's construction is very similar to UT390+ (it has si5351 installed).

    I want to do it's full reverse engineering, and write my own code for rangefinder's STM32.

    I hope that code will be suitable for UT390+ too.

  • Tried and gave up

    StefanM11/20/2016 at 18:04 6 comments

    I tried to get some data out of a KKMOON branded laser range meter.

    It's inside is from SNDWAY and looks basicly like the UNI-T UT390B+. Moreover there were some debug pads inside wired to RX and TX but they were dead.

    First I did some measurements on different pins, like Simon did, but finally I gave up since it was too time consuming.

    Now I have orded some other device beeing supposed to have an active RS232 port. So I will keep you informed if I have any news.

    Moreover I attached the information I could find out about the pinning - it's written in German. Unfortunately I couldn't upload the pdf file.

  • Fried

    Simon Merrett07/27/2016 at 23:59 0 comments

    Think I've killed the STM32F. LCD isn't showing anything, there's a funny audible scratching sound when I press the laser firing button and even though the laser fires, I can't get anything useful out of the previously active pins. This is all after I tried soldering a jumper wire to all the exposed pads and there's a good chance some of them hit the 9V rail on my breadboard power supply.

    Oh well. Perhaps time to try a different laser distance measurer. There's a Bosch PLR15 in the post...

  • More pin mapping

    Simon Merrett07/26/2016 at 20:43 0 comments

    Using this pad reference picture:

    E = PA13, D=PA14: SWDIO & SWCLK, as mentioned before. C = NRST. B = GND. A = VDD.

    I = VBAT. J = GND. K = VBAT. L = GND. H = ADC1_IN (Probably) as described in a previous log.

    The I2C lines are where I might try next.

  • Quick dump...

    Simon Merrett07/24/2016 at 21:34 0 comments

    Just from probing while I was offline this weekend:

    PA5 (Pin 15) is high frequency pulses, sine and carrier.

    Also on that pin is SPI CLK and ADC_IN 5.

    PA8 is giving out a 20 uSec period pulse (500 kHz) when the button is pressed. It's the only one I can see which has MCO as a function but it also does USART1 CLK. I presume this is the MCO output though:

    PB7 is giving a short 20 uSec pulse, 150 uSec pause then 50 uSec pulse. It's SDA for I2C_1:

    Meanwhile, PB6 is I2C_1 SCL and is producing a 40 uSec period pull down pulse @ 50% duty:

    The I2C messes up the LCD when wires got shorted by my probe so I'm confident this is what it's being used for.

    The FT24C32A chip is two wire serial EEPROM. Maybe i2c talking there too?

    I have a feeling that the chips near the laser which have 5351 on are copies of the MAXIM 3.3V version of the 535 DAC. More checks required.

    I've also emailed SNDWAY, who make the laser module, to see if they'll tell us the inputs/outputs from the module.


    I'm not holding my breath as they also make their own laser range finder consumer products and it would be giving their secret sauce away somewhat.

    Please chip in with ideas as I'm about to hit the limits of what I can do with this to get a useful distance measurement out of it!

  • SWD

    Simon Merrett07/22/2016 at 07:42 0 comments

    It turns out that the two mystery pads at one end of the five which are exposed to through the battery bay are Serial Wire Debug lines, or SWD. I have only just heard of this term when I looked into the Mechaduino and how you need the SDW interface for loading the Arduino bootloader on the Atmel SAMD21 that they're using (same chip as in Arduino/Genuino Zero - good call Tropical Labs). I traced the pads ringed in the picture below with the multimeter and the pink one is connected to PA13 (SWDIO) and the red one is connected to PA14 (SWCLK).

    I have yet to find out if we can talk to the STM32F via SWD but thought I'd let you know the latest finding. More to follow.

    An idea: perhaps there are other chips on this board which have interfaces that would let us talk to the STM32F, like SPI or I2C (although slaves are unlikely to get very far). Datasheets ahoy!

  • Glimmers

    Simon Merrett07/21/2016 at 22:59 3 comments

    I have found a few points of light, mostly around the lone via which gives out a sine wave when the laser is firing. Initially, I assumed this was some ramp-esque control signal to the laser but the photos below suggest that it's actually the output from the laser receiver (and it's conditioning circuitry) into the microcontroller. The first photo is of the pad/via in the bottom right hand corner of the photo.

    When I checked, this is connected to pin 11, PA1 on the LFQP 48 package and the additional function of that pin is... ADC_IN1.

    This makes me think that the laser receiver circuitry is producing a signal that the microcontroller can sample within it's (relative to the speed of light) limited processing clock speeds. The next photo is of the sine wave when the laser is pointing at a wall 1.8m away (by pressing the READ button once).

    Then if I put my hand about 20cm in front of the beam/lens we get this higher voltage amplitude signal which is significantly clipped:

    I don't know how the microcontroller is extracting the data it needs to perform a ranging calculation from this signal but I hope someone else out there could suggest a possible method and way to test if it works for a different microcontroller.

    Finally, to be more confident that this is a received signal rather than a microcontroller-generated command signal, I covered up the lens:

    This captured image doesn't articulate the noise/random walk of the trace and I think it's a good enough indication that we are dealing with a signal from the laser receiver rather than the microcontroller.

    I'd really like help here for ideas about what to do with this signal but the two mystery pads on the array are dragging me back to the search for a serial line on this microcontroller for debugging/firmware.

View all 12 project logs

Enjoy this project?

Share

Discussions

Michal wrote 01/04/2020 at 13:52 point

Hi,

I have just bought 2 unit390b+ units, they were on sale on aliexpress. I was able to dump firmware If someone is interested. The hardware is pretty straight forward.

2 lasers powered by current source with 2 power levels. RF signal from si5351 clock generator feeds the laser diode. There is one select pin which select which laser is ON. Either the "measured" path one or the "known" path one. Known path is internal laser diode shining directly at the APD diode.

APD diode needs 50-100V for operation. This is generated by simple boost circuit on the bottom of the board near the buzzer. Higher the voltage higher the sensitivity. Second generated RF signal is fed directly to the APD.

When the laser light hits the APD it acts as RF mixer. Both RF signals generated by si5351 are 5kHz apart. So the resulting mixed signal is 5kHz.

The range calculation is similar to iliasam's calculation, but the "reference" and measured signals are switched instead. You are either sampling reference signal or measured signal - selected by which laser diode is turned on.

The UART commands look like they are sent over bluetooth, probably in some different version. I guess there is some android APP where you can find the protocol.

The maximal distance is determined by single byte in the eeprom.

Pinout of the MCU and fwdump can be found in my repo:

https://github.com/robots/laser-unit390bplus

  Are you sure? yes | no

phyzikes wrote 05/04/2019 at 11:40 point

Hi, people! Someone did it. What do you think?!

 https://youtu.be/nPPaJmDTnjw

  Are you sure? yes | no

Eddi Maevski wrote 02/04/2017 at 21:26 point

Simon Hi,

Would you mind sharing your findings regarding this NCSE NS-60 the one with serial interface ?

Where from one can order such board or device ?

Thanks, Eddi

  Are you sure? yes | no

Simon Merrett wrote 02/05/2017 at 09:03 point

Hi Eddi, StefanM is the main person making progress at the moment and he's the one with all the info about the NCSEs. Have you read the most recent project log with further info on these devices and looked at the arduino code in the project files? If so, what specific information are you looking for? StefanM is thinking about how to set up a supply source for these boards so let him know if you are keen. 

  Are you sure? yes | no

Eddi Maevski wrote 02/05/2017 at 14:19 point

yes, thanks I've saw the file and the protocol doc.

I'll be very interested in getting one device to play with.

  Are you sure? yes | no

StefanM wrote 03/15/2017 at 19:17 point

Hallo Eddi,

I still have one 20m sample device from the manufacturer here. It is already disassambled.

If you need it, I could send it to you for purchase price. Just send me a PM.

I'm sorry for the late reply, but I do not get any notifications when someone writes a comment and I'm very busy at the moment.

Stefan

  Are you sure? yes | no

Jim Nissen wrote 02/02/2017 at 04:55 point

Anyone try to use the ARM SWD interface to see if the flash data in the micro is available? I have a USB SWD device on order but Im not convinced the protection bits would not be set to limit the read. Highly unlikely the flash is unprotected. 

  Are you sure? yes | no

Simon Merrett wrote 02/05/2017 at 08:59 point

Jim, I broke mine before getting that far. Sorry. 

  Are you sure? yes | no

Jim Nissen wrote 02/07/2017 at 03:24 point

Well my SWD interface is in the mail still but I have a working laser range finder! Will be interesting if it will respond...

  Are you sure? yes | no

StefanM wrote 11/06/2016 at 14:24 point

Hi Simon,

at the moment I'm trying to obtain the distance data from a SNDWAY device.

My PCB looks a bit different but in principle it seems to be identical.

Did you ever get an answer from SNAWAY and did you find another suitable device where to get to the data.

Greetings,

meni

  Are you sure? yes | no

Simon Merrett wrote 11/25/2016 at 11:00 point

Sorry, I never got a reply from SNDWAY or found anything else (but haven't looked hard)

  Are you sure? yes | no

p wrote 10/29/2017 at 09:11 point

So, you started with the U390B+, which seems to use the same board as a SNDWAY SW-T40. Did I understand it right that you were unable to communicate with this device and instead started using some other device with a known serial interface?

Do you have any suggestions for the next steps in getting the U390B+ (or for me, the SW-T40)
In the post you mention the I2C interface, did you have time to test this?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates