Help: how to read LONG raw ASCII input like NM
Archiver
Posts: 46,084
You could solve the problem by "throwing hardware at it" such as an external
UART or, as Jon pointed out, the BS2p when it becomes available.
A second approach is to recognize that (1) every platform has its limitations
and (2) a close and detailed study of your platform is necessary in order to
maximize its utility in light of (or, in spite of) its limitations.
Your Stamp's SERIN statement has a large bag of tricks at its disposal. Those
techniques in concert with your careful thinking can produce some pretty
surprising results. Consider the following typical NMEA sentence:
$GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68
That's 66 ASCII bytes by my count. Now suppose we want to read this entire
sentence in and then send it to an LCD. But the Stamp only has 26 bytes of
variable space--how to stuff 66 bytes into a 26 byte bag?
Technique #1: don't store constant information like "$GPRMC", or ',', or '.'
or 'A', or 'N'. Use it for parsing purposes, but don't store it. Then
re-create it later as needed. Replacing the constant information with a '/'
for the sake of this discussion, the remaining data stream looks like:
///////225446///4916/45///12311/12///000/5/054/7/191194/020/3/E/68
Now we're down to 40 significant ASCII bytes by my count. Read carefully about
the WAIT and DEC modifiers to see how you can parse the data stream to find,
bypass or "ignore" data.
Technique #2: don't store unnecessary data. The checksum and magnetic
variation may be nice to know but are probably not needed (or not likely to
change) in your application. So don't bother storing them or even reading them
in if so. Making that assumption, the remaining meaningful information looks
like:
///////225446///4916/45///12311/12///000/5/054/7/191194///////////
The remaining 33 bytes still won't fit so we need to dig deeper into the SERIN
bag of tricks. By storing the time information as binary rather than ASCII, we
cut its storage requirement in half, from six bytes to three (read carefully
again the DEC modifier):
hours VAR BYTE
minutes VAR BYTE
seconds VAR BYTE
SERIN pin,baud,[noparse][[/noparse]...DEC2 hours, DEC2 minutes, DEC2 seconds,...]
The same can be done for lat/long, speed, and date:
lat_deg VAR BYTE
lat_min VAR BYTE
lat_min_d VAR BYTE
lon_deg VAR BYTE
lon_min VAR BYTE
lon_min_d VAR BYTE
knots VAR BYTE
knots_d VAR NIB
c_m_g VAR WORD
c_m_g_d VAR NIB
SERIN pin,baud,[noparse][[/noparse]...DEC2 lat_deg, DEC2 lat_min, DEC2 lat_min_d,...]
That's only 13 bytes to store those 33 bytes worth of ASCII information,
leaving 13 bytes available for other variable use, or for the data fields
ignored earlier, if desired.
Use WAIT and DEC to sort through the NMEA sentence's punctuation and other
predictable structure and extract the meaningful information for you.
Warning: the SERIN bag of tricks (WAIT, DEC, ...) can fail if the serial input
stream is too fast--doesn't give your Stamp enough time to think and act
between bytes. Set your GPS or other NMEA generator at 2400 baud or slower if
feasible--the slower the better. Read the data stream all at once and make
decisions later.
Here's a starting place to re-create the sentence on your LCD:
SEROUT lcd_pin,baud,[noparse][[/noparse]"$GPRMC,", DEC2 lat_deg, DEC2 lat_min, ".",
DEC2 lat_min_d, ",A,", ...]
Insert the punctuation as needed. Unless you are really, _really_ lost, you
know which hemisphere you're in, so insert the 'N' or 'S' from your program,
and so on. Think it through. Break your problem into small pieces, then put
working pieces together into a whole. Have fun.
Steve
On 21 Jan 01 at 16:09, brandaris400@h... wrote:
> Hello,
>
> I want read long raw NMEA sentences and show them on the LCD
> display. Til yet it works well, but i read them as a variable input.
> The BS2 has only 26 variables, so after the 26th variable i can read
> nothing more...
UART or, as Jon pointed out, the BS2p when it becomes available.
A second approach is to recognize that (1) every platform has its limitations
and (2) a close and detailed study of your platform is necessary in order to
maximize its utility in light of (or, in spite of) its limitations.
Your Stamp's SERIN statement has a large bag of tricks at its disposal. Those
techniques in concert with your careful thinking can produce some pretty
surprising results. Consider the following typical NMEA sentence:
$GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68
That's 66 ASCII bytes by my count. Now suppose we want to read this entire
sentence in and then send it to an LCD. But the Stamp only has 26 bytes of
variable space--how to stuff 66 bytes into a 26 byte bag?
Technique #1: don't store constant information like "$GPRMC", or ',', or '.'
or 'A', or 'N'. Use it for parsing purposes, but don't store it. Then
re-create it later as needed. Replacing the constant information with a '/'
for the sake of this discussion, the remaining data stream looks like:
///////225446///4916/45///12311/12///000/5/054/7/191194/020/3/E/68
Now we're down to 40 significant ASCII bytes by my count. Read carefully about
the WAIT and DEC modifiers to see how you can parse the data stream to find,
bypass or "ignore" data.
Technique #2: don't store unnecessary data. The checksum and magnetic
variation may be nice to know but are probably not needed (or not likely to
change) in your application. So don't bother storing them or even reading them
in if so. Making that assumption, the remaining meaningful information looks
like:
///////225446///4916/45///12311/12///000/5/054/7/191194///////////
The remaining 33 bytes still won't fit so we need to dig deeper into the SERIN
bag of tricks. By storing the time information as binary rather than ASCII, we
cut its storage requirement in half, from six bytes to three (read carefully
again the DEC modifier):
hours VAR BYTE
minutes VAR BYTE
seconds VAR BYTE
SERIN pin,baud,[noparse][[/noparse]...DEC2 hours, DEC2 minutes, DEC2 seconds,...]
The same can be done for lat/long, speed, and date:
lat_deg VAR BYTE
lat_min VAR BYTE
lat_min_d VAR BYTE
lon_deg VAR BYTE
lon_min VAR BYTE
lon_min_d VAR BYTE
knots VAR BYTE
knots_d VAR NIB
c_m_g VAR WORD
c_m_g_d VAR NIB
SERIN pin,baud,[noparse][[/noparse]...DEC2 lat_deg, DEC2 lat_min, DEC2 lat_min_d,...]
That's only 13 bytes to store those 33 bytes worth of ASCII information,
leaving 13 bytes available for other variable use, or for the data fields
ignored earlier, if desired.
Use WAIT and DEC to sort through the NMEA sentence's punctuation and other
predictable structure and extract the meaningful information for you.
Warning: the SERIN bag of tricks (WAIT, DEC, ...) can fail if the serial input
stream is too fast--doesn't give your Stamp enough time to think and act
between bytes. Set your GPS or other NMEA generator at 2400 baud or slower if
feasible--the slower the better. Read the data stream all at once and make
decisions later.
Here's a starting place to re-create the sentence on your LCD:
SEROUT lcd_pin,baud,[noparse][[/noparse]"$GPRMC,", DEC2 lat_deg, DEC2 lat_min, ".",
DEC2 lat_min_d, ",A,", ...]
Insert the punctuation as needed. Unless you are really, _really_ lost, you
know which hemisphere you're in, so insert the 'N' or 'S' from your program,
and so on. Think it through. Break your problem into small pieces, then put
working pieces together into a whole. Have fun.
Steve
On 21 Jan 01 at 16:09, brandaris400@h... wrote:
> Hello,
>
> I want read long raw NMEA sentences and show them on the LCD
> display. Til yet it works well, but i read them as a variable input.
> The BS2 has only 26 variables, so after the 26th variable i can read
> nothing more...
Comments
Thanks for your solid reply, I would certain try some of your solutions.
Jugo
>From: "S Parkis" <parkiss@e...>
>Reply-To: basicstamps@egroups.com
>To: brandaris400@h..., basicstamps@egroups.com
>Subject: Re: [noparse][[/noparse]basicstamps] Help: how to read LONG raw ASCII input like NM
>Date: Sun, 21 Jan 2001 11:24:03 +0800
>
>You could solve the problem by "throwing hardware at it" such as an
>external
>UART or, as Jon pointed out, the BS2p when it becomes available.
>
>A second approach is to recognize that (1) every platform has its
>limitations
>and (2) a close and detailed study of your platform is necessary in order
>to
>maximize its utility in light of (or, in spite of) its limitations.
>
>Your Stamp's SERIN statement has a large bag of tricks at its disposal.
>Those
>techniques in concert with your careful thinking can produce some pretty
>surprising results. Consider the following typical NMEA sentence:
>
>$GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68
>
>That's 66 ASCII bytes by my count. Now suppose we want to read this entire
>sentence in and then send it to an LCD. But the Stamp only has 26 bytes of
>variable space--how to stuff 66 bytes into a 26 byte bag?
>
>Technique #1: don't store constant information like "$GPRMC", or ',', or
>'.'
>or 'A', or 'N'. Use it for parsing purposes, but don't store it. Then
>re-create it later as needed. Replacing the constant information with a
>'/'
>for the sake of this discussion, the remaining data stream looks like:
>
>///////225446///4916/45///12311/12///000/5/054/7/191194/020/3/E/68
>
>Now we're down to 40 significant ASCII bytes by my count. Read carefully
>about
>the WAIT and DEC modifiers to see how you can parse the data stream to
>find,
>bypass or "ignore" data.
>
>Technique #2: don't store unnecessary data. The checksum and magnetic
>variation may be nice to know but are probably not needed (or not likely to
>change) in your application. So don't bother storing them or even reading
>them
>in if so. Making that assumption, the remaining meaningful information
>looks
>like:
>
>///////225446///4916/45///12311/12///000/5/054/7/191194///////////
>
>The remaining 33 bytes still won't fit so we need to dig deeper into the
>SERIN
>bag of tricks. By storing the time information as binary rather than
>ASCII, we
>cut its storage requirement in half, from six bytes to three (read
>carefully
>again the DEC modifier):
>
>hours VAR BYTE
>minutes VAR BYTE
>seconds VAR BYTE
>
>SERIN pin,baud,[noparse][[/noparse]...DEC2 hours, DEC2 minutes, DEC2 seconds,...]
>
>The same can be done for lat/long, speed, and date:
>
>lat_deg VAR BYTE
>lat_min VAR BYTE
>lat_min_d VAR BYTE
>lon_deg VAR BYTE
>lon_min VAR BYTE
>lon_min_d VAR BYTE
>knots VAR BYTE
>knots_d VAR NIB
>c_m_g VAR WORD
>c_m_g_d VAR NIB
>
>SERIN pin,baud,[noparse][[/noparse]...DEC2 lat_deg, DEC2 lat_min, DEC2 lat_min_d,...]
>
>That's only 13 bytes to store those 33 bytes worth of ASCII information,
>leaving 13 bytes available for other variable use, or for the data fields
>ignored earlier, if desired.
>
>Use WAIT and DEC to sort through the NMEA sentence's punctuation and other
>predictable structure and extract the meaningful information for you.
>
>Warning: the SERIN bag of tricks (WAIT, DEC, ...) can fail if the serial
>input
>stream is too fast--doesn't give your Stamp enough time to think and act
>between bytes. Set your GPS or other NMEA generator at 2400 baud or slower
>if
>feasible--the slower the better. Read the data stream all at once and make
>decisions later.
>
>Here's a starting place to re-create the sentence on your LCD:
>
>SEROUT lcd_pin,baud,[noparse][[/noparse]"$GPRMC,", DEC2 lat_deg, DEC2 lat_min, ".",
> DEC2 lat_min_d, ",A,", ...]
>
>Insert the punctuation as needed. Unless you are really, _really_ lost,
>you
>know which hemisphere you're in, so insert the 'N' or 'S' from your
>program,
>and so on. Think it through. Break your problem into small pieces, then
>put
>working pieces together into a whole. Have fun.
>
>Steve
>
>On 21 Jan 01 at 16:09, brandaris400@h... wrote:
>
> > Hello,
> >
> > I want read long raw NMEA sentences and show them on the LCD
> > display. Til yet it works well, but i read them as a variable input.
> > The BS2 has only 26 variables, so after the 26th variable i can read
> > nothing more...
>
>
>
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
read in several bytes, then tell the GPS to stop sending. The BS2 could
send what it has to the LCD. Then the BS2 could tell the GPS to begin
sending the info again. On and on. But Steve is correct, don't store
or read in stuff you don't care about.
Tracy
Original Message
From: S Parkis [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=z-FHsJ1gp54jEs4wLX1l8iOD89mSjKEkMRkBXRDRhUSk9mOrVYjZtZZco6qo2VDEq8jdJxkm39q5OXNDYlsi]parkiss@e...[/url
Sent: Saturday, January 20, 2001 8:24 PM
To: brandaris400@h...; basicstamps@egroups.com
Subject: Re: [noparse][[/noparse]basicstamps] Help: how to read LONG raw ASCII input like
NM
You could solve the problem by "throwing hardware at it" such as an
external
UART or, as Jon pointed out, the BS2p when it becomes available.
A second approach is to recognize that (1) every platform has its
limitations
and (2) a close and detailed study of your platform is necessary in
order to
maximize its utility in light of (or, in spite of) its limitations.
Your Stamp's SERIN statement has a large bag of tricks at its disposal.
Those
techniques in concert with your careful thinking can produce some pretty
surprising results. Consider the following typical NMEA sentence:
$GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68
That's 66 ASCII bytes by my count. Now suppose we want to read this
entire
sentence in and then send it to an LCD. But the Stamp only has 26 bytes
of
variable space--how to stuff 66 bytes into a 26 byte bag?
Technique #1: don't store constant information like "$GPRMC", or ',', or
'.'
or 'A', or 'N'. Use it for parsing purposes, but don't store it. Then
re-create it later as needed. Replacing the constant information with a
'/'
for the sake of this discussion, the remaining data stream looks like:
///////225446///4916/45///12311/12///000/5/054/7/191194/020/3/E/68
Now we're down to 40 significant ASCII bytes by my count. Read
carefully about
the WAIT and DEC modifiers to see how you can parse the data stream to
find,
bypass or "ignore" data.
Technique #2: don't store unnecessary data. The checksum and magnetic
variation may be nice to know but are probably not needed (or not likely
to
change) in your application. So don't bother storing them or even
reading them
in if so. Making that assumption, the remaining meaningful information
looks
like:
///////225446///4916/45///12311/12///000/5/054/7/191194///////////
The remaining 33 bytes still won't fit so we need to dig deeper into the
SERIN
bag of tricks. By storing the time information as binary rather than
ASCII, we
cut its storage requirement in half, from six bytes to three (read
carefully
again the DEC modifier):
hours VAR BYTE
minutes VAR BYTE
seconds VAR BYTE
SERIN pin,baud,[noparse][[/noparse]...DEC2 hours, DEC2 minutes, DEC2 seconds,...]
The same can be done for lat/long, speed, and date:
lat_deg VAR BYTE
lat_min VAR BYTE
lat_min_d VAR BYTE
lon_deg VAR BYTE
lon_min VAR BYTE
lon_min_d VAR BYTE
knots VAR BYTE
knots_d VAR NIB
c_m_g VAR WORD
c_m_g_d VAR NIB
SERIN pin,baud,[noparse][[/noparse]...DEC2 lat_deg, DEC2 lat_min, DEC2 lat_min_d,...]
That's only 13 bytes to store those 33 bytes worth of ASCII information,
leaving 13 bytes available for other variable use, or for the data
fields
ignored earlier, if desired.
Use WAIT and DEC to sort through the NMEA sentence's punctuation and
other
predictable structure and extract the meaningful information for you.
Warning: the SERIN bag of tricks (WAIT, DEC, ...) can fail if the serial
input
stream is too fast--doesn't give your Stamp enough time to think and act
between bytes. Set your GPS or other NMEA generator at 2400 baud or
slower if
feasible--the slower the better. Read the data stream all at once and
make
decisions later.
Here's a starting place to re-create the sentence on your LCD:
SEROUT lcd_pin,baud,[noparse][[/noparse]"$GPRMC,", DEC2 lat_deg, DEC2 lat_min, ".",
DEC2 lat_min_d, ",A,", ...]
Insert the punctuation as needed. Unless you are really, _really_ lost,
you
know which hemisphere you're in, so insert the 'N' or 'S' from your
program,
and so on. Think it through. Break your problem into small pieces,
then put
working pieces together into a whole. Have fun.
Steve
On 21 Jan 01 at 16:09, brandaris400@h... wrote:
> Hello,
>
> I want read long raw NMEA sentences and show them on the LCD
> display. Til yet it works well, but i read them as a variable input.
> The BS2 has only 26 variables, so after the 26th variable i can read
> nothing more...