JRC GPS-Rx protocol Ver 3.0B (data format)

After getting some requests for the protocol of the JRC-GPS-Rx, I started to type in the information I got in form of paper copies. If you find this information useful, please give me a hint in my guestbook. Please concern that I did not understand everything in this description, in this case I wrote it down as printed, but in slanted letters. In other cases I changed something a little bit to make it more clear.

The used JRC-format is Ver 3.0B, the type of the rx is CCA-191P used in car navigation systems.

Last Update: 2002-09-04: Contents, missing bytes in input data, experiences

Contents

• The I/O pin layout
• Interface at TX1 and RX1
• Data format
    Output data format at TX1
      no extend mode
      extend mode
      extend2 mode
    Input data format at RX1
      type = 0
      type = 1
• my experiences

The I/O pin layout

Pins are numbered from 1 to 10, 1 is the pin nearer to the board edge. Attention, there are different boxes around the PCB, with antenna connector on different sides.

Interface at TX1 and RX1

TTL-signal direct connection, 4800 Bd asynchronous, 1start bit, 8data bits, 2stop bits, no parity.

Output interval: 1s

Data format

Output data format at TX1

If a value is represented by more than one byte, most significant byte is the first, LSB is last.

In case of no extend output (default, switched to extended by input data):

In case of extend mode, byte 1..80 are the same (see note 2 for an exception), bytes 81 to 119 are as follows:

note 1: if corrections cease to be received, the value in use will continue to be treated as valid for a further 30 seconds. Age of differential data is used the maximum value from among fixed satellites.

note 2: in byte 35 (and in the other 7 bytes 41, 47,... for satellites 2..8) is an additional information in extend mode: Bits 5..2 containing the SV acuracy.

note 4: perhaps it means: satellites used for fix exist except these for 4 sats

In case of extend2 mode, bytes 105..122 carry additional information:

Input data format at RX1

If a value is represented by more than one byte, most significant byte is the first, LSB is last. After Cold start fix is done, all setting values will be set default value and data output format is set to no extend mode.

There are two different input data formats, the type flag (bit 6 in byte 20) controls which of them is used.

In case of type flag = 0:

note 3: Input-of-altitude flag? Makes more sense...

in case of type flag = 1:

my experiences

It was not a big deal to start with this rx. After connecting antenna and power (backup is required!) the RX1 pin shows the no extend format with 81 bytes. And some minutes later, the output changes, sat by sat is found and tracked. The information contained in the no extended data only is enough to convert it to the NMEA-formats for position ($GPGGA) and speed/course ($GPVTG) looking like this:

$GPGGA,190655.00,4929.410,N,00949.221,E,1,05,3.60,224,M,46,M,,*52
$GPVTG,345.0,T,345.0,M,0.0,N,0.0,K*4E

Only the last distance (46m) is faked, I can't remember it's meaning, but it wasn't important. The satellite data in this data format is interesting too - and it can be displayed in a text display:

picture...

But I also tried to switch to the extended formats. I worked, but I never wrote a program to interpret the contents of the additional bytes.

Back to JRC-contents