Scratch pad RAM and serial in

Hi all.

In the latest incarnation of the manual, it mentions that the scratch pad is useful for GPS data input. With the extra RAM, I would agree.

The only thing is, that a standard NMEA sentence is allowed to be upto 80 characters long. Most GPSs usually ouput several sentences at a time, GLL, RMC, GGA, RMB, ZDA, etc.

To make use of the scratch pad RAM, it would be useful to allow only a certain, selected sentence through.

How would you go about this?
Use an 8M, as a preselector, toggling a 28X1 via an interrupt, as an example?

Mark

You are in luck! The hserin command allows an optional parameter 'qualifier' which screens out any data unless it starts with that value. Therefore you can use $GPGGA etc to only get what you want.

The background receive option is particularly useful!


See hsersetup and hserin.

Hi KJ,

One thing I am not sure of yet is this:
for background receive I need to set up HSERSETUP like this

<code><pre><font size=2 face='Courier'>
hsersetup B4800_4, %11
main:
hserin 0,80,($GPRMC)
&quot;rest of code&quot;
</font></pre></code>

correct?
When I am ready to do something with the information, then I use @ptr etc.

I think I was thinking initially of the serrxd command, but this also allows qualifiers by the looks of it.

Well I guess that makes life a lot easier then. Thanks.

You don't have to issue an hserin if you set background receive on; that's the beauty of it. Any data that arrives is automatically placed in scratchpad. The hserptr is updated to point to the end of the data and the hserflag is set.

So you program can just go about its other business while the data is received and either poll periodically to check the hserflag or hserptr to see if there's data, or even better, set an interrupt with setintflags which so your interrupt routine can check each recieved character for end of sentence.

If I didn't konw better I'd say the PICAXE people were thinking of GPS interfaces when they came up with this stuff.

Another way is to use a normal Serin command and use @ptrinc in the variable string to extract to scratchpad only the bytes of the NMEA sentence you're interested in. Just use a dummy variable to 'skip' the bytes you're not interested in.

Background receive and interrupts are tempting and a great feature to have, but I'm not convinced they're always going to be of benefit - it depends on your app and how it processes the GPS data. For instance in my app I don't want to receive new data until the last lot's been processed (and there's a lot of processing to do), so it's better to finish processing then wait with a normal Serin until the next message. The use of Serin like this actually regulates my system to the steady output of the GPS messages.

Also with background receive you need to be careful you don't get a reception half way through processing the scratchpad data from the previous reception.

Edited by - jeremy leach on 04/07/2007 09:10:48

hardware serial commands were indeed designed for use in this type of situation.

If you do not want to background receive a new GPS string whilst processing the old one, one approach is to issue a 'hsersetup off' command before starting the processing and then re-enable it when processing is complete.

jeremy, what are you doing with the GPS data that it takes so long to process?

I'm doing complicated maths to interpolate sub-second time of arrival, along with other data storage and comparisons.


Edited by - jeremy leach on 05/07/2007 08:22:33