Seiko QT-2100 Watch Timing Device (‘Time Grapher’)

[RWAP]

We are trying to develop a printer emulator for the Seiko QT-2100P printer which connects to the QT-2100 Watch Timing Machine.

It is a peculiar beast, and having pushed various sections of Seiko, we have at least managed to get English manuals for both the timing device and the printer - although no technical details. Why is it that some companies think that technical information for a machine last sold 30 years ago is commercially sensitive ?? Oh well, at least we are confident now that they do not have the technical information.

Now for the printer emulation side, the printer has 4 different modes, two of which are text output (giving the timing data) and two are graphs - yet, none of the modes capture any text from the timing device!!

It looks as though there are a series of ESC commands followed by up to 7 bytes most of which appear to be zeros. One of the commands at least seems to force the printer to output a standard text header but only in the graph modes.

We are using Excel at the moment to try and rationalise the data captured by the Retro-Printer module, and work out how it correlates to the figures we know are being captured by the device.

It is taking quite a bit of experimentation, but we think that we are getting there.

I am not sure how useful this will be to any other pieces of equipment, but it does go to show the problems that emulating printers can present!!

[RWAP]

Now that is an interesting approach - we have managed to figure out part of the data format for the QT-2100 (certainly for the text mode) - it looks as though each line of data is a series of 8 bytes.

First two bytes look like a control code ESC $31

Then a value (unknown) - possibly mode, as this is different for graphs.

Then a negative flag

Two more bytes (always seem to be zero).

The number is then sent as 4 octets in two bytes, so you can get -9.999 to +9.999

That's it.

We assume the two bytes which always seem to be zero are to allow support for a further 4 digits but that is a pure guess, as they should never be required.

[RWAP]

We are now making some progress with this - it looks as though there are at least two graph modes.

One is for digital watches and sends the data as +/- x,xxx,xx seconds change over time - obviously there is something wrong with a watch that is losing 9,000+ seconds so we tend to ignore the first two digits for plotting a graph.

The other mode is for analogue watches. This uses a microphone to listen for the tick / tock - it then sends a readout which appears to be the noise at 32768Hz, with a value up to 10,000.00 At the moment, we are taking that reading and dividing it by 32768, so that we get a value which we can plot, assuming the first value is the "tick", the second is the "tock" we then plot those values.

How you use that for timing is another question!!

[RWAP]

Further progress today with this one - we are at least now gettign data which matches what we see on the QT-2100 tester from both digital and analogue watches.

There are some odd commands being sent which we have no idea what they are for though (they are a variation of the main reading command, but with 2 data bytes instead of 5).

[RWAP]

More information about the Seiko QT-2100P printer emulator and how we created it have been added to our website:
https://www.retroprinter.com/anatomy-of ... -emulator/

It has been an interesting journey so far, but at least we now get something like the original output (so far as we can tell!)

[inboost]

Hello All,

I have been working on this project with @RWAP and he's asked me to jump in and provide my feedback and suggestions here on the support forum. Here's where I am at so far with my review and thoughts for the next iteration of it's functionality. I'll post my comments based on the printing mode. to keep everyone straight here's a quick cheat sheet:

Mode A [10S] - used to print mechanical watch function in a 'timegrpaher' style plot with 10sec/day divisions.
Mode A [2M] - used to print mechanical watch function in a 'timegrpaher' style plot with 2min/day divisions.
Mode B [1S] - used to print quartz watch (LCD or stepper) in a line graph as in Mode A, but this is always a single trace
Mode C - used to show quartz (LCD or stepper) data in text list format instead of a graphical line trace

Note that these modes will have different behaviors based on the sample time assigned to the test in the Seiko QT-2100, most notably the Mode A output.

Here are my requests / suggestions!

Mode A [10S]
---------------

1) Fix output width to +/- 30 seconds with 6 major horizontal graduations to match
QT-2100P output scale

2) When gate time is set in seconds (not Hz) we get a single line imitating Mode B [1s]
so we do NOT want to wrap the line over as a high gain or loss rate could be misinterpreted
Byte 3 gives us the means to track this where:
Byte 3 = 00 then it's in seconds single line plotting mode so hold to end of scale
Byte 3 = 20 or 21 then it's in Hz dual line plotting mode so allow wrapping
Action - hold to end of scale, and plot an * instead of a dot on the margin to indicate 'OVER'

3) Handling of OVER scale data (see page 4 of QT-2100P manual)
When the LED display goes blank due to a miscalculation in measurement a new message is sent:
1B 31 01 AO Error if last good message has byte 3 = 20
1B 31 01 A1 Error if last good message has byte 3 = 21
I think the A0/A1 is an indicator on how to pick up and carry on from the last known position
either adding or subtracting from the last known value.

There also may br something to do with BYTE 4 data perhaps being a bit field where the octet yields
a different 'flag' for each bit position. Observed bit patterns: 0001,0010,0011,0101,0110,0111,1000,1001
(1,2,3,5,6,7,8,9) - oddly never 0100 (4) !? - Some combination of these is going to
be useful in knowing to simply not plot that point and either reset to zero for
the next point or pick up from the last good point.

