The pySerial library is really good. Today I installed it and in half an hour I got acquainted with its class methods, even though I have little knowledge about serial ports and the like.

With some trial and error about the connection parameters, I was even able to solve the problem with non-printable characters, tweaking the bytesize of the connection.

Briefly, these are the steps I did in the interactive ipython console:

1. >>> import serial
   >>> ser = serial.Serial('/dev/ttyUSB0', \
   baudrate=9600, bytesize=serial.SEVENBITS, timeout=0, \
   parity=serial.PARITY_NONE, rtscts=1)
   >>> ser.open()

2. at this point, start the transfer from the device
3. check that you have received some data:

   >>> ser.inWaiting()
   648L
   

   A non-zero result means that you have received something.

4. I saved this value to use it with the read() method of the Serial class:

   >>> n = ser.inWaiting()
   >>> result = ser.read(n)
   

5. The result object is a string, seeing its contents is as simple as:

   >>> print(result)
   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
   END
   

   As you can see, there are no errors after the END sentence, because the serial connection is handled gracefully now. The previous attempt with cat /dev/ttyUSB0 was a bit brutal…

For now, that’s all. I go back studying and maybe also writing some Python code for this Total Station. If you have got a total station and want to contribute to this project, let me know by leaving a comment here.

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 = read_file.read()
>>> 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
END
E
E

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.

This post is one of the “dear lazyweb” ones.

Here at the department we have a Zeiss Elta R55 total station. This device has its own software for downloading recorded data, but, as usual, it’s a Windows-only, non-free application.

Is it possible to download data from such a device using a GNU/Linux machine? Nobody knows. I have asked a number of people and no one has ever tried to do this. 🙁 With some good advice from Frankie, today I made my first test.

With substantial help from Elisa, I recorded 1 point. This point has coordinates:

X    -0.472
Y     1.576
Z     0.004

I downloaded from the device using this simple command (it’s ttyUSB0 because my laptop has no serial port)

cat /dev/ttyUSB0 > data

The total number of points is 7. Points 1-6 contain information about the origin point and other parameters. For now, I’m ignoring them. The resulting data file is binary. You can see it here. I am no expert of binary files, so I used GHex to see its contents. Its dumped form looks like this:

...000.....................
...........................
...........................
...000....................0
S.................0.000.Y..
.......0.000.Z.....0.000...
...0003....................
...........................
....39..03.0...............
...000..P..A...............
...........................
...........................
...0005..NPU...............
.........t..........500.i..
.......0.000...............
...0006..NPU...............
.........t........0.000.i..
.......0.000.Z.....0.000...
...000.....................
.................-0.....Y..
.........5.6.Z.....0.00....
.ND........................
...........................
...........................
...............

Some comments about this first test:

• anything after the ND means there are no more data.
• the recorded point seems to be in the part immediately before ND

If anyone has any other suggestions about this test, please tell me.