NMEA0183 parsing out of variable space

KidE · 2012-03-12 09:21

HI All,

Iḿ trying to parse to following NMEA string

 $GPRMC,160056.000,A,5156.7871,N,00600.9030,E,0.00,206.54,120312,,,A*6E

Beside doing a degrees to decimal conversion (and other stuff) i also would like to output the complete string to send it via SEROUT.

As i'm chopping my way through a sample from the parallax site iḿ running into a "Out of variable space" error in the editor.

My code sofar is:

' {$STAMP BS2}
' {$PBASIC 2.5}

'----[ Program Definitions ]------------------------------------------------------------------------------
'
' <desciption>


'----[ I/O definitions ]----------------------------------------------------------------------------------

gpsRx      PIN     0
GpsFixLed  PIN     1

'----[ Constants ]----------------------------------------------------------------------------------------

n4800      CON     188
n9600      CON     84

'----[ Variables ]----------------------------------------------------------------------------------------

LatDeg     VAR     Byte
LatMin     VAR     Byte
LatMinD    VAR     Word
LatSign    VAR     Byte
LatDir     VAR     Byte

LonDeg     VAR     Byte
LonMin     VAR     Byte
LonMinD    VAR     Word
LonSign    VAR     Byte
LonDir     VAR     Byte

hh         VAR     Byte
mm         VAR     Byte
ss         VAR     Byte
sss        VAR     Word
DD         VAR     Byte
MM         VAR     Byte
YY         VAR     Byte

status     VAR     Byte
dest       VAR     Nib(2)
degr       VAR     Byte(2)
Fix        VAR     Byte
counter    VAR     Nib

wVal       VAR     Word

'----[ EEPROM Data ]--------------------------------------------------------------------------------------


'----[ Initialisation ]-----------------------------------------------------------------------------------

counter = 0

'----[ Program Code ]-------------------------------------------------------------------------------------

Main:
DO
  GOSUB GPS_Fix

  'Get GPSRMC statement from pin 0
  SERIN 0, n4800, [WAIT("RMC,"), DEC2 hh,DEC2 mm,DEC2 ss, SKIP 1,DEC3 sss, SKIP 1, status,
      DEC2 LatDeg, DEC2 LatMin, SKIP 1, DEC LatMinD, SKIP 1, LatSign,
      DEC3 LonDeg, DEC2 LonMin, SKIP 1, DEC LonMinD, SKIP 1, LonSign,
      SKIP 1, DEC dest(1), SKIP 1, DEC2 dest(2), SKIP 1, DEC degr(1), SKIP 1, DEC degr(2)]

      DEBUG "$GPRMC,", DEC2 hh, DEC2 mm, DEC2 ss, ".", DEC3 sss, ",", status, ",",
           DEC2 LatDeg, DEC2 LatMin, ".", DEC LatMinD, ",", LatSign, ",",
           DEC3 LonDeg, DEC2 LonMin, ".", DEC LonMinD, ",", LonSign, ",",
           DEC dest(1), ".",DEC2 dest(2), DEC degr(1), ".", DEC degr(2)   CR
  GOSUB AddSign



  hh = hh + 1                                                  'adjust to CET
  SEROUT 16, n9600, [DEC2 hh, ":", DEC2 mm, ":",  DEC2 ss, ".", DEC3 sss, " " ]

  wVal = (LatMin * 1000 / 6) + (LatMinD / 60)                  'convert to min/seconds
  SEROUT 16, n9600, [REP "-"\LatDir, DEC2 LatDeg, ".", DEC4 wVal, ", "]

  wVal = (LonMin * 1000 / 6) + (LonMinD / 60)                  'convert to min/seconds
  SEROUT 16, n9600, [REP "-"\LonDir, DEC LonDeg, ".", DEC4 wVal, CR]

LOOP

'----[ Subroutines ]--------------------------------------------------------------------------------------

GPS_Fix:

   SERIN 0, n4800, [WAIT("GGA,"), SKIP 36, DEC1 Fix]           ' find Fix value
   'DEBUG "Fix : ", DEC Fix, CR
   IF Fix > 0 THEN                                             ' test is GPS fix is there and set led 1 high
       HIGH 1
       RETURN
   ELSE
       counter = counter + 1
       'DEBUG DEC counter, CR
       IF counter = 10 THEN                                    ' Output NO FIX only once every 10 seconds
           SEROUT 16, n9600, ["NO GPS FIX", CR]
           counter = 0                                         ' Reset counter to 0
       ENDIF
       HIGH GpsFixLed                                          ' Flash until GPS fix is found
       PAUSE 500
       LOW GpsFixLed
       GOTO GPS_Fix                                            ' Loop until GPS fix is found
   ENDIF
RETURN

