28501 gps

mmoreland

How does the 28501 GPS module and a BS2p derive or interpret the time/date information (hr:min:sec and month day year that print when the program is running) from the data it receives from satellites? What is the essential time/date information that's transmitted?

alex123

All the GPS satellites send is time. Each has an on-board atomic clock. Based on the time the GPS receiver calculates a 2D (or 3D) position. They also send the satellite number to be 100% precise.

Tor

alex123 wrote: »

All the GPS satellites send is time. Each has an on-board atomic clock. Based on the time the GPS receiver calculates a 2D (or 3D) position. They also send the satellite number to be 100% precise.

They send a little bit more than that..
The GPS satellites send 37k messages at 50 bits per second. The message consists of frames, where some data is repeated as often as every 30 seconds but other parts may go the full 12.5 minutes between repeats. The message contains a lot of stuff, including but not limited to:
- Time, as week number since Jan. 6 1980 (10 bits, i.e. rolls over after 1023) and time within the week. The time is not corrected for leap seconds and is as of now 15 seconds ahead of UTC.
- Almanac data, which are reduced-precision ephemeris data for all the GPS satellites.
- Ephemeris data, full-precision, for itself only.
- Telemetry data (housekeeping).
- Satellite ID.

The ephemeris data is needed to calculate where the satellite is. When you know the time and position of at least 3 satellites you'll be able to calculate where you are.
As it takes time for the ephemeris data to come around, and it takes time to find the satellites in the first place (and when you find one you'll have to wait for the almanac data to come around so that you can get an idea of where the others are, and thus their doppler shift and frequency, and when you find it you have to wait for its ephemeris data), then you have the reason for why it can take a while to get first lock.

-Tor

alex123

Yeah, I have access to wikipedia too. What I meant was that this is a time based system. All you need is time... (and money... )

mmoreland

Thanks Tor and Alex, Since time comes as week since 1980 or perhaps 1999 since it rolled over to 0 again after 1024 weeks, where in the code that is received by the GPS module is the week number embedded? And where is the number that represents the seconds of the present week embedded?

alex123

Most GPS's (if not all) use what's called NMEA protocol. They send ASCII strings with data that you have to prase to get what you need. There's a bunch of documents that give you details on the NMEA format. Here's a link to one of them:
http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf

mmoreland

Does anyone know how to get a ZDA string using the 28501 module? Is there sample code provided for anything besides the RMC string?

Publison

mmoreland wrote: »

Does anyone know how to get a ZDA string using the 28501 module? Is there sample code provided for anything besides the RMC string?

According to the manufacture's spec, The ZDA sentence is not available in this model.

Output Message: NMEA0183 V2.2 GGA, GSV, GSA, RMC (optional VTG, GLL)

Date and time are available in the RMC sentence.

$GPRMC

Recommended minimum specific GPS/Transit data

eg1. $GPRMC,081836,A,3751.65,S,14507.36,E,000.0,360.0,130998,011.3,E*62
eg2. $GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68


225446 Time of fix 22:54:46 UTC
A Navigation receiver warning A = OK, V = warning
4916.45,N Latitude 49 deg. 16.45 min North
12311.12,W Longitude 123 deg. 11.12 min West
000.5 Speed over ground, Knots
054.7 Course Made Good, True
191194 Date of fix 19 November 1994
020.3,E Magnetic variation 20.3 deg East
*68 mandatory checksum

PJAllen

David B found a way to access 1pps with a "minor" hardware mod of the PMB-688 (p/n 28501)
http://forums.parallax.com/showthread.php?129914-Parallax-GPS-sensor-PMB-688-1PPS&highlight=1pps

mmoreland

Date and time are available in the RMC sentence.[/QUOTE]

This is true. I am, however, wanting to use ddmm info in another place, so I've used GET to put it in some variables. The problem I've run into is that the RMC string changes length due to changes in number size a few places to the left of the date, so I can't reliably obtain the ddmm figures as they move from location to location. Normally they are in locations 50-53, but some times they are in locations 49-52 and occasionally in 48-51. If there's another way around this problem, I'd be happy to learn it. That's why I hoped to get the ZDA string. mm

PJAllen

If the data field lengths vary, the number of commas separating them is fixed.
So, count the commas.

With $GPGLL, the position of date and time in the sentence do not vary.

mmoreland

It appears to me that GLL provides only time not date. How do I instruct the Stamp to give me the first four elements after the ninth comma in the string? A reference?

PJAllen

First, WAIT for "$GPRMC," (that tests for the right sentence and the first comma).
Then set up a loop that WAITs for a comma 8 times and then capture the date data into your array.

Or

WAIT for "$GPRMC,"
SKIP the next 38 characters
WAIT for a comma
WAIT for a comma
capture 6 bytes date data into your array

PJAllen

mmoreland,
Any new developments?
How do you fare now?

mmoreland

PJAllen, How I fare is always sketchy when working with this stuff, but even geezers can learn, I hope. I used the following:

SERIN GPSpin, T4800, [WAIT("GPRMC,"), SKIP 43, WAIT(","), SPSTR 4]
GET 0, d, dd 'get two day bytes from GPS
GET 2, m, mm 'get two month bytes from GPS

and for getting the hour of the day, I used the following:

SERIN gpspin, T4800, [WAIT("GPRMC,"), SPSTR 65]
GET 0, h, hh

and both have worked just fine. I've been able to save all the data to variables and use them elsewhere. It has been a perfect solution. Thanks. There is a statement in the SERIN line from the GPS sample program following "T4800" that is "3000, No_GPS_Data with a few lines of code below beginning with No_GPS_Data: a pause and a goto, and as long as that statement is in the SERIN line, I can't get the program to leave the GPS section and go on to the section that checks the inclinometer and the section that runs the motor, so I just took it out, but I think that's not really the right way to do it since there could be a time when there was no GPS data. Does any of that make sense? Do you have any suggestions? mm

PJAllen

OK

Since time and date are in the RMC sentence you should be able to collect that data with one SERIN.
The time data is/are the first 6 characters after "$GPRMC,"
"Speed over the ground" and "Track angle in degrees", two data fields of RMC are variable length, I thought (and the cue to count commas.) Maybe it's the Speed field, not a fixed number of characters.

However, the point's moot since this is for a fixed position installation. I read in another subject of yours related to this that this is for positioning a solar collector/array.

If the SERIN Timeout is used then, given a threshold without data, the program should branch to a subroutine that reports that it cratered. Then it could go back to that SERIN or END (or you decide.)
Assuming all's well, though, the line immediately after the SERIN should be a routine where you proceed to work with the data collected.

PE -- In a similar vein, I capture all of this information:
PA VAR Byte (2) 'dd latitude
PM VAR Byte (2) 'mm
PD VAR Byte (3) '.mmm leaves off last dp
NS VAR Byte (1) 'NS
MA VAR Byte (3) 'ddd longitude
MM VAR Byte (2) 'mm
MD VAR Byte (3) '.mmm leaves off last dp
EW VAR Byte (1) 'EW
TM VAR Byte (6) 'hhmmss no frac time
AV VAR Byte (1) 'A or V, VAL or INVAL

with one line (and a lot of formatters) --

SERIN 9,188,[WAIT("GLL,"),STR PA\2,STR PM\2,SKIP 1,STR PD\3,SKIP 2,STR NS\1,SKIP 1,STR MA\3,STR MM\2,SKIP 1,STR MD\3,SKIP 2,STR EW\1,SKIP 1,STR TM\6,SKIP 5,STR AV\1]

mmoreland

Thanks. I'm not sure I understand everything here, and I'm away from the machine for a while, so I can't get on it and try things out, but I will, and I'll get back to you on this. Thanks for your help. One odd thing is the changing field length when my GPS set up isn't moving, yet the line with ground speed keeps changing showing that my location is sometimes still and sometimes moving very slowly. Perhaps the satellites collect and disseminate incorrect information that they keep correcting with respect to ground speed.

PJAllen

I haven't worked extensively with RMC, but this is all variations on a theme.
I don't know why they didn't make the speed and/or track angle fields fixed i]is it both?[/i with leading zeros (as w/ lat & lon).

In case "comma counting" is too slow, you could count the periods (2) after the E/W character and then set up a WAIT for a comma where the next character will be the first of the date.

GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W,6A

mmoreland

OK, I'm back at it and still having a problem you responded to above. Here's a sample of the code I'm using:

GPSpin PIN 0
T4800 CON 500
d VAR Byte
dd VAR Byte
m VAR Byte
mm VAR Byte
day VAR Byte
mon VAR Byte
date VAR Word

Initialize:
PAUSE 250 ' Let DEBUG open
DEBUG CLS ' Clear the screen
Main:
SERIN GPSpin, T4800, 2000, No_GPS_Data, [WAIT("GPRMC,"), SKIP 43, WAIT(","), SPSTR 4]
No_GPS_Data:
PAUSE 2500
GOTO Initialize
GET 0, d, dd
GET 2, m, mm
day = ((d-"0")*10)+(dd-"0")
mon = ((m-"0")*10)+(mm-"0")
date = (mon-1*30)+(mon/9+mon/2)-(mon MAX 3/3*2)+day
DEBUG "Day of the year is ", DEC date,CR,CR
SLEEP 15

When the "No_GPS_Data" label is placed immediately after SEROUT, the program recycles endlessly between the command and the label. If the label is placed at the end of the program but before SLEEP, it executes the code that follows SEROUT, but it never sleeps. If I put it after the SLEEP command, it works fine, but I suspect the isn't doing anything.

In the fuller set of code, there are a number of subroutines. If the label is placed before the subroutines, they never execute, but if it's placed at the end after all the subroutines, it's ineffective in assuring the routines have GPS data to use.

The BS Manual asserts (p. 415) that in order to use the Timeout, Tlabel, arguments, Fpin must be specified, but in the example on p. 408, no Fpin is specified. However, in the example, the Tlabel ends with a DEBUG. It doesn't contain a GOTO as my use does. Any idea what I'm doing wrong here?

One last item...I just added a DEBUG to the Tlabel. The program executes, gives me a day of the year, sleeps for 15 seconds and then executes the Tlabel argument with the DEBUG statement that there is no GPS data despite the fact that there is data. mm

PJAllen

You cannot have the "No GPS Data" routine right after the SERIN.
What's happening is that if it has good data it executes the very next line of executable code - which is, in your example the first line of the No GPS Data routine". You have to jump over that

Initialize:
  PAUSE 250 ' Let DEBUG open
  DEBUG CLS ' Clear the screen
Main:
  SERIN GPSpin, T4800, 2000, No_GPS_Data, [WAIT("GPRMC,"), SKIP 43, WAIT(","), SPSTR 4]
  [COLOR="red"]GOTO GPS_OK[/COLOR]

No_GPS_Data:
  PAUSE 2500
  GOTO Initialize

[COLOR="red"]GPS_OK:[/COLOR]  
  GET 0, d, dd
  GET 2, m, mm
  day = ((d-"0")*10)+(dd-"0")
  mon = ((m-"0")*10)+(mm-"0")
  date = (mon-1*30)+(mon/9+mon/2)-(mon MAX 3/3*2)+day
  DEBUG "Day of the year is ", DEC date,CR,CR
  SLEEP 15

mmoreland

Wow, that was helpful! Thanks. I'm still trying to implement your suggestion above for the SERIN command as it looks quite different from the one I'm using, and so far, I haven't been able to get the hour as well as the day and month from the same SERIN command. Some late replies to implied questions: comma counting isn't too slow. Nothing has to happen fast here. It is an attempt to write a program that will operate a single axis solar array.

Your list of variables has numbers in parentheses...what is that? Perhaps you'd say something about what's happening in your string of formatters above.

PJAllen

Here's the GLL sentence (form):
$GPGLL,3723.2475,N,12158.3416,W,161229.487,A*2C
Given:
SERIN 9,188,[WAIT("GLL,"),STR PA\2,STR PM\2,SKIP 1,STR PD\3,SKIP 2,STR NS\1,SKIP 1,STR MA\3,STR MM\2,SKIP 1,STR MD\3,SKIP 2,STR EW\1,SKIP 1,STR TM\6,SKIP 5,STR AV\1]

It's for a BS2, no scratchpad ram, so everything goes into VARs/VAR arrays [the parentheses with the VAR declarations mean: Array!]
Most of the SKIPs are skipping commas, the SKIP 5 skips over the decimal and 'frac' seconds of the time and the following comma.
PA array captures 3 7
PM array captures 2 3
skip period
PD array captures 2 4 7
skip 5 comma
NS captures N
skip comma
MA array captures 1 2 1
MM array captures 5 8
skip period
MD array captures 3 4 1
skip 6 comma
EW captures W
skip comma
TM array captures 1 6 1 2 2 9
skip period 4 8 7 comma
AV captures A

mmoreland

Thanks, PJ Allen; that helped me to understand. Since I'm using a BS2p, I'll keep working with SPSTR in an effort to get the items out of the string that I need without resorting to two SERIN commands. And thanks again for the several pieces of earlier help. Michael

mmoreland

I'm not sure where to put a new request concerning the above, so I'll try here and see what happens. The thread above refers to the construction of a single axis tracking solar array which has been in service since 2011 and working fine. This morning it woke up as usual, set to the correct angle, and then I turned it off to reset it to vertical, so I could wash the array. Since turning it back on, it refuses to reset to the correct angle for the day and time. This is a procedure I've employed dozens of times over the years. I haven't begun to work on it, but it appears it's not getting information from GPS, that is, it sets itself to a zero position to begin the day, which it is doing, but under normal circumstances, it takes about ten seconds to get input from GPS to move to its first position of the day. That isn't happening. I see that the GPS accessory is discontinued. With this minimal amount of information, does anyone have any thoughts or suggestions? mm

iseries

Is the GPS working first off. Second is there was an event in the GPS date time function that just happen recently where the data used to determine the date over flowed. Since this is an older GPS unit perhaps that has come into play.

Mike

mmoreland

Thanks for your comments, Mike. I'm working on it. mm

Tracy Allen

If it comes down to it, I have a spare, unused #28501 GPS module that you could swap into your system. If it works, then it's yours. However, I'm first more inclined to suspect a loose or corroded connection.

mmoreland

Hello Tracy Allen, Thank you for your comment. Six hours after the failure the array operator spontaneously began working again and has continued to function according to design until today, so I hadn't returned to the forum, and I missed your comment. This morning, as on April 26, I turned it off/on/off to send it vertical, so I could wash it. After washing, I turned it back on; it initialized the tracking maneuver by finding the zero position, but it will not move from there. I'm only guessing that it's the GPS module or its antenna, so I will examine all the connections carefully and get back. If there is a corroded or loose connection, then I suppose the string of data coming from the module could have errors simulating a malfunctioning module. Thank you for the suggestion. mm

Tracy Allen

Water get into something? Please report back what you find. Ah, troubleshooting.

mmoreland

I have found nothing. At 11 AM the day of the incident, the array resumed its normal behavior, and I'm reluctant to mess with it when it's working. I know that's cowardly, but in this instance I'm in way over my head. I've had water issues before that I've solved by installing a 4 watt bulb in the controller housing along with small sacks of desiccant that I replace every few months, and that has solved the matter. The previous response to water has been erratic movement rather than not moving at all. The way it's set up, the power supply for the motor turns off when the array goes dormant at the end of the day. I have a revised circuit that will leave the power supply on for ambient heat all the time in place of the 4 watt bulb, but as above, not wanting to mess with something that works, I have the parts and plans for the revision sitting in my office. Those were a lot of words to tell you haven't done anything, I don't know anything, and the array is working as it should. My current work around is to wash it before it turns on in the morning. mm

iseries

With those older GPS units it often too a long time for those units to find enough satellites to get a lock on. In some cases they would never get there. I know because I had a number of Bluetooth units that often had to be turned in the right direction at the right time before they would lock on.

There is probably nothing wrong with the unit other than getting a good signal.

Mike