Laser distance meter update: serial commands, timing measurements

In my first post about the laser distance meter I asked for help finding usable commands to control the unit, and within days reader speleomaniac had found a command format and several commands. Let's have a look! But first I'll explain some timing measurements that people have been emailing about.

Timing measurements

The unit is able to take just over 1 measurement per second using the single-shot *00004# command on a flat surface (see below). However there is also a rapid-fire mode which can be activated by holding the ON button for about 1000mS. So far I haven't found a serial command to begin rapid-fire mode (edit: the command is *00084553#, scroll down for details). In rapid-fire mode, the unit takes 100 measurements in quick bursts, and it's capable of scanning just over 3 measurements per second off a smooth, reflective surface. When the laser beam is scanned across soft or bumpy surfaces the measurements take longer, and when the laser beam is out of range or shaky, the unit will output an error and continue until it has attempted all 100 measurements. The output for each failed measurement is:

OUT_RAN dist = 18
OUT_RAN dist = 31
OUT_RAN dist = 30
[...]

I've uploaded a text file containing raw sensor measurements, with timestamps added at the beginning of each line to show the speed. It can be downloaded here: ut390b_laser_timing.txt.

Commands

Command *00001#

Outputs the message

pMsgWrite TRUE 
pInitDataWrite TRUE

Command *00002#

Takes 3 readings, screen shows "Er". Outputs the 3 measurements in array notation (distance is 103.7mm):

u32Dist[0]=1037  u32Dist[1] =1037 u32Dist[2] =1037
u32temp =0
*000720150000000042#

See below for an explanation of the last line ending in 42#.

Command *00004#

Takes 1 measurement, screen shows the measurement. Outputs the measurement like this: (distance is 112.7mm)

Dist: 1127,curtemp =22 

V2.0 
nDist: 1127,tempDv=0

*0006400000112784#

See below for an explanation of the last line ending in 84#.

Command *00005#

Memory dump. I'm not sure why, but some measurements are recorded to the unit's nonvolatile memory. Not all measurements are stored -- measurements that will be stored will display the following additional message:

Dist: 3122,curtemp =21 

V2.0 
nDist: 3122,tempDv=0

WriteTestData TRUE

The memory dump command outputs these recorded measurements in the following format:

*0024500001000001850000018700000000000000000000000061#

These fields are, in order:

  1. Command type (memory dump)
  2. Counter (starts at 00001 and counts up)
  3. First measurement
  4. Second measurement
  5. Third measurement
  6. Fourth measurement
  7. Fifth measurement
  8. Checksum

Not all measurements will be recorded on a given line (I'm not sure why). The checksum format is as follows: interpret the data bytes between * and # as 2-digit base-10 integers, and add them together (skipping the checksum). Mod the resulting value by 100. For example:

00+24+50+00+01+00+00+01+85+00+00+00+00
     +00+00+00+00+00+00+00+00+00+00+00+00 = 161
and
161 % 100 = 61

Which gives the resulting checksum of 61. This can be used to verify the serial output of the unit.

Command *100515#

Turns on laser light (seems to freeze the screen, and the buttons no longer work).

Command *100111#

Some kind of memory dump. I've seen between 1-3 lines of output for this command, depending on how many times the laser has been used. Typical output looks like this:

*00261100000000000411000000000000000150119723520395002812#
curent ver:420411

Where the bold values constantly fluctuate up and down (the 97 sometimes becomes 96, etc).

Command *00084553#

Begin rapidfire measurement.

Command #

Repeat previous command.

Thanks to all the readers who have offered info about this laser unit. Good luck!

  • Mijael

    Thank you!

  • Marty Beath

    This stuff is great! I have just ordered a Uni-T so i can start messing with this.

  • c

    Are newer units behaving the same for people? The serial commands TO it work for me so I can have it take a measurement, but it's returning gibberish like: þ…¢­.ÉÉ`7–¬—««žL,¤H¤¤²É]0 C!‹•¹ºMH&SbѕÚp¢»O¦¤¤Pþ*˜˜L‰ÁÁ`0°™™LNÓÿ

  • c

    I may as well answer my own question here... yes, newer units are behaving the same way.

    First mistake was trying to use software serial. Second, even using the hardware serial port, trying to read the data 1 char at a time in a loop doesn't work either (buffer overflowing because I'm not reading the data out fast enough?), and it wasn't until I followed Andrews lead and used Serial.readBytes that I started seeing the expected results.

  • Dardan
  • Dardan

    * 00 08 45 53 # for rapid fire

  • Dardan