Thanks for the tip! It started me thinking. I apologize for the somewhat lengthy post below but it helped me my thoughts organized. Please bear with me.
I indeed think that counting the amount of GPS sentences with invalid or no information is a way to detect an error. However, error checking outside the parsing routine won't work well with my program. It has to do with the way I designed it and that has to do with speed.
I'll try to explain as far as I understand all this.
The 'kernel' of the program is the awk parsing routine. Remember that awk is a programming language and runs in it's own shell. It is fast, according to some faster than a similar program in C or C++. Calling routines from awk outside it's own shell may slow down the parsing process.
Very simplified, my program structure is, in order:
bash shell - ensure Bluetooth and monitor availability, set background
awk shell & - parse GPS data, import system data, display data (dzen2)
bash shell - grab video from display &, display webcam (Mplayer)
awk is pushed into the background ('&'), otherwise you're stuck in the awk shell and you can't easily startup the video screen grabber (also pushed into the background) or Mplayer.
awk runs happily in it's own shell but has to import/export data. Exporting text to dzen2 is no problem since dzen2 is fast enough not to cause delays, no matter how many dzen2 instances.
Importing data from /dev/rfcomm0 is no problem either because awk is infinitely faster than the speed with which GPS data comes in.
But noticeable speed issues arise when calling some of the system functions. Most evident is calling the system time:
Code: Select all
cmd="date +"%T""; cmd | getline system_time
close(cmd)
The time displayed freezes, skipping seconds at a time, is irregular. In stead I use the GPS time, convert it to local time (GPS time is always UTC) and format:
Code: Select all
local_time_hours=substr(gps_time,0,2)+timezone
if ( local_time_hours > 23 ) local_time_hours=0
local_time=local_time_hours":"gps_time_minutes":"gps_time_seconds
This is much faster than calling 'date +"T%"'.
(this, by the way, un-synchronizes time and local system date but there are solutions for that).
Similarly, calling a 'while-do' loop outside the awk shell puts a handbreak on awk. That's undesired and a waste of awk's capabilties.
Concluding this: I do not want to rely on routines outside the awk shell to recognize errors in the GPS datastream. It must be done entirely within the parsing routine itself.
That brings us to details of the GPS datastream. It looks like this (example):
--------------------------------------------------------------------------
$GPGGA,043428.163,,,,,0,00,50.0,,M,,,,0000*23
$GPGGA,043429.163,,,,,0,00,50.0,,M,,,,0000*22
$GPRMC,043429.163,V,,,,,,,020213,,,N*43
$GPVTG,,T,,M,,N,,K,N*2C
---------------------------------------------------------------------------
$GPGGA,043430.163,,,,,0,00,50.0,,M,,,,0000*2A
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05
$GPGSV,2,1,08,15,63,310,,09,55,132,29,26,45,016,23,02,43,129,*7F
$GPGSV,2,2,08,24,37,178,,29,36,271,,05,34,039,,21,07,321,*7B
$GPRMC,043430.163,V,,,,,,,020213,,,N*4B
$GPVTG,,T,,M,,N,,K,N*2C
----------------------------------------------------------------------------
$GPGGA,043431.163,,,,,0,00,50.0,,M,,,,0000*2B
$GPRMC,043431.163,V,,,,,,,020213,,,N*4A
$GPVTG,,T,,M,,N,,K,N*2C
-----------------------------------------------------------------------------
$GPGGA,043432.163,,,,,0,00,50.0,,M,,,,0000*28
$GPRMC,043432.163,V,,,,,,,020213,,,N*49
$GPVTG,,T,,M,,N,,K,N*2C
-----------------------------------------------------------------------------
(the '-------' lines are to indicate one second data blocks but actually they are empty sentences).
When the GPS signal is interrupted (.e.g. when you drive through under a bridge) there should be more empty sentences. However, the GPS receiver keeps a buffer of x seconds, so the GPS data is retained for a while. Interruptions longer than x seconds (e.g. when driving through a long tunnel) result in empty sentences only should result in a 'lost signal' error.
The parsing routine ignores empty sentences (including the ones in a normal situation as illustrated above) and thus, sofar, doesn't know the difference between intermittent empty sentences and empty sentences forever. awk just keeps looking at the /dev/rfcomm0 port with nothing to parse.
That is where the technosaurus' tip comes in: I should detect empty sentences in the parsing routine within a time frame and decide there what to do with it.
I have been looking up a lot about awk programming. Mostly, manuals and examples are about parsing text documents. awk is mostly treated as a utility alongside with grep and sed (which are programming languages too) and, worse, in combination of those and, much worse, with cat.
awk can do that all by itself. It can do al lot more than simple document processing. I read somewhere that even an OS was built with awk, but so far did not find the details.
I'll keep in touch on progress.
Thanks guys.