When a 1B 31 01 Ax message goes through skip a line and wait for the next point of data
If the next point of data is 1B 31 01 Ax then skip again
If the next point to come through is useful data, perform the add/subtract function as
supplied by the Ax value and continue on.




Mode A [2M]
------------

1) Fix output width to +/- 600 seconds with 5 major horizontal graduations to match
QT-2100P output scale

2) When gate time is set in seconds (not Hz) we get a single line imitating Mode B [1s]
so we do NOT want to wrap the line over as a high gain or loss rate could be misinterpreted
Byte 3 gives us the means to track this where:
Byte 3 = 00 then it's in seconds single line plotting mode so hold to end of scale
Byte 3 = 20 or 21 then it's in Hz dual line plotting mode so allow wrapping
Action - hold to end of scale, and plot an * instead of a dot on the margin to indicate 'OVER'

3) Handling of OVER scale data (see page 4 of QT-2100P manual)
When the LED display goes blank due to a miscalculation in measurement a new message is sent:
1B 31 01 AO Error if last good message has byte 3 = 20
1B 31 01 A1 Error if last good message has byte 3 = 21
I think the A0/A1 is an indicator on how to pick up and carry on from the last known position
either adding or subtracting from the last known value.

There also may br something to do with BYTE 4 data perhaps being a bit field where the octet yields
a different 'flag' for each bit position. Observed bit patterns: 0001,0010,0011,0101,0110,0111,1000,1001
(1,2,3,5,6,7,8,9) - oddly never 0100 (4) !? - Some combination of these is going to
be useful in knowing to simply not plot that point and either reset to zero for
the next point or pick up from the last good point.

When a 1B 31 01 Ax message goes through skip a line and wait for the next point of data
If the next point of data is 1B 31 01 Ax then skip again
If the next point to come through is useful data, perform the add/subtract function as
supplied by the Ax value and continue on.


Mode B [1s]
-----------

1) Fix output width to +/- 1.5 sec/day and place solid lines at -1.0 and +1.0
and dotted lines at 0.2 sec/day intervals

2) Do NOT allow this plot to wrap to the other side

3) Handling of OVER scale data (see page 4 of QT-2100P manual) - Would like to somehow replicate the
'Large Dot' printed at the margin. As shown below when we get an 'OVER' condition in this mode the
data is 1B 31 03 but in byte 4 instead of 01 we get 81. In this test I was using my 'Zombie Quartz Movement'
with it's crystal oscillator run by an external signal generator. It was given a step function to drive it
between -0.360 sec/day and -10.000 sec/day which produces an 'OVER' error. In the case it was a positive rate
Byte 4 would have gone between 00 and 80

byte 0 1 2 3 4 5 6 7
1B 31 03 01 00 00 03 60
1B 31 03 01 00 00 03 62
1B 31 03 01 00 00 03 62
1B 31 03 01 00 00 03 61
1B 31 03 81
1B 31 03 81
1B 31 03 81
1B 31 03 81
1B 31 03 81
1B 31 03 81
1B 31 03 01 00 00 85 13
1B 31 03 01 00 00 03 60
1B 31 03 01 00 00 03 60
1B 31 03 01 00 00 03 68

Action: When byte 4 = 8x plot a large dot in the margin and then wait for the next line of data
if byte 4 = 0x then plot normal data. if byte 4 = 8x then plot another large dot in the margin and wait

Here is data from an LCD wrist watch running just slightly ahead of best timing at +0.008 sec/day

byte 0 1 2 3 4 5 6 7
1B 31 03 00 00 00 00 08
1B 31 03 00 00 00 00 08
1B 31 03 00 00 00 00 08
1B 31 03 00 00 00 00 09
1B 31 03 80
1B 31 03 00 00 00 00 08
1B 31 03 00 00 00 00 08
1B 31 03 00 00 00 00 08
1B 31 03 00 00 00 00 08
1B 31 03 00 00 00 00 08
1B 31 03 80
1B 31 03 80
1B 31 03 80
1B 31 03 00 00 00 00 09
1B 31 03 80
1B 31 03 00 00 00 00 08
1B 31 03 00 00 00 00 19
1B 31 03 00 00 00 00 08
1B 31 03 00 00 00 00 09


Mode C
------
1) Add CSV output of result to allow for external graphing in EXCEL or similar
I imagine this as an option in the config directory output_QT2100_CSV (yes/no)

2) Report time between data points as GATE TIME to simple integer precision of
the allowable values: 1,2,4,5,6,10,20,30,60,120 as a second column or a single
value at start or end of record

4) Handling of OVER scale data (see page 4 of QT-2100P manual) - I need to try
and replicate an error condition mid stream to see what raw data comes out of
the port. Would like it to report 'OVER' instead of time gain/loss value
we get an 'OVER' condition in this mode we are given the same message as we are
in mode B[1S] so error trapping is the same.

Action - when 1B 31 03 8x appears print a line that says OVER in text instead
of the normal rate message


General functionality
---------------------

1) QT-2100P User Manual - If you think this is useful and something you would like
I would be happy to write this up for you (where would it go?)

2) TIMEOUT variable must be greater than GATE TIME set on device as the output
may come at periods of as much as 120sec - should be noted

3) System Time / Date stamp at end of record equal to time and date when retro
printer processes the file (same as file naming convention)