Delorme Tripmate BS2 Interfacing
Archiver
Posts: 46,084
I'm having a little trouble interfacing my Delorme Tripmate GPS
reciever to my stamp... An example string that I'm sent is:
$GPRMC,020438,V,3300.9990,N,09649.7490,W,53.549,181.3,240397,5.7,E*54
The problem is that that third field "V" has to be an "A" for the
data to be "valid" and even though I get valid data after a few
minutes of having it connected, it is still sending the letter V
instead of A. Anyone else have this problem before and can advise me
if I need to send a string to initialize the tripmate? Right now the
RX and TX lines are crossed for auto boot and I'm not sure if that
may be causing a problem... Any help/examples of source code or
anything else related to interfacing the two would be GREATLY
appreciated!
-special [noparse][[/noparse]k]
reciever to my stamp... An example string that I'm sent is:
$GPRMC,020438,V,3300.9990,N,09649.7490,W,53.549,181.3,240397,5.7,E*54
The problem is that that third field "V" has to be an "A" for the
data to be "valid" and even though I get valid data after a few
minutes of having it connected, it is still sending the letter V
instead of A. Anyone else have this problem before and can advise me
if I need to send a string to initialize the tripmate? Right now the
RX and TX lines are crossed for auto boot and I'm not sure if that
may be causing a problem... Any help/examples of source code or
anything else related to interfacing the two would be GREATLY
appreciated!
-special [noparse][[/noparse]k]
Comments
I've fiddled with various Garmin GPS and Stamps. I've got some ideas below. The
application I used it for was for a boat. The stamp read and stored the gps
position. In the event of a SOS situtation the captain presses a button, and the
stamp sends out a morse SOS message to a radio transmitter on 2182 Khz.
On NMEA A and V indications:
I've noticed that the Garmin family only starts sending valid "A" data once it
has synchonised with the satelites. This of course makes sense. However until
they synchronize they send the last known position.
I don't know the model you've used but is there a way of telling externally
whether you have synchonised?. If not, you can take the unit out for a walk to
force synchronisation on a different lat and longitude.
When you bring it back in, if the data is still showing the new location, then
you know you are not synchonising. If it shows a differenct location then you
know you are synchronising.
On Interfacing:
The Stamp is a pain to interface to this type of device. But I've had some
success.
On the Garmins I've used, handshaking on the serial link for NMEA is not
possible, and the speed is set to 4800 bps.
The length and variability of the NMEA string also makes it hard to reading data
into variables in one go.
What I did was to use a BS2SX fo speed, and read the chars in one at a time in a
loop. The stamp process the data afterwards.
The good news is that I could connect the Garmin directly to any old pin on the
stamp and read it ok.
Here is an example from my code for the BS2X in full.
This is one of several modules in different eeprom pages. Other modules in other
pages take the data in SP ram and process it.
The code below assumes there is a serial LCD connected.
----0
0
0----0----
'This inputs GPS serial input to Scratchpad RAM
B300 con 24697
B600 con 20530
B1200 con 18447
B2400 con 17405
B4800 con 16884
B9600 con 16624
'*********************************************************************
'** LCD Constants **
'*********************************************************************
LcdPort con 0
LcdRate con B9600
LcdControl con 254
LcdCLS con 1
LcdLine1 con 128
LcdLine2 con 128+64
'*********************************************************************
'** GPS Constants **
'*********************************************************************
GpsPort con 1
GpsRate con B1200
'*********************************************************************
'** Debug **
'*********************************************************************
True con 0
False con 1
GpsSim con True ' set to false when testing w/out gps
Debugg con False ' set to true when debugging
'*********************************************************************
'** EEPROM data **
'*********************************************************************
FakeInputStartAddr data "@010614033358N5131318W00004682S"
data 0
'*********************************************************************
'** State Values for Action Code **
'*********************************************************************
acStoreMsg con 0
acStoreMsgComplete con 1
acSendMsg con 2
acSendMsgComplete con 3
'*********************************************************************
'** Message Code values **
'*********************************************************************
mcGPS con 0
mcSOS con 1
mcMOB con 2
mcRescue con 3
mcMedical con 4
'*********************************************************************
'** Response code values **
'*********************************************************************
rcActionOk con 0
rcInvalidAction con 255
'*********************************************************************
'** Global Data in SP RAM **
'*********************************************************************
ActionCodeAddr con 0
ActionReturnCodeAddr con 1
MsgCodeAddr con 2
RetriesSinceLastValidAddr con 3
IncomingGpsAddr con 4 ' GPS message
'*********************************************************************
'** Variables **
'*********************************************************************
ch var byte
i var word
SP var byte
GpsRetryCount var word
CharCnt var word
START:
'*********************************************************************
'** Program starts here **
'*********************************************************************
GpsRetryCount=0
if Debugg=False then DoSerialInput
debug "GPS1.BSX",cr
DoSerialInput:
'*********************************************************************
'** **
'** Waits for @ char and copies input data to scratchpad ram **
'** from location 0 upwards. **
'** **
'*********************************************************************
SP=IncomingGpsAddr
CharCnt=0
if GpsSim=True then NoGPS
Debug "Waiting for GPS",cr
gosub LcdClear
serout LcdPort,LcdRate,[noparse][[/noparse]"Waiting for GPS"]
gosub LcdGotoLine2
serout LcdPort,LcdRate,[noparse][[/noparse]"Retry: ",dec GPSRetryCount]
Loop:
Serin GpsPort,GpsRate,Parity,2000,NoSerial,[noparse][[/noparse]ch]
if ch="@" then StoreGPSS
CharCnt=CharCnt+1
if CharCnt>40 then BadData
goto Loop
Capture:
Serin GpsPort,GpsRate,Parity,2000,NoSerial,[noparse][[/noparse]ch]
StoreGPSS:
if ch=CR then GotCR
Put SP,ch
SP=SP+1
goto Capture
BadData:
Debug "Bad Data" ,cr
gosub LcdGotoLine2
serout LcdPort,LcdRate,[noparse][[/noparse]"GPS Connected? "]
GpsRetryCount=GpsRetryCount+1
pause 2000
goto DoSerialInput
NoSerial:
Debug "no serial" ,cr
gosub LcdGotoLine2
serout LcdPort,LcdRate,[noparse][[/noparse]"GPS Switched on?"]
GpsRetryCount=GpsRetryCount+1
pause 2000
goto DoSerialInput
Parity:
Debug "Parity Error",cr
gosub LcdGotoLine2
serout LcdPort,LcdRate,[noparse][[/noparse]"GPS parity error"]
GpsRetryCount=GpsRetryCount+1
pause 2000
goto DoSerialInput
GotCR:
put SP,0 'sentinel for end of string
GpsRetryCount=0
SerialDunit:
run 2
NoGPS:
'*********************************************************************
'** **
'** SIMULATOR for testing without GPS **
'** Copies pre-recorded value in eeprom to scratchpad ram **
'** from location 0 upwards. This simulates input from GPS **
'** **
'*********************************************************************
i=FakeInputStartAddr
Debug "Simulating GPS",cr
NoGPSLoop:
read i,ch
if ch=0 then SerialDunit
put SP,ch
i=i+1
SP=SP+1
goto NoGPSLoop
LcdClear:
serout LcdPort,LcdRate,[noparse][[/noparse]LcdControl,LcdCLS]
pause 10
return
LcdGotoLine1:
serout LcdPort,LcdRate,[noparse][[/noparse]LcdControl,LcdLine1]
return
LcdGotoLine2:
serout LcdPort,LcdRate,[noparse][[/noparse]LcdControl,LcdLine2]
return
The Garmin
Original Message
From: "special_4k4" <special_4k4@y...>
To: <basicstamps@yahoogroups.com>
Sent: Friday, January 04, 2002 3:35 AM
Subject: [noparse][[/noparse]basicstamps] Delorme Tripmate BS2 Interfacing
> I'm having a little trouble interfacing my Delorme Tripmate GPS
> reciever to my stamp... An example string that I'm sent is:
> $GPRMC,020438,V,3300.9990,N,09649.7490,W,53.549,181.3,240397,5.7,E*54
> The problem is that that third field "V" has to be an "A" for the
> data to be "valid" and even though I get valid data after a few
> minutes of having it connected, it is still sending the letter V
> instead of A. Anyone else have this problem before and can advise me
> if I need to send a string to initialize the tripmate? Right now the
> RX and TX lines are crossed for auto boot and I'm not sure if that
> may be causing a problem... Any help/examples of source code or
> anything else related to interfacing the two would be GREATLY
> appreciated!
>
> -special [noparse][[/noparse]k]
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and Body
of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
[noparse][[/noparse]Non-text portions of this message have been removed]
string. Here's the information on it from
http://nwaprs.org/aprsinfo.htm :
Decoding Global Positioning System Sentences
RMC - Recommended minimum specific GPS/Transit data
RMC Sentence Format:
$GPRMC,123519,A,4807.038,N,01131.324,E,000.0,276.9,150895,000.5,E*73
$GPRMC,HHMMSS,A,DDMM.MM,N,DDDMM.MM ,W,XXX.X,XXX.X,DDMMYY,XXX.X,E*XX
Decoded 1 2 3 4 5 6 7 8 9 10 11 12
1. Time (UTC) : of fix
2. Position valid (A=valid, V=invalid) :
3. Latitude at UTC time (degrees and minutes)
4. Latitude direction (N=north, S=south)
5. Longitude at UTC time (degrees and minutes)
6. Longitude direction (E=east, W=west)
7. Speed over ground (knots)
8. Course over ground or track (degrees, true)
9. Date (day, month, year) : Date of fix
10. Magnetic variation (degrees)
11. Magnetic variation direction (E=east, W=west)
12. Checksum
-Garmin-45 RMC:
$GPRMC,062428,A,3250.782,N,09645.682,W,000.0,360.0,310595,,*00
-Tripmate RMC:
$GPRMC,020438,A,3300.9990,N,09649.7490,W,53.549,181.3,240397,5.7,E*54
-APRS processed RMC GPS fix:
CS>APRS:@011714z3216.89N/10852.57Wu233/56./APRS/good RMC Fix
Points to note:
-Processed APRS data is 2 decimal places or DDDMM.MM
-Garmin RMC output is 3 decimal places or DDDMM.MMM
-Tripmate RMC output is 4 decimal places or DDDMM.MMMM
-The NMEA format is comma delimited so most software can process the
different GPS data strings.
The problem that I've had is that even though I am recieving the
correct latitude, longitude, date, and time, the GPS reciever is
giving me a "V" instead of an "A" in field 2... I'm wondering if I
need to send an initialization string... I had pins 2 and 3 tied
together so it would automatically send data, but since then, I've
seperated them and started sending "ASTRAL" to the reciever to start
it up. When I get home later today (at HS right now), I'll see if I
can leave it on for like 5-10 min and see if it will start sending me
the right data.
The reason I'm so confused is because when I use the Delorme
Streetatlas 7.0, reading the raw data, the program recieves the
correct field ("A") after 2-3 minutes.
-special [noparse][[/noparse]k]
--- In basicstamps@y..., <tony.wells@a...> wrote:
> Hi special [noparse][[/noparse]k]
>
> I've fiddled with various Garmin GPS and Stamps. I've got some
ideas below. The application I used it for was for a boat. The stamp
read and stored the gps position. In the event of a SOS situtation
the captain presses a button, and the stamp sends out a morse SOS
message to a radio transmitter on 2182 Khz.
>
> On NMEA A and V indications:
> I've noticed that the Garmin family only starts sending valid "A"
data once it has synchonised with the satelites. This of course makes
sense. However until they synchronize they send the last known
position.
>
> I don't know the model you've used but is there a way of telling
externally whether you have synchonised?. If not, you can take the
unit out for a walk to force synchronisation on a different lat and
longitude.
>
> When you bring it back in, if the data is still showing the new
location, then you know you are not synchonising. If it shows a
differenct location then you know you are synchronising.
>
> On Interfacing:
>
> The Stamp is a pain to interface to this type of device. But I've
had some success.
>
> On the Garmins I've used, handshaking on the serial link for NMEA
is not possible, and the speed is set to 4800 bps.
>
> The length and variability of the NMEA string also makes it hard to
reading data into variables in one go.
>
> What I did was to use a BS2SX fo speed, and read the chars in one
at a time in a loop. The stamp process the data afterwards.
>
> The good news is that I could connect the Garmin directly to any
old pin on the stamp and read it ok.
>
> Here is an example from my code for the BS2X in full.
> This is one of several modules in different eeprom pages. Other
modules in other pages take the data in SP ram and process it.
>
> The code below assumes there is a serial LCD connected.
> [noparse][[/noparse]Source code removed for length]
to a BS2. The "V" indicates the fix is not yet valid, and the Tripmate can
take several minutes to lock, even when outside with a full view of the sky.
While the lat/lon/time info may be close, it's not what the GPS chip
considers a proper solution yet. In your example below, the GPS unit thinks
the date is March 24th, 1997, so it hasn't gotten the proper date/time from
the satellites.
You can also check the GPGGA and GPGSA sentences for valid fixes. If the
RMC sentences indicates invalid, they should also indicate the same. Lots
of online documentation for GGA and GSA sentence format.
Tying the RX and TX lines together does not cause any problems for getting
fixes.
If you initialize the unit with the proper lat/lon/time, the
time-to-first-fix is shortened greatly. However, you will have to send the
ASTRAL string yourself and can't tie the RX and TX lines. I may be able to
find the format of the initialization string if you're interested.
73 de Mark N9XTN
Mark D. Conner
E-mail: n9xtn@a...
Homepage: http://members.home.net/mconner1
"Arrogance and stupidity, all in the same package.....how efficient
of you!" - Ambassador Londo Mollari, Babylon 5
===================================
Date: Fri, 04 Jan 2002 03:35:21 -0000
From: "special_4k4" <special_4k4@y...>
Subject: Delorme Tripmate BS2 Interfacing
I'm having a little trouble interfacing my Delorme Tripmate GPS
reciever to my stamp... An example string that I'm sent is:
$GPRMC,020438,V,3300.9990,N,09649.7490,W,53.549,181.3,240397,5.7,E*54
The problem is that that third field "V" has to be an "A" for the
data to be "valid" and even though I get valid data after a few
minutes of having it connected, it is still sending the letter V
instead of A. Anyone else have this problem before and can advise me
if I need to send a string to initialize the tripmate? Right now the
RX and TX lines are crossed for auto boot and I'm not sure if that
may be causing a problem... Any help/examples of source code or
anything else related to interfacing the two would be GREATLY
appreciated!
flight path). Any additional information that you could provide on GPS
interfacing (initializing) would be appreciated and we will certainly publish
additional information on our web site.
We're using the BS2p in our experiments because it can buffer the entire GPS
string into its scratchpad RAM. Once the string is in RAM it can be parsed
without fear of dropping characters -- not to mention the complications of
using the WAIT modifier in SERIN.
-- Jon Williams
-- Applications Engineer, Parallax
In a message dated 1/4/02 8:26:45 AM Central Standard Time, mconner1@h...
writes:
> I have used a Tripmate previously in amateur radio balloon flights, hooked
> to a BS2. The "V" indicates the fix is not yet valid, and the Tripmate can
> take several minutes to lock, even when outside with a full view of the sky.
> While the lat/lon/time info may be close, it's not what the GPS chip
> considers a proper solution yet. In your example below, the GPS unit thinks
> the date is March 24th, 1997, so it hasn't gotten the proper date/time from
> the satellites.
>
> You can also check the GPGGA and GPGSA sentences for valid fixes. If the
> RMC sentences indicates invalid, they should also indicate the same. Lots
> of online documentation for GGA and GSA sentence format.
>
> Tying the RX and TX lines together does not cause any problems for getting
> fixes.
>
> If you initialize the unit with the proper lat/lon/time, the
> time-to-first-fix is shortened greatly. However, you will have to send the
> ASTRAL string yourself and can't tie the RX and TX lines. I may be able to
>
[noparse][[/noparse]Non-text portions of this message have been removed]
interested?
--- In basicstamps@y..., jonwms@a... wrote:
> At Parallax we're experimenting with GPS and model airplanes
(recording the
> flight path). Any additional information that you could provide on
GPS
> interfacing (initializing) would be appreciated and we will
certainly publish
> additional information on our web site.
>
Jim
--- In basicstamps@y..., "mddemetz" <miked@t...> wrote:
> I have 8 BS2 GPS programs I have found on the WEB if anyone is
> interested?
>