Raytheon "Integrated Instrumentation" talker ID

[Dave Parker]

Hi

Sorry to jump in here. I feel I've done enough research to pose this
question in the dev list but if I'm mistaken please accept my apology
in advance.

I've got a Raytheon navigation system on my boat that includes a
number of NMEA attachment points (two inputs, three outputs). I'm
currently working with the output from the autopilot's computer. I've
hooked it into an intel linux box and am successfully receiving NMEA
data from the course computer at 4800bd (8n1).

My glee was shortlived however when I came to the realization that
gpsd won't recognize any of the data coming from that device. I'm
certain I understand at least one part of that: the "talker ID" that
the course computer sends is "II" - "Integrated Instrumentation".
Another reason may be that of the sentences normally recognized by
gpsd (RMC, GLL, GGA, GSA, GSV, ZDA), GLL is the only one that this
device emits (the others are related to course and course deviation,
speed, etc).

For my purposes, however, GLL would be adequate.

My question then is this: Could I make gpsd "work" with this feed by
altering it's default notion of the "talker ID", and if so, where is
that notion codified. I've looked through the code (albeit briefly)
and I attempted to do a quick hack in nmea_parse.c and drivers.c to
wit:

drivers.c: if (session->outbuffer[0]=='$' &&
strchr("II",session->outbuffer[1]))
nmea_parse.c: {"IIRMC", GPRMC, processGPRMC},
nmea_parse.c: {"IIGGA", GPGGA, processGPGGA},
nmea_parse.c: {"IIGLL", GPGLL, processGPGLL},
nmea_parse.c: {"IIGSA", GPGSA, processGPGSA},
nmea_parse.c: {"IIGSV", GPGSV, processGPGSV},

This hasty and ignorant act however gave me no joy, so I'm hoping one
of you can point me in a more intelligent direction.

For your reference, my intention is to use gpsd in combination w/
kismet in this case. I do have another NMEA attach point that emits
all of the other supported sentences. It however has the same "talker
ID" issue (and is a bit of a wiring hassle for me).

Here is a sample of NMEA output from the course computer interface:

$IIGLL,3658.00,N,12200.11,W,025238,A*28
$IIHDG,167.,,,15.,E*16
$IIBWC,025238,,,,,,T,,M,,N,*0F
$IIHDM,167.,M*12
$IIHDT,182.,T*19
$IIVTG,000.,T,345.,M,00.0,N,,K*45

Thanks in advance for your time.

[Eric S. Raymond]

Post by Dave Parker
Sorry to jump in here. I feel I've done enough research to pose this
question in the dev list but if I'm mistaken please accept my apology
in advance.

No worries, you asked the right question in the right place.

Post by Dave Parker

Post by Dave Parker
My question then is this: Could I make gpsd "work" with this feed by

altering it's default notion of the "talker ID", and if so, where is
that notion codified. I've looked through the code (albeit briefly)
and I attempted to do a quick hack in nmea_parse.c and drivers.c to
drivers.c: if (session->outbuffer[0]=='$' &&
strchr("II",session->outbuffer[1]))
nmea_parse.c: {"IIRMC", GPRMC, processGPRMC},
nmea_parse.c: {"IIGGA", GPGGA, processGPGGA},
nmea_parse.c: {"IIGLL", GPGLL, processGPGLL},
nmea_parse.c: {"IIGSA", GPGSA, processGPGSA},
nmea_parse.c: {"IIGSV", GPGSV, processGPGSV},
This hasty and ignorant act however gave me no joy, so I'm hoping one
of you can point me in a more intelligent direction.

That didn't work because, while you told the NMEA interpreter the
right thing, you didn't tell the packet getter. It's still looking
for packets beginning with GP.

Presently it is wired in pretty deep that the talker ID is GP. I think
I can change this fairly easily so that the talker ID is a compile-time
parameter with a default of GP. More than that will be difficult.

Let me go off and look at this for a bit. I'll follow up to the list.