Need Communication Specs for Nikon DTM A10LG Total Station

[BobKrohn]

Need Communication Specs for Nikon DTM A10LG Total Station.
Nikon is now Trimble and their tech dept knows nothing, ZERO about
this older instrument.

I am trying to record measured data to my laptop PC (MS Windows).
I want to possibly write my own VB6 program to act as data collector.
Buying software and dedicated data collector is not possible for me.
The Trimble Connex software looks like it is for downloading bulk data
that is stored onboard the Total Station.
I don't think the A10 has storage ability. (?) Doesn't look like (?)
the Trimble Connex pgm can capture shots as they are made.

So far I have used HyperTerminal experimentally (the comm pgm included
with Windows)
Have been able to receive the just measured, individual data at 4800
baud. Sent out by the REC button on Total Station.

TR PN: 1 SD:000123456 HA:001031070 VA:009412060 HT:000005000 V

Each data record of PN SD HA VA HT is bracketed by:

TR = 01 54 52 02

Hex Dec English
01 = 01 SOH Ctl A
54 = 84 "T"
52 = 82 "R"
02 = 02 STX Ctl B

V = 03 56 04 0D 0A

Hex Dec English
03 = 03 ETX Ctl C
56 = 86 "V"
04 = 04 EOT Ctl D
0D = 13 CR Ctl M
0A = 10 LF Ctl J

The Total Station sends the same record three times then says it
failed and fails to increment the point number.
It's apparently waiting for a confirmation string from PC after each
attempt.

* What is the confirmation string it's waiting for?

* Can the Total Station send other data items? How to set this?
(manual shows a lot more data items that can be sent. Horizontal
Distance for example)

* Manual mentions
Remote Control Commands (performing all Total Station keyboard
functions from PC?)
Data Setting Commands (example. set plate Zero?)
Data Output Request Command (firing gun from PC?)

I wrote a data collector pgm for the HP100/200 in mid-90's for Topcon
ET-1 and Wild but don't have the HP anymore.
It was DOS so "could" run on PC but not sure about handling odd serial
port numbers that exist under windows (ex. Com29)

Thanks for any helpful info, Bob

[gord.b...@gmail.com]

I know this is a tad late, but....

I've reverse engineered out the comminication protocol for this, and I'm writing up a document describing it in painful detail, and writing a library for Delphi (I don't do C, but I should) that can interpret the packets.

I'll give a very quick primer,

It is broken down into this:
When coming from the gun

0x01 + 'T' + IDChar

The IDChar is a response by the unit to whatever was sent to the gun by the "device" in the last packet. It defaults to 0x52 ('R'), but can be anything above 0x21 (I think).

When sending TO the gun you switch the bytes.
0x01 + IDChar + 'T'


Followed by either

A) A message delineated by 0x02 .... 0x03
B) An ACK 0x06
C) A NACK 0x15

Then a checksum byte for everything past the 0x01 + ID1 +ID2 chars up to, but not including the checksum, calculated as such.

CHKSUM = (x1 + x2 + x3.. xN) - 0xC9

This will work if CHKSUM is treated as an 8 bit value.


Then a 0x04 (EOT) + 0x0D (CR) + 0x0A (LF)

For those that have been following for the last 30 years, I bet you're thinking "XModem Ripoff" and you'd be right....

So, if your gun fired out that message, you could respond with an ACK

0x01 + 0x52 + 0x54 + 0x06 + 0x3D +0x04 + 0x0D + 0x0A

Breaking it down

0x01 + 0x52 + 0x54 <- Header
0x06 <- Message
0x3D <- Checksum calculated as (0x06) - 0xC9 = 0x3d
0x04 <- EOT
0x0D + 0x0A <- CR+LF

There are a variety of messages (that are sent as part of the 0x02 + "text" + 0x03) that I'm still hashing out.

There you go!
Gord

[gord.b...@gmail.com]

Ok, an update. Apparently I've somehow got the checksum wrong, and it's driving me nuts.

I'll be posting some examples of packets and hopefully we can get some minds working on this.

Cheers

[gord.b...@gmail.com]

OK! The checksum is derived from adding the bytes after the (0x01) up to, but not including the checksum then ANDing with $3F and adding $20

EG:

0x01,0x43,0x54,0x02,0x24,0x44,0x4E,0x58,0x03,0x4A,0x04,0x0D,0x0A

Add 0x43 -> 0x03 = 0xAA

0xAA AND 0x3F = 0x2A

0x2A + 0x20 = 0x4A

Thus, this packet is correct.

More to come...