Introduction

I'm using a seismometer to explore any correlation of phase or frequency jumps in some of my sensitive frequency standards with vibration in the house. The Kinemetrics EarthScope was chosen because it was relatively inexpensive, targeted educational more than professional users, and looked like it would work out-of-the-box with no learning curve.

The Windows DOS based software that comes with the EarthScope is simple to use. Here's the first plot:

Like most instruments in the lab my first goal is to write my own software so that I can log data in real-time (in the format of my choice; in the operating system of my choice), generate real-time plots, and post them to the web site. The PS2.EXE EarthScope tool is nice but limited.

RS-232 Protocol

It's usually a simple matter to rewrite data logging and plotting software. Most RS-232 devices come with a documented protocol so that the user can adapt the instrument to their own needs. Initial attempts to log the EarthScope data at baud rates from 1200 to 115200 were not entirely successful. It is clear, once started, that the unit generated continuous binary data at a high rate. If I had to guess I would say 128 Hz 12 byte packets at 19200 baud but a series of initialization commands don't fit this model. So this instrument is not as simple as many other RS-232 sensors.

Below is a ½ second oscilloscope trace of the PC transmit pin (channel 1) and the PC receive pin (channel 2). There are a couple of commands from the PC, of varying lengths, each followed by a short response from the EarthScope. After the last command the EarthScope enters high data rate mode. But what are the commands; the responses; and the baud rate of the data? The goal will be a minimal C program to control the EarthScope and obtain the identical data stream as the DOS software that comes bundled with the instrument.

Detail of first command/response

From the high-level trace there appears to be two long commands, three medium commands, and three short commands.

Below is a close view of the first command and the response:

Zooming to 2.5 ms/div gives a picture of the command only. The bit cells are a third of 2.5 ms wide, or about 800 ms. And we can clearly make out ones and zeros.

A review of RS-232 baud rates suggests the baud rate is 1200.

With the baud rate determined we now look at the individual bits. A review of RS-232 protocol:

• TTL +5V, RS-232 -3 to -25 volts, Mark, logic 1, idle, stop bit
• TTL 0V, RS-232 +3 to +25 volts, Space, logic 0, active, start bit
• The RS-232 line, when idle, is in the Mark state (logic 1, negative 12 volts)
• A transmission starts with a start bit (logic 0, positive 12 volts)
• Then each bit is sent down the line with least significant bit sent first.
• A stop bit (logic 1, negative 12 volts) is then appended as the last signal
• That returns the line to the Mark, or idle state
• Most significant zero data bit(s) look like a stop bit

With this in mind the first command bit cells, left to right, are:

+--++++++-+++++++++-+-+++--+-

The byte format appears to be 8N1. Identifying the start (s) and stop (p) bits gives us:

s--++++++ps++++++++ps-+++--+-p

Positive voltages are 0 bits, and negative voltages 1 bits, so the binary data is:

s11000000ps00000000ps10001101p

Adjusting for LSB ordering and dropping start/stop bits gives us these three bytes:

00000011 00000000 10110001

Converting to hex gives us the following command:

0x03 0x00 0xB1

So the first command sent by the PC is "03 00 B1" (hex) at 1200 baud using 8N1 bytes.

Panning to the response byte:

Using a similar analysis the response is +-+++++-+- = s10000010p = 0100 0001 = 0x41 = 'A', also at 1200 baud

Second command/response

Below is a close view of the second command and the response. This looks like a two byte command and the same response.

Zooming to 2.5 ms/div gives a detailed picture of the command from which we can interpret bits.

The command is +-+++++++-++++-++++- = s10000000p s00010000p = 0000 0001 0000 1000 = 0x01 0x08

And the response is again 0x41 = 'A'.

Third, fourth, fifth command/response

Below is a trace of the set of three medium width commands following the first two. These are clearly not at the same 1200 baud at the first two commands. The commands are just under 5 ms wide and the response about 2 ms wide.

Zooming to 1 ms/div gives a better view of the first of these three commands. It would appear the bits are now a fifth of a 1 ms division suggesting the baud rate is now 4800 baud.

sdf

Zooming to 1 ms/div gives a better view of the first of these three commands. It would appear the bits are now a fifth of a 1 ms division suggesting the baud rate is now 4800 baud.

