Quantar V.24 Interface

From W9CR
Revision as of 12:08, 3 April 2016 by Bryan (talk | contribs) (Created page with "'''Note this is taken verbatim from [http://mattames.com/wiki/index.php/Understanding_the_Motorola_Quantar_V.24_interface Matt Ames Wiki] due to availability issues on the ori...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Note this is taken verbatim from Matt Ames Wiki due to availability issues on the original page

Introduction

This page aims to take all the pertinent information that myself, user ASTRO Spectra and others have discovered and shared on the p25.ca forum in this thread here. Since Quantars are linked using the V.24 interface, this makes connecting them up over long distances quite a challenge, since the only equipment that can transport V.24 over long distances are telco grade MUXes, microwave links, or TeNSr Channel Banks connected via T1/E1 circuits. (TeNSr stands for Telecommunications Network Server.) A simpler and more modern way would be to use an IP based connection. The first step in designing such an interface is to understand what traffic is actually going over this interface, which is the purpose of this exercise.

V.24

The V.24 daughterboard provides a V.24 interface at the front of the station via an RJ45 socket. This can be used to link to other Quantars in the back to back RT/RT configuration, or to an ASTROtac vote comparator, or back to a DIU3000 analog to digital interface. This uses synchronous serial RS232 at the PHY layer. The framing and transport layer that operates on top of this physical layer is bit stuffing HDLC which is a protocol that was developed by the ISO in the late 1980s and early 1990s, and was state-of-the art at the time the Quantar was released.

Connecting to the V.24 without a V.24 daughtercard

Usually, the V.24 daughtercard (part number TTN4010) is required in order to connect to the HDLC interface in the Quantar. The HDLC interface can be accessed at TTL levels by taking the pins directly off the J300 connector on the Wireline Board (model number CLN6955 used as reference). The 50 pin V.24 interface J300 is located towards the main card edge connector. Pin 1 is marked with a small arrow on the silk screen; pin 2 is the next pin across with pin 3 the next pin down. The locations of pins 49 and 50 are wrong on the wireline board parts locator diagrams in the manual (68P81088E90-E). The Quantar is the DTE In this case, and the signals are all 5V TTL level on this connector. This means the maximum length of any cable connected to this interface is about 3-4 feet or so, and since it is being used in a RF hot environment, it will require screening.

The TTL to V.24 interface can be home brewed easily by using off the shelf RS-232 interface chips (eg the classic MAX232.) Three drivers will be needed to build the interface, as there are data, clock and control lines in both directions.


Wireline J300 Connector pinout - used to connect V.24 board or ASTRO Modem to Wireline card
Pin Number Function
Pins 1, 2, 49, 50 Ground (there are other ground pins).
Pin 36 RXD1 to Quantar, pulled to +5 via 10k
Pin 45 TXD1 from Quantar
Pin 34 RDCLK1 to Quantar, pulled to +5 via 10k
Pin 43 TDCLK1 to/from Quantar
Pin 42 CTS1 to Quantar, pulled to +5 via 10k
Pin 41 RTS1 from Quantar
Pin 31 CD1 to Quantar, pulled to +5 via 10k
Pin 33 SQ1 - high means Quantar is providing the clock on Pin 43 (DTE timed TX), low means Quantar is expecting a clock (external TX timing) on Pin 43, pulled to +5 via 10k
Pins 44, 46 +5V
RJ45 pinout on front of Quantar V.24 board
Pin Number Function
Pin 1 RX clock to Quantar
Pin 2 CD input to Quantar
Pin 3 TX clock from Quantar
Pin 4 GND
Pin 5 RX data to Quantar
Pin 6 TX data from Quantar
Pin 7 CTS to Quantar
Pin 8 RTS from Quantar

V.24 HDLC Protocol

ASTRO Spectra used an old HP J2302 protocol analyzer to sniff the traffic on the Quantar V.24 interface. The HDLC frames were then analyzed and the content of each frame was investigated.

Idle traffic and Link Establishment

It was discovered that when the V.24 interface is started, the Quantar sends out periodic HDLC Supervisory Frames (S-frames), specifically a SABM (Set Asynchronous Balanced Mode) frame as follows.


Set Asynchronous Balanced Mode (SABM) Frame

fd 3f 43 0a

Address = 253, Frame Type = 0x3f (SABM), Poll/Final = 0 (Poll), FCS = 0x43-0a


Un-numbered Acknowledgement (UA) Frame

The SABM frames are sent until the remote end responds with a UA (Unnumbered Acknowledgement) frame, once this is received, the originating station sends a single UA frame back.

Exchange Identification (XID) Frame

Next Exchange Identification (XID) frames are exchanged; these frames contain information fields as follows for an Quantar to DIU example:

fd bf 01 05 c2 00 00 00 00 ff 93 30 =

Address = 253, Frame Type = 0xbf (XID), Poll/Final = 0 (Poll), FCS = 0x93-30

Info = 01 05 c2 00 00 00 00 ff

The payload appears to be a message as follows: Message type 1, (station site number ID * 2) + 1, station type (Quantar = C2). The test Quantar was site 2 in this example. FF may indicate the end of the message string.

Next, an XID frame is sent the reverse direction, from DIU to Quantar:-

0b bf 01 1b 00 00 00 00 00 ff e6 69 =

Address = 011, Frame Type = 0xbf (XID), Poll/Final = 0 (Poll), FCS = 0xe6-69

Info field = 01 1b 00 00 00 00 00 ff

This lines up with the DIU, which defaults to an ID 13. The ID is calculated via (2 * 13) + 1 = 1b in hex.

Notice that for the first time in the set-up exchange we see an HDLC address that’s not 253.


Receive Ready (RR) Frame

Following the SABM, UA, and XID exchanges the stations then continue to send Receive Ready (RR) messages as a keep alives. If the Quantar doesn’t receive a RR message after about 5 seconds it reverts to sending SABM messages, similarly for the DIU but with a longer timeout.

fd 01 be d2

Address = 253, Frame Type = 0x01 (RR), Poll/Final = 0 (Poll), N(r) = 0, FCS = 0xbe-d2


Voice Traffic Un-numbered Information (UI) Frames

Now investigating conventional P25 framed speech, it turns out that the Quantar sends unnumbered information frames (UI-frames) containing an information payload with the encoded voice. These frames vary between 18 and 34 bytes, a sample frame is:

07 03 60 02 04 0c 0b 1b 51 1a 37 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 3a 5d bf

Which in HDLC speak is:

Address = 007, Frame Type = 0x03 (UI), Poll/Final = 0 (Poll), FCS = 0x5bd-bf

In this frame the sample payload is the 30 bytes between 60 02 …. 00 3A. As before, the first two bytes are the address and frame type, and the last two are the checksum.

Voice Frames in order

The first UI frame payload is always 10 bytes. From now on we’ll ignore the address, frame type and frame checksum bytes. An example of the first frame is as follows:-

00 02 04 0c 0b 00 00 00 00 00

The second UI payload contains the following:

60 02 04 0c 0b 1b 57 1a 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 0a

The third UI payload looks like this:

61 00 01 17 14 2a 10 33 31 00 39 2a 22 04 23 12 11 0a 00 03 0c 02

While the subsequent UI payloads look like this:

62 02 04 0c 0b 1b 5a 1a 2e 80 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
63 04 0c fd 7b fb 7d f2 7b 3d 9e 45 00 7a
64 00 00 00 00 04 0c fd 7b fb 7d f2 7b 3d 9e 44 02
65 00 00 01 00 04 0c fd 7b fb 7d f2 7b 3d 9e 45 02
66 00 00 50 00 8c ce 59 0b d9 b2 00 0b 19 de 7c 02
67 b7 4a af 00 80 da 89 bd 23 5b 80 08 2d d7 bb 46
68 c4 68 30 00 18 e1 ac 6c 5d 80 05 1d 56 14 08 02
69 68 cf a5 00 9c ca 8e 92 d8 b5 00 0d 45 c9 85 02
6a 82 88 06 b8 a6 b0 b3 c5 d8 00 06 a9 27 b8 00
6b 02 04 0c 0b 1b 58 1a 30 98 6c a5 3b 33 ef 8f 00 0a c9 c9 37 0a
6c a8 d5 24 68 ee 65 00 08 11 1a f0 02 32
6d 00 00 00 00 b4 a6 f0 27 4e 88 00 08 8d 2c 07 02
6e 00 00 00 00 98 dc 2b 59 8a 59 80 0b 7d 03 a6 02
6f 00 00 00 00 a0 c5 99 9c b4 06 80 0b 31 9e 6f 02
70 80 00 00 00 98 ad 83 80 d9 bf 80 09 ec af 54 02
71 ac b8 a4 00 98 b1 59 7d 1b e2 00 09 51 61 e5 02
72 9b dc 75 00 a8 f4 51 b3 08 28 80 04 92 ce 58 02
73 f1 70 06 90 a3 df 19 fd 19 00 08 d5 b2 65 00