Shop OBEX P1 Docs P2 Docs Learn Events
28501 gps — Parallax Forums

28501 gps

mmorelandmmoreland Posts: 89
edited 2011-10-17 21:15 in Accessories
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?
«1

Comments

  • alex123alex123 Posts: 102
    edited 2011-08-24 12:32
    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.
  • TorTor Posts: 2,010
    edited 2011-08-25 01:06
    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
  • alex123alex123 Posts: 102
    edited 2011-08-25 07:24
    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... :D)
  • mmorelandmmoreland Posts: 89
    edited 2011-08-28 23:43
    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?
  • alex123alex123 Posts: 102
    edited 2011-08-29 04:57
    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
  • mmorelandmmoreland Posts: 89
    edited 2011-09-19 21:46
    Does anyone know how to get a ZDA string using the 28501 module? Is there sample code provided for anything besides the RMC string?
  • PublisonPublison Posts: 12,366
    edited 2011-09-20 04:14
    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
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2011-09-20 05:56
    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
  • mmorelandmmoreland Posts: 89
    edited 2011-09-20 09:25
    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
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2011-09-20 11:31
    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.
  • mmorelandmmoreland Posts: 89
    edited 2011-09-20 14:03
    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?
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2011-09-20 15:46
    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
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2011-09-24 09:03
    mmoreland,
    Any new developments?
    How do you fare now?
  • mmorelandmmoreland Posts: 89
    edited 2011-09-26 20:03
    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
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2011-09-28 16:53
    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.

    flowchart.JPG


    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]
    
    282 x 378 - 11K
  • mmorelandmmoreland Posts: 89
    edited 2011-09-30 21:14
    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.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2011-10-01 08:12
    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
  • mmorelandmmoreland Posts: 89
    edited 2011-10-17 11:42
    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
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2011-10-17 13:49
    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
    
    
  • mmorelandmmoreland Posts: 89
    edited 2011-10-17 18:49
    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.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2011-10-17 19:26
    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
  • mmorelandmmoreland Posts: 89
    edited 2011-10-17 21:15
    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
  • 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
  • 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
  • Thanks for your comments, Mike. I'm working on it. mm
  • 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.
  • 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
  • Water get into something? Please report back what you find. Ah, troubleshooting.
  • 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
  • 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
Sign In or Register to comment.