Zooming to 1 ms/div gives a better view of the first of these three commands. It would appear the bits are now a fifth of a 1 ms division suggesting the baud rate is now 4800 baud.

sub-title

Zooming to 1 ms/div gives a better view of the first of these three commands. It would appear the bits are now a fifth of a 1 ms division suggesting the baud rate is now 4800 baud.

Zooming to 1 ms/div gives a better view of the first of these three commands. It would appear the bits are now a fifth of a 1 ms division suggesting the baud rate is now 4800 baud.

sfd

Zooming to 1 ms/div gives a better view of the first of these three commands. It would appear the bits are now a fifth of a 1 ms division suggesting the baud rate is now 4800 baud.

The command is ++-++++++-+-+++++++- = s01000000ps10000000p = 0000 0010 0000 0001 = 0x02 0x01 and the response is 0x41 = 'A'.

We do the same for the next command: ++-++++++-+----+++++- = s01000000p s11110000p = 0000 0010 0000 1111 = 0x02 0xFF and the response is 0x41 = 'A'.

And finally the third of these three commands: +-+++++++-+-+-+++++- = s10000000p s10100000p = 0000 0001 0000 0101 = 0x01 0x05 and the response is 0x41 = 'A'. 

The final command/response

Below is a trace of the set of three narrow width commands following the first two wide commands following the next three medium commands. These are clearly not at the same baud rate as either of the previous two sets.

At this point a deep memory logic analyzer would be better than a cheap digital 'scope but we'll see what we can do.

We can tell three narrow commands, the last not as wide as the first. Then about 8 ms after the last command comes the data. It appears be be in bursts, about 6 ms wide with 2 ms gaps.

Zooming to 250 ms/div shows the first of the last three commands. At 1.5 ms long, with a bit cell width of 1/4 to 1/5 of 250 us it appears to be three bytes at 19200 baud.

The second of the narrow commands appears to be two bytes long.

And the final narrow command is one byte long with no response. Well, actually, some ms later the streaming data starts.

A view of the streaming data

After the final command bursts of data arrive.

Below

At 50 us/div the bit cells are clearly 50 us wide, 19200 baud. Bytes are 500 us. Packets are 6 ms long. or 12 bytes

The data stops when you click on Quit in the PS2.exe program.

Looking more closely at this we see a single byte at 19,200 baud stops the stream at the end of the current packet. The byte is +-+-+++++- = s10100000p = 0000 0101 = 0x05.

Summary

The following commands were observed in sequence:

Double check

Now that we know the baud rate of the commands issued to the EarthScope change several times during initialization we can monitor the transmit pin using another COM port. Data received at the wrong baud rate will be garbage (but with a certain characteristic look) but data at the correct baud rate will read correctly.

A dozen short runs of PS2.exe were made; four at each of three different baud rates. Actual command bytes are in green and garbage bytes in red. Note these commands exactly match those interpreted from the 'scope traces above.

Four runs at 1200 baud:

1: 03 00 B1 01 08 F9 FB FA FF FF
2: 03 00 B1 01 08 F9 FB FA EE
3: 03 00 B1 01 08 F9 FB FA E6 FF
4: 03 00 B1 01 08 F9 FB FA BE

Four runs at 4800 baud:

1: F8 00 00 78 F8 78 00 00 02 01 02 0F 01 05 E1 FA FE FF
2: F8 00 00 78 F8 78 00 00 02 01 02 0F 01 05 E1 F0 FE FF
3: F8 00 00 78 F8 78 00 00 02 01 02 0F 01 05 C9 FA FE FF
4: F8 00 00 78 F8 78 00 00 02 01 02 0F 01 05 E1 FA FF FF

Four runs at 4800 baud:

1: 00 00 00 00 00 00 00 00 00 00 80 00 78 80 00 F8 00 78 78 00 03 00 B1 01 05 04 05
2: 00 00 00 00 00 00 00 00 00 00 80 00 78 80 00 F8 00 78 78 00 03 00 B1 01 05 04 05
3: 00 00 00 00 00 00 00 00 00 00 80 00 78 80 00 F8 00 78 78 00 03 00 B1 01 05 04 05
4: 00 00 00 00 00 00 00 00 00 00 80 00 78 80 00 F8 00 78 78 00 03 00 B1 01 05 04 05

/tvb