AddSign:
  IF LatSign = "S" THEN
    LatDir = 1
  ELSE
    LatDir = 0
  ENDIF

  IF LonSign = "W" THEN
    LonDir = 1
  ELSE
    LonDir = 0
  ENDIF
RETURN

I'm a unexperienced programmer so im learning on the job here.

Beside pasing through a string i want that stamp to do a lot more but iḿ wondering if im hitting bounderies already or am i just making a huge error here.

What would be a good way to solve this?

Gr,

Ernst

Mike Green · 2012-03-12 09:47

NMEA parsing does indeed eat up variable space. There are only 26 bytes of variable space available on the Stamps and there's no way to add more. On the other hand, it's very unusual to need all those variables all at the same time, so it's usually possible to reuse the variables for something else in other parts of the program. Parallax Basic has a feature called "aliases" which you can find described in the Basic Manual and the Stamp Editor's help files. Essentially you can define a new variable that occupies the same storage as some other variable. If only one part of the program uses the first variable and is finished with the variable value when other parts of the program execute, then you can define an alias that you can use in other parts of the program. Using aliases, it's also possible to use different sized variables as aliases. In other words, you may have a word variable that's used as two byte variables elsewhere. You can also have single bit variables and 4-bit (nibble) variables if that's all the storage that's needed for the variable.

KidE · 2012-03-12 11:09

OK i see but beside squeezing in nibbles and bits, there is now way iĺl be able to parse multiple NMEA strings if the stamps are that limited.
I've started 4 separate projects now and all have stranded due to lack of speed/space/variables etc and its getting a bit annoying so to speak.

How does the propeller cope with this. What are its limitations is this? is there a good comparison chart of some kind where these differences between stamp and propeller are layed out?

It would be nice to just finish one project without having to cope with all these frustrations all the time.

Mike Green · 2012-03-12 12:31

The BS2 is really kind of marginal in terms of storage for complex tasks like parsing NMEA strings. The other Stamp models are better off in that they some additional but different memory (scratchpad ram) that can be used to hold information. It's not usable for variables, but is treated like the EEPROM for access. If the NMEA data doesn't change quickly, you can also store it in EEPROM. The main problem there is that an EEPROM location can only be written about 1000000 times. That's not much of an issue if the data changes once every few seconds or less, but you can wear out the EEPROM in a modest amount of time if you're updating the EEPROM 10 times a second.

The Propeller is completely different. It has more memory (32K bytes) although the program and data have to share the 32K. Programs (like on the Stamps) are quite compact. There are some objects in the Propeller Object Exchange that do a lot of the work already for NMEA parsing. The Propeller is much much faster than the Stamps and has 8 identical processors that can all be used at the same time (usually for doing I/O). Unlike the Stamps where most of the I/O is built-in as statements, the Propeller uses pre-written objects to provide the complex I/O. For example, there are several objects available that will do buffered serial I/O, some at speeds up to 1MBaud. The Propeller can store data and programs directly on an SD card as PC-compatible files. There's an object that will handle up to 32 servos for you and is used as the basis of Parallax's Propeller Servo Controller. The Propeller can generate VGA video and/or TV (NTSC or PAL) video.

KidE · 2012-03-13 01:14

Thanks Mike for the helpfull info in this. I think i'll be switching over to the propeller chip to avoid these kind of frustrations in the future.

sylvie369 · 2012-03-13 08:30

KidE wrote: »

Thanks Mike for the helpfull info in this. I think i'll be switching over to the propeller chip to avoid these kind of frustrations in the future.

If you're doing GPS projects, you'll be very pleased that you did. You might find a bit of a hump in the initial learning curve - things like debugging are more difficult with the Prop than the BS2. But once you get those things under your belt, the GPS stuff will be FAR easier with the Prop. And of course the forums are here to help you with the learning curve stuff.

KidE · 2012-03-13 12:04

sylvie369 wrote: »

You might find a bit of a hump in the initial learning curve

Well I came as a total n00b in electronics a 5 months ago and i took the hurdle of learning the Stamp so I think I'll survive ;-)

I took a look at the spin language and the beginners books and i'm confident to learn it. By accident i just sold my professional experiment board and the board of education so i can start totally fresh and without a big gap in my wallet

sylvie369 · 2012-03-14 09:28

KidE wrote: »

Well I came as a total n00b in electronics a 5 months ago and i took the hurdle of learning the Stamp so I think I'll survive ;-)

I took a look at the spin language and the beginners books and i'm confident to learn it. By accident i just sold my professional experiment board and the board of education so i can start totally fresh and without a big gap in my wallet

The bigger challenge, I think, is getting things set up so that you can see output while you debug your program. Not that big a deal, but it's not a complete "gimme" like it is with the Stamp units. But I'm sure you'll manage it without too much trouble, and again, the Forums are here to help.

NMEA0183 parsing out of variable space

Comments