Total stations and GNU/Linux, part 2

In this off-line weekend, I went on investigating the output from the Zeiss Elta R55 total station.

First of all, it turns out that the file was not binary. A simple

$ file downloaded_data
downloaded_data: Non-ISO extended-ASCII text

could have revealed this simple truth. My error was due mainly to the fact that most of the content in the file was made by non-printable characters. But my guess about the lines that contained the point coordinates was right. Probably due to a wrong download procedure, there were some problems with that file. All characters with code > 128 (hex 80) had to be translated shifting their code by 128. I used this simple Python script for this task:

>>> read_file = open("downloaded_data", 'r')
>>> des =
>>> for i in des:
...     if ord(i) > 127:
...         print chr(ord(i)-128)
...     else:
...         print chr(ord(i))

Probably this could be done in a better way, but I’m no hexpert at all. And I think this can be completely avoided by downloading from the serial port with the right connection parameters. I think I’m going to use the pySerial library for this task.

Obviously, I’m solving the problem for one model of one manufacturer, but there are many models and many brands. With my short experience, the best solution I can think of is a modular approach, with an abstract connection class that can be subclassed, with the connection parameters for each model.

The second part of the story comes when it’s time to process the downloaded data. First of all, take a look at the clean file contents:

   0001 OR.COOR
   0002                   0S        X        0.000 Y         0.000 Z     0.000
   0003                                            Om     397.0370
   0004 POLAR
   0005 INPUT                       th       1.500 ih        0.000
   0006 INPUT                       th       0.000 ih        0.000 Z     0.000
   0007                   1         X       -0.472 Y         1.576 Z     0.004

Let’s comment it, line by line:

  1. the first line contains the OR.COOR string, but I’m not sure about the other possible values it can take; the line starts with 0001 like all other lines, except the last one
  2. the second line contains the X Y Z coordinates of the origin point (maybe represented by the string 0S?); please note that it uses the same format as for normal points, except that instead of the id number there is this special string
  3. the third line contains information about the orientation angle, but I can’t tell anything more specific about this
  4. the fourth line contains the POLAR string, that is probably referred to the orientation method; I’m not sure about the other values this field can take
  5. the fifth and sixth lines both start with an INPUT string, that should refer to the height of the reflector prism: 1.500 m is in fact the usual height of the reflector
  6. the seventh line contains our only recorded point, with its id (an integer number) and the X Y X coordinates with precision 3
  7. the eighth line indicates that there are no more points to download, and starts with the END string: when downloading, the program should stop here, otherwise the device emits an error (and also a noisy beep), that is represented by the E string on the following lines
  8. attempts to let the download go on even if the device emits the error simply result in more E lines

Part 3 will follow soon.

Pubblicato da

Stefano Costa

Archaeologist, I study the Late Antique and Early Medieval/Byzantine period on the northern side of the Mediterranean, focusing on pottery usage patterns. I'm also involved in open source and open knowledge communities, like OSGeo, the IOSA project and the Open Knowledge Foundation.