<div style="border:1px solid red;background-color:#FFEEEE;padding:3px;">
[[Image:warning.jpg]] '''WARNING:''' {{{1}}}
</div>

Template:Warning

2009-07-17T06:42:43Z

Kirk:

<div style="border:1px solid red;background-color:#f9ffff;padding:3px;">
[[Image:warning.jpg]] '''WARNING:''' {{{1}}}
</div>

File:Warning.jpg

2009-07-17T06:42:19Z

Kirk: Warning icon

Warning icon

HOWTO Drifter Data Processing

2009-07-17T06:40:18Z

Kirk:

Template:Warning

2009-07-17T06:38:26Z

Kirk: New page: <div style="border:1px solid red;background-color:#f9ffff;padding:3px;"> Image:http://www.tomtom.com/lib/img/cs/warning.jpg '''WARNING:''' {{{1}}} </div>

<div style="border:1px solid red;background-color:#f9ffff;padding:3px;">
[[Image:http://www.tomtom.com/lib/img/cs/warning.jpg]] '''WARNING:''' {{{1}}}
</div>

HOWTO Drifter Data Processing

2009-07-17T06:35:06Z

Kirk:

<h1>Kirk's HOWTO on processing Drifter data</h1>
 
 {{warning}} '''THIS PAGE IS NOT DONE''' 
<h2>Follow these steps to process 'raw' drifter data from [http://www.pacificgyre.com pacificgyre] to final posting on our website:</h2>
 
Notes:
<ul>
<li>Once proficient, it takes about 20 min to process a typical day's deployment.
<li>Folders/files referenced here can be found on the ICESS network at /home/locl/users/kirk/ (hereafter referred to as '..../kirk/') in the data or user subfolders.
<li>You should copy the kirk folder contents to your local computer and run the scripts there instead of on the server.
</ul>
 
<ol>
<h2>Folder: .../kirk/user/0_Info</h2>
<li>On deployment day: be sure to fill out .../kirk/user/0_Info/drifter_hist.xls (drifter history) with the
performance of the drifters to track if there are any consistent problems (Note that this file is now out of date). 
 
<h2>Folder: .../kirk/user/1_get_data_from_web</h2>
<li>Edit data_dates.m with the start/stop date/times to get. 
Notes: 
<ul>
<li>Use the [http://pacificgyre.com http://pacificgyre.com] website (log: ohlmann, pass: drifterguy) if you need to get an estimation of
when the drifters went in and came out of the water (look at in-water flag values), or go to
[http://www.icess.ucsb.edu/drifter/realtime/BETA.php http://www.icess.ucsb.edu/drifter/realtime/BETA.php] and enter custom times.
<li>Keep adding date/times to the bottom of this file (or in the appropriate "deployment type" area (e.g. SBCLS), and commented out), then copy these uncommented deployment times to
the top of it to fetch the data. Note, when in the "deployment type" groups, I number the 'dates' sequentially, but when copying one or two of them to the top to fetch, you need to make sure those 'dates' numbering start at 1.
<li>You don't have to be exact on the times (cleanup happens in following steps), just be sure you have a time at least before or at start and a time after or at ending deployment.
</ul>
<li>Run get_data.m
<ul>
<li>Be sure the IRIDIUM value in it is set correctly
<li>Data will be saved in '..../kirk/data/Drifter_Anal/2_data/yyyymmdd' folder as a yyyymmdd_drifter_dat.log file.
<li>Now, move that folder into a 'deployment type' folder (e.g. .../kirk/data/Drifter_Anal/2_data/SBCLS) 
</ul>
 
Notes: 
<ul>
<li>If IRIDIUM is set, you may want to check the settings of REMOVE_GPS_01 and CONVERT_GPS_2_TO_2 in the convert_Iridium_reports_to_Microstar_format.m file.
<li>Data format (column numbers):
</ul>
<pre>
#1 drifter ID
#2 year
#3 month
#4 day
#5 hour
#6 minute
#7 second
#8 lat
#9 long
#10 satelites availiable
#11 satelites used
#12 com flag
#13 Secs to fix
#14 Mobitex RSSI
#15 in-water flag
</pre>
<h2>Folder: .../kirk/user/2_clean_up</h2>
<li>Edit clean_up_drifter_data.m with the correct area and deploy_date at the top.

PWS Drifter Realtime Webpage Info

2009-07-17T06:17:32Z

Kirk:

<h1>Prince William Sound, Alaska Drifter Realtime Webpage Wiki</h1>

Page can be found at: [http://pws.drifterdata.com http://pws.drifterdata.com] or [http://www.icess.ucsb.edu/drifter/realtime-PWS/ http://www.icess.ucsb.edu/drifter/realtime-PWS/], and it's help page [http://www.icess.ucsb.edu/drifter/realtime-PWS/help/ here]. Other deployment info can be found [http://ak.aoos.org/aoos/fieldexp/data_by_pi-researcher.html here].
 
This page is for displaying any Surface Velocity Program (SVP) in blue, Coast Guard SLDB (CG) in green, and Oil Spill Response (OSR) in red drifter tracks. The Iridium drifters will be on the normal [http://www.icess.ucsb.edu/drifter/realtime/ realtime page]. 

<h2>File Locations</h2>
The data files must be uploaded (e.g. via ftp or sftp, for Mac one can use [http://filezilla-project.org/download.php filezilla]) to the ICESS network in this directory: '''/home/locl/file_sharing/PWS/'''. The filenames must be '''PWS_SVP_DATA.txt''' (SVP), '''PWS_CG_DATA.txt''' (Coast Guard), and '''PWS_OIL_DATA.txt''' (OSR). There are README files there to help with formatting. To not show a particular group's data, either empty the contents of the appropriate file or delete (or rename) it. 
 
There is also a '''BOX_COORDINATES.txt''' there (and README file) for setting coordinates for a box. 

<h2>File Formats</h2>
One thing to note is that fields which normally have a number must have a number, with the exception of SST which can instead have a "NaN". We really only care about 5 things ('''drifter_number, date/time, lat, lon, & SST'''), so if any of those other 4 fields are a "NaN" it should be skipped anyway since they contain critical information. As for any "non critical" columns, (e.g. "FoM" or "Batt volts" [if we set that up to be a valid column] or whatever) can contain anything since we're ignoring those columns anyway. 
 
1) SVP. The info [http://penguin.sfos.uaf.edu/output/pws/Halverson/SVP/ASCII/20090409/ here]
still doesn't show which column will have the drifter number, so for now, I'm assuming it will be the first. 
e.g.
<pre>
% Pacific Gyre SVP - Drogue center: 10m - ARGOS telemetry
% Drifter # Date/Time (UTC) Lat Lon FoM SST [C]
1234 2009/04/09 22:30:00 60.5503 -145.7611 1 5.0
</pre>
2) Coast Guard SLDMBs
The email from Rob Cermak on Jul 9th @ 17:39 has
[http://penguin.sfos.uaf.edu/output/pws/Ohlmann/SLDMBS/GNOME/20090528/SLDMBS_20090528_0823_processed.txt this link]
 
Right now, this is the format it's ready for this type format:
<pre>
Shape|OBJECTID|Buoynum|ZDateTime|DateTime|Location
|1|38669|232030Z MAY 09|39956.85|20-57.453N 071-20.205W
</pre>

3) Oil Spill Resp.
For now it's setup to be exactly in the same format as the SVP (but with one header line instead of two)

e.g.
<pre>
% Drifter # Date/Time (UTC) Lat Lon FoM SST [C]
1234 2009/04/09 22:30:00 60.5503 -145.7611 1 5.0
</pre>

<h2>Parsing Files</h2>
The webpage code and parsing scripts all live here: '''/home/kirk/public_html/drifter/realtime-PWS/'''. The parsing scripts (those which breakdown the uploaded files) are named '''getdata.SVP.php''', '''getdata.CG.php''', and '''getdata.OSR.php'''. They are pretty self explanatory if they need to be edited for any reason. One thing to note is that they use [http://us.php.net/manual/en/reference.pcre.pattern.syntax.php regular expression] (i.e. preg_match) checking to ensure that any misformatted data is skipped.

<h2>Other Notes</h2>
If for some reason, the javascript code needs to be edited, it's at '''/home/kirk/public_html/drifter/realtime-PWS/''', and there are 2 main javascript files: '''ajax.js''', '''map.js''' (with 'message.js' and 'YFT.js' providing less important support). Note that really, you want to edit the javascript files with __UNCOMPRESSED__ in their name (as the files w/o that in their name were compressed using [http://dean.edwards.name/packer/ this tool]). If you want to use these uncompressed files, you need to edit the '''index.php''' file and set '''$USE_UNCOMPRESSED''' to '''1'''.

<h2>Iridium Notes</h2>
These will show on the normal [http://www.icess.ucsb.edu/drifter/realtime/ realtime page]. If the drifter numbers to receive data for need tweaking, this file, '''/home/kirk/public_html/drifter/realtime/getdata.php''', needs to be edited around line 425. Or to show more or less hour's worth of reports, edit the '''$NUM_HRS_TO_GET''' value on line 40 (currently set to 12).

PWS Drifter Realtime Webpage Info

2009-07-17T06:14:46Z

Kirk:

<h1>Prince William Sound, Alaska Drifter Realtime Webpage Wiki</h1>

Page can be found at: [http://pws.drifterdata.com http://pws.drifterdata.com] or [http://www.icess.ucsb.edu/drifter/realtime-PWS/ http://www.icess.ucsb.edu/drifter/realtime-PWS/], and it's help page [http://www.icess.ucsb.edu/drifter/realtime-PWS/help/ here]. Other deployment info can be found [http://ak.aoos.org/aoos/fieldexp/data_by_pi-researcher.html here].
 
This page is for displaying any Surface Velocity Program (SVP) in blue, Coast Guard SLDB (CG) in green, and Oil Spill Response (OSR) in red drifter tracks. The Iridium drifters will be on the normal [http://www.icess.ucsb.edu/drifter/realtime/ realtime page]. 

<h2>File Locations</h2>
The data files must be uploaded (e.g. via ftp or sftp, for Mac one can use [http://filezilla-project.org/download.php filezilla]) to the ICESS network in this directory: '''/home/locl/file_sharing/PWS/'''. The filenames must be '''PWS_SVP_DATA.txt''' (SVP), '''PWS_CG_DATA.txt''' (Coast Guard), and '''PWS_OIL_DATA.txt''' (OSR). There are README files there to help with formatting. To not show a particular group's data, either empty the contents of the appropriate file or delete (or rename) it. 
 
There is also a '''BOX_COORDINATES.txt''' there (and README file) for setting coordinates for a box. 

<h2>File Formats</h2>
One thing to note is that fields which normally have a number must have a number, with the exception of SST which can instead have a "NaN". We really only care about 5 things ('''drifter_number, date/time, lat, lon, & SST'''), so if any of those other 4 fields are a "NaN" it should be skipped anyway since they contain critical information. As for any "non critical" columns, (e.g. "FoM" or "Batt volts" [if we set that up to be a valid column] or whatever) can contain anything since we're ignoring those columns anyway. 
 
1) SVP. The info [http://penguin.sfos.uaf.edu/output/pws/Halverson/SVP/ASCII/20090409/ here]
still doesn't show which column will have the drifter number, so for now, I'm assuming it will be the first. 
e.g.
<pre>
% Pacific Gyre SVP - Drogue center: 10m - ARGOS telemetry
% Drifter # Date/Time (UTC) Lat Lon FoM SST [C]
1234 2009/04/09 22:30:00 60.5503 -145.7611 1 5.0
</pre>
2) Coast Guard SLDMBs
The email from Rob Cermak on Jul 9th @ 17:39 has
[http://penguin.sfos.uaf.edu/output/pws/Ohlmann/SLDMBS/GNOME/20090528/SLDMBS_20090528_0823_processed.txt this link]
 
Right now, this is the format it's ready for this type format:
<pre>
Shape|OBJECTID|Buoynum|ZDateTime|DateTime|Location
|1|38669|232030Z MAY 09|39956.85|20-57.453N 071-20.205W
</pre>

3) Oil Spill Resp.
For now it's setup to be exactly in the same format as the SVP (but with one header line instead of two)

e.g.
<pre>
% Drifter # Date/Time (UTC) Lat Lon FoM SST [C]
1234 2009/04/09 22:30:00 60.5503 -145.7611 1 5.0
</pre>

<h2>Parsing Files</h2>
The webpage code and parsing scripts all live here: '''/home/kirk/public_html/drifter/realtime-PWS/'''. The parsing scripts (those which breakdown the uploaded files) are named '''getdata.SVP.php''', '''getdata.CG.php''', and '''getdata.OSR.php'''. They are pretty self explanatory if they need to be edited for any reason. One thing to note is that they use [http://us.php.net/manual/en/reference.pcre.pattern.syntax.php regular expression] (i.e. preg_match) checking to ensure that any misformatted data is skipped.

<h2>Other Notes</h2>
If for some reason, the javascript code needs to be edited, it's at '''/home/kirk/public_html/drifter/realtime-PWS/''', and there are 2 main javascript files: '''ajax.js''', '''map.js''' (with 'message.js' and 'YFT.js' providing less important support). Note that really, you want to edit the javascript files with __UNCOMPRESSED__ in their name (as the files w/o that in their name were compressed using [http://dean.edwards.name/packer/ this tool]). If you want to use these uncompressed files, you need to edit the '''index.php''' file and set '''$USE_UNCOMPRESSED''' to '''1'''.

<h2>Iridium Notes</h2>
These will show on the normal [http://www.icess.ucsb.edu/drifter/realtime/ realtime page]. If the drifter numbers to receive need tweaked, this file, '''/home/kirk/public_html/drifter/realtime/getdata.php''', needs to be edited around line 425.

2009-07-17T05:42:32Z

Kirk: New page: <h1>Prince William Sound, Alaska Drifter Realtime Webpage Wiki</h1> Page can be found at: [http://pws.drifterdata.com http://pws.drifterdata.com] or [http://www.icess.ucsb.edu/drifter/rea...

CalCOFI Drifter Realtime Webpage Info

2009-07-10T06:50:12Z

Kirk:

<h1>CalCOFI SVP Drifter Realtime Webpage Wiki</h1>

NOTES AND THINGS TO KNOW ABOUT THE SVP REALTIME PAGE 
Jun, 2009 Kirk

Webpage:
[http://www.icess.ucsb.edu/drifter/realtime-SVP/ SVP Realtime Page]

There are three main parts needed to display the data (details below): 
1. Fetching the data (using Python script running on dub-locl) 
2. Parsing the data (using PHP script running on dub-locl) 
3. Displaying the data (using Javascript running on your browser) 

<h2>1. FETCHING THE DATA</h2>

On dub-locl.icess.ucsb.edu in /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/ there is a Python script 'fetch_calcofi_svp_data.py'.
<ul>
<li>There is essentially nothing to configure it, and it's well documented should you need to change anything. It is set to fetch via ftp from ftp.aoml.noaa.gov for the last 9 days worth of positions.

<li>It may need to be updated with drifter numbers and temperature coefficients as more are sent drifting.

<li>It is set to run about every 6 hours (05:30, 11:30, 17:30 & 20:30 Pacific, and they should post the data at 8am Eastern Time) via a "cron job" on the kirk account. To edit this job, as kirk, at the Terminal, type 'crontab -e' and use 'vi' style editing commands, or 'crontab -l' to just show it. (To become kirk, login as drift, then in a Terminal, type 'sudo su -' (then type the drift password) to become root, then 'su kirk' to become kirk.)

<li>It fetches their file, archives it (to /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/DATA_ARCHIVE/), uncompresses it, and starts the parsing script (see next section).
</ul>
 
<h2>2. PARSING THE DATA</h2>

This PHP script on dub-local.icess.ucsb.edu (called by the fetching script above) is /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/parse_calcofi_argos_svp_data.php and is pretty well documented. It breaks down the fairly cryptic GPS encoding and then saves it to a friendly format. It archives this file to /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/DATA_ARCHIVE/yyyymmdd_CALCOFI_SVP_LATEST_DATA.txt and copies this file to /home/kirk/public_html/drifter/realtime-SVP/CALCOFI_SVP_LATEST_DATA.txt so the website has access to it. 
 
<ul>
<li>There is very little configuring it, and it's well documented should you need to change anything, but it does have temperature coefficients and a couple other possible configuration settings.
</ul>
It outputs 1 record per position report in this format: 
<pre>
drift_no,YY-MM-DD,HH:MM:SS,milliseconds_since_Jan01_1970,orig_report_num,lat,lon,position_type(1=GPS,0=ARGOS),SST(C),batt(V),base_time,record_num
</pre>
e.g.
<pre>
93561,2007-04-03,10:34:45,1175610885000,136,+26.6980,-081.9550,0,NaN,NaN,NaN,NaN (an argos position)
93561,2007-04-03,10:33:37,1175610817000,137,+26.6979,-081.9557,1,NaN,12.4,2007-04-03_11:33:30,2 (a gps position)
</pre>

 
<h2>3. DISPLAYING THE DATA (at [http://www.icess.ucsb.edu/drifter/realtime-SVP/ realtime page] or [http://svp.drifterdata.com http://svp.drifterdata.com]) </h2>

The Google mapping code was adapted from the Iridium/Microstar realtime page at [http://www.icess.ucsb.edu/drifter/realtime/ http://www.icess.ucsb.edu/drifter/realtime/]

The two main javascript files are ajax.js and map.js. 
 
The javascript files are compressed using http://www.icess.ucsb.edu/drifter/realtime/JavascriptCompressor.html, so changes made to the xxx__UNCOMPRESSED__.js files won't show up on the page unless they are compressed and saved without the "__UNCOMPRESSED__" portion in the name, '''OR*''' at the beginning of index.php those two types of files are commented/uncommented out as appropriate. 

 
<h2> POTENTIAL PROBLEMS / TROUBLESHOOTING</h2>

Prob: The data file (/home/kirk/public_html/drifter/realtime-SVP/CALCOFI_SVP_LATEST_DATA.txt) is not getting saved/updated
<ul>
<li>Is the dub-locl computer up?
<li>Is /home/kirk/ mounted on dub-locl? (It should come up automatically)
<li>Has 6 hours passed since the last time it ran? It only runs about every 6 hours (see above), but they only update the file once per day at 8am Eastern.
<li>Try fetching the data yourself via ftp:
</ul>
<pre>
ftp://ftp.aoml.noaa.gov/phod/pub/daily_buoydata/7325/
login: anonymous
pass: e_mail
</pre>
Look for a file of today's data with the following name format:
ddMMMyy.LOG-GZ, for example: 15JUL09.LOG-GZ (i.e. for july 15th, 2009) 
 

----
<h2>INFO ABOUT TIME CALCULATION</h2>
Basically each data block is for three hourly reports, and data blocks can be repeated (I
have no idea how that's determined), and there is a slight adjustment
to the time based on "fix delay" (or "Length of Acquisition", which is
usually on the order of <60 seconds). 
 
For example (showing the second to last block in the existing file as
I write this): 
<pre>
07325 93575 15 27 N 3 2009-06-25 20:18:59 34.416 240.156 0.000 401652653
2009-06-25 20:21:22 3 12 62 678 94
00 01 344156 01
1198452 01 04 689
01 344155 01 1198448
01 04 661 01
344156 01 1198448 01
04 587 00
</pre>
 
This *first line* contains ARGOS only info:
<pre>
prog_num 07325
drift_num 93575
lines_in_sat_pass 15
num_sensors 27
sat_name N
resolution 3
time 2009-06-25 20:18:59
xmit_lat 34.416
xmit_lon 240.156
xmit_alt 0.000
xmit_freq 401652653
</pre>
 
The next 7 lines contain 3, hourly GPS reports. 
 
---- Line 1: (2009-06-25 20:21:22 3 12 62 678 94) 
<pre>
BASE Date/Time 2009-06-25 20:21:22
# identical messages rcvd 3
Drogue count over last half hour 12
Battery voltage = n * 0.2 62 -> 12.4V
SST(C) = x * 0.043 - 5 678 -> 24.154
Checksum 94
</pre>
 
---- Line 2: (00 01 344156 01) 
<pre>
Msg ID 00 -> this is 1st message sent
Valid Pos #1 (1=good, 0=bad) 01 -> good
Lat #1 (ten-thousandths of degree) 344156 -> 34.4156
Lat #1 Ref (0 = South, 1 = North) 01 -> North
</pre>
 
---- Line 3: (1198452 01 04 689) 
<pre>
Lon #1 (ten-thousandths of degree) 1198452 -> 119.8452
Lon #1 Ref (0 = East, 1 = West) 01 -> West
Pos #1 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #1 (C) = x * 0.043 - 5 689 -> 24.627
</pre>
 
---- Line 4: (01 344155 01 1198448) 
<pre>
Valid Pos #2 (1=good, 0=bad) 01 -> good
Lat #2 (ten-thousandths of degree) 344155 -> 34.4155
Lat #2 Ref (0 = South, 1 = North) 01 -> North
Lon #2 (ten-thousandths of degree) 1198448 -> 119.8448
</pre>
 
---- Line 5: (01 04 661 01) 
<pre>
Lon #2 Ref (0 = East, 1 = West) 01 -> West
Pos #2 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #2 (C) = x * 0.043 - 5 661 -> 23.423
Valid Pos #3 (1=good, 0=bad) 01 -> good
</pre>
 
---- Line 6: (344156 01 1198448 01) 
<pre>
Lat #3 (ten-thousandths of degree) 344156 -> 34.4156
Lat #3 Ref (0 = South, 1 = North) 01 -> North
Lon #3 (ten-thousandths of degree) 1198448 -> 119.8448
Lon #3 Ref (0 = East, 1 = West) 01 -> West
</pre>
 
---- Line 7: (04 587 00) 
<pre>
Pos #3 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #3 (C) = x * 0.043 - 5 587 -> 20.241
Null bits (only for padding, ignore)
</pre>
 
 
NOTES: 
-Total bit count (a very non trivial calculation) of all 7 lines must equal the checksum value or
message block is considered garbled and thus ignored. 
 
-Times of GPS reports are calculated thusly: 
 
1) Take BASE time, subtract (Msg ID*3) [that is, if message has been
repeated, it is at least 3 hours old -- I have a switch in my code
(it's turned on for now) which will ignore messages with a message
ID>0 because the original may be also present, and it's possible the
duplicate isn't an exact duplicate and then you get slightly different
reports at similar times] 
2) Then, subtract 2 hours for Pos #3, and 1 hour for Pos #2 and 0 for Pos #1 
3) Then subtract the associated small "Length of Acq" 
 
Thus, the 2nd GPS time (i.e. #2) would be calculated thusly: 
<pre>
BASE time: 2009-06-25 20:21:22
minus 0 hours (because Msg ID is 0)
minus 1 hour (because it's Pos #2)
minus (pos #2 length of acq) 16 seconds

equals: 2009-06-25 19:21:06
</pre>
 
An additional wacky thing is that due to repetition of the messages,
or god knows what, the calculations of the reports you see aren't
necessarily in chronological order. So, after doing all the
calculations, I then sort them chronologically before outputting
(within the parse_argos_data.php script), so that when showing the
track lines, the points are in order.

CalCOFI Drifter Realtime Webpage Info

2009-07-10T06:48:50Z

Kirk:

<h1>CalCOFI SVP Drifter Realtime Webpage Wiki</h1>

NOTES AND THINGS TO KNOW ABOUT THE SVP REALTIME PAGE 
Jun, 2009 Kirk

Webpage:
[http://www.icess.ucsb.edu/drifter/realtime-SVP/ SVP Realtime Page]

There are three main parts needed to display the data (details below): 
1. Fetching the data (using Python script running on dub-locl) 
2. Parsing the data (using PHP script running on dub-locl) 
3. Displaying the data (using Javascript running on your browser) 

<h2>1. FETCHING THE DATA</h2>

On dub-locl.icess.ucsb.edu in /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/ there is a Python script 'fetch_calcofi_svp_data.py'.
<ul>
<li>There is essentially nothing to configure it, and it's well documented should you need to change anything. It is set to fetch via ftp from ftp.aoml.noaa.gov for the last 9 days worth of positions.

<li>It may need to be updated with drifter numbers and temperature coefficients as more are sent drifting.

<li>It is set to run about every 6 hours (05:30, 11:30, 17:30 & 20:30 Pacific, and they should post the data at 8am Eastern Time) via a "cron job" on the kirk account. To edit this job, as kirk, at the Terminal, type 'crontab -e' and use 'vi' style editing commands, or 'crontab -l' to just show it. (To become kirk, login as drift, then in a Terminal, type 'sudo su -' (then type the drift password) to become root, then 'su kirk' to become kirk.)

<li>It fetches their file, archives it (to /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/DATA_ARCHIVE/), uncompresses it, and starts the parsing script (see next section).
</ul>
 
<h2>2. PARSING THE DATA</h2>

This PHP script on dub-local.icess.ucsb.edu (called by the fetching script above) is /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/parse_calcofi_argos_svp_data.php and is pretty well documented. It breaks down the fairly cryptic GPS encoding and then saves it to a friendly format. It archives this file to /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/DATA_ARCHIVE/yyyymmdd_CALCOFI_SVP_LATEST_DATA.txt and copies this file to /home/kirk/public_html/drifter/realtime-SVP/CALCOFI_SVP_LATEST_DATA.txt so the website has access to it. 
 
<ul>
<li>There is very little configuring it, and it's well documented should you need to change anything, but it does have temperature coefficients and a couple other possible configuration settings.
</ul>
It outputs 1 record per position report in this format: 
<pre>
drift_no,YY-MM-DD,HH:MM:SS,milliseconds_since_Jan01_1970,orig_report_num,lat,lon,position_type(1=GPS,0=ARGOS),SST(C),batt(V),base_time,record_num
</pre>
e.g.
<pre>
93561,2007-04-03,10:34:45,1175610885000,136,+26.6980,-081.9550,0,NaN,NaN,NaN,NaN (an argos position)
93561,2007-04-03,10:33:37,1175610817000,137,+26.6979,-081.9557,1,NaN,12.4,2007-04-03_11:33:30,2 (a gps position)
</pre>

 
<h2>3. DISPLAYING THE DATA (at [http://www.icess.ucsb.edu/drifter/realtime-SVP/ realtime page] or [http://svp.drifterdata.com http://svp.drifterdata.com]) </h2>

The Google mapping code was adapted from the Iridium/Microstar realtime page at [http://www.icess.ucsb.edu/drifter/realtime/ http://www.icess.ucsb.edu/drifter/realtime/]

The two main javascript files are ajax.js and map.js. 
 
The javascript files are compressed using http://www.icess.ucsb.edu/drifter/realtime/JavascriptCompressor.html, so changes made to the xxx__UNCOMPRESSED__.js files won't show up on the page unless they are compressed and saved without the "__UNCOMPRESSED__" portion in the name, '''OR*''' at the beginning of index.php those two types of files are commented/uncommented out as appropriate. 

 
<h2> POTENTIAL PROBLEMS / TROUBLESHOOTING</h2>

Prob: The data file (/home/kirk/public_html/drifter/realtime-SVP/CALCOFI_SVP_LATEST_DATA.txt) is not getting saved/updated
<ul>
<li>Is the dub-locl computer up?
<li>Is /home/kirk/ mounted on dub-locl? (It should come up automatically)
<li>Has 6 hours passed since the last time it ran? It only runs about every 6 hours (see above), but they only update the file once per day at 8am Eastern.
<li>Try fetching the data yourself via ftp:
</ul>
<pre>
ftp://ftp.aoml.noaa.gov/phod/pub/daily_buoydata/7325/
login: anonymous
pass: e_mail
</pre>
Look for a file of today's data with the following name format:
ddMMMyy.LOG-GZ, for example: 15JUL09.LOG-GZ (i.e. for july 15th, 2009) 
 
NOTE: if you want to get data from a specific time period, use julian dates and GMT hours after the comma after 'ds'.
For example:
<pre>
prv,7325,ds,174/12-175/10,93561-93587 (for June 23rd at 12Z through June 24th at 10Z)
</pre>

Prob: The data file (/home/locl/file_sharing/SVP_CALCOFI_LATEST_DATA.txt) shows no data
<ul>
<li>There probably aren't any drifters talking in the last 24hours (look for the line "No data available or authorization failure" in the file or try manually getting the data)
</ul>

----
<h2>INFO ABOUT TIME CALCULATION</h2>
Basically each data block is for three hourly reports, and data blocks can be repeated (I
have no idea how that's determined), and there is a slight adjustment
to the time based on "fix delay" (or "Length of Acquisition", which is
usually on the order of <60 seconds). 
 
For example (showing the second to last block in the existing file as
I write this): 
<pre>
07325 93575 15 27 N 3 2009-06-25 20:18:59 34.416 240.156 0.000 401652653
2009-06-25 20:21:22 3 12 62 678 94
00 01 344156 01
1198452 01 04 689
01 344155 01 1198448
01 04 661 01
344156 01 1198448 01
04 587 00
</pre>
 
This *first line* contains ARGOS only info:
<pre>
prog_num 07325
drift_num 93575
lines_in_sat_pass 15
num_sensors 27
sat_name N
resolution 3
time 2009-06-25 20:18:59
xmit_lat 34.416
xmit_lon 240.156
xmit_alt 0.000
xmit_freq 401652653
</pre>
 
The next 7 lines contain 3, hourly GPS reports. 
 
---- Line 1: (2009-06-25 20:21:22 3 12 62 678 94) 
<pre>
BASE Date/Time 2009-06-25 20:21:22
# identical messages rcvd 3
Drogue count over last half hour 12
Battery voltage = n * 0.2 62 -> 12.4V
SST(C) = x * 0.043 - 5 678 -> 24.154
Checksum 94
</pre>
 
---- Line 2: (00 01 344156 01) 
<pre>
Msg ID 00 -> this is 1st message sent
Valid Pos #1 (1=good, 0=bad) 01 -> good
Lat #1 (ten-thousandths of degree) 344156 -> 34.4156
Lat #1 Ref (0 = South, 1 = North) 01 -> North
</pre>
 
---- Line 3: (1198452 01 04 689) 
<pre>
Lon #1 (ten-thousandths of degree) 1198452 -> 119.8452
Lon #1 Ref (0 = East, 1 = West) 01 -> West
Pos #1 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #1 (C) = x * 0.043 - 5 689 -> 24.627
</pre>
 
---- Line 4: (01 344155 01 1198448) 
<pre>
Valid Pos #2 (1=good, 0=bad) 01 -> good
Lat #2 (ten-thousandths of degree) 344155 -> 34.4155
Lat #2 Ref (0 = South, 1 = North) 01 -> North
Lon #2 (ten-thousandths of degree) 1198448 -> 119.8448
</pre>
 
---- Line 5: (01 04 661 01) 
<pre>
Lon #2 Ref (0 = East, 1 = West) 01 -> West
Pos #2 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #2 (C) = x * 0.043 - 5 661 -> 23.423
Valid Pos #3 (1=good, 0=bad) 01 -> good
</pre>
 
---- Line 6: (344156 01 1198448 01) 
<pre>
Lat #3 (ten-thousandths of degree) 344156 -> 34.4156
Lat #3 Ref (0 = South, 1 = North) 01 -> North
Lon #3 (ten-thousandths of degree) 1198448 -> 119.8448
Lon #3 Ref (0 = East, 1 = West) 01 -> West
</pre>
 
---- Line 7: (04 587 00) 
<pre>
Pos #3 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #3 (C) = x * 0.043 - 5 587 -> 20.241
Null bits (only for padding, ignore)
</pre>
 
 
NOTES: 
-Total bit count (a very non trivial calculation) of all 7 lines must equal the checksum value or
message block is considered garbled and thus ignored. 
 
-Times of GPS reports are calculated thusly: 
 
1) Take BASE time, subtract (Msg ID*3) [that is, if message has been
repeated, it is at least 3 hours old -- I have a switch in my code
(it's turned on for now) which will ignore messages with a message
ID>0 because the original may be also present, and it's possible the
duplicate isn't an exact duplicate and then you get slightly different
reports at similar times] 
2) Then, subtract 2 hours for Pos #3, and 1 hour for Pos #2 and 0 for Pos #1 
3) Then subtract the associated small "Length of Acq" 
 
Thus, the 2nd GPS time (i.e. #2) would be calculated thusly: 
<pre>
BASE time: 2009-06-25 20:21:22
minus 0 hours (because Msg ID is 0)
minus 1 hour (because it's Pos #2)
minus (pos #2 length of acq) 16 seconds

equals: 2009-06-25 19:21:06
</pre>
 
An additional wacky thing is that due to repetition of the messages,
or god knows what, the calculations of the reports you see aren't
necessarily in chronological order. So, after doing all the
calculations, I then sort them chronologically before outputting
(within the parse_argos_data.php script), so that when showing the
track lines, the points are in order.

CalCOFI Drifter Realtime Webpage Info

2009-07-10T06:47:11Z

Kirk:

<h1>CalCOFI SVP Drifter Realtime Webpage Wiki</h1>

NOTES AND THINGS TO KNOW ABOUT THE SVP REALTIME PAGE 
Jun, 2009 Kirk

Webpage:
[http://www.icess.ucsb.edu/drifter/realtime-SVP/ SVP Realtime Page]

There are three main parts needed to display the data (details below): 
1. Fetching the data (using Python script running on dub-locl) 
2. Parsing the data (using PHP script running on dub-locl) 
3. Displaying the data (using Javascript running on your browser) 

<h2>1. FETCHING THE DATA</h2>

On dub-locl.icess.ucsb.edu in /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/ there is a Python script 'fetch_calcofi_svp_data.py'.
<ul>
<li>There is essentially nothing to configure it, and it's well documented should you need to change anything. It is set to fetch via ftp from ftp.aoml.noaa.gov for the last 9 days worth of positions.

<li>It may need to be updated with drifter numbers and temperature coefficients as more are sent drifting.

<li>It is set to run about every 6 hours (05:30, 11:30, 17:30 & 20:30 Pacific, and they should post the data at 8am Eastern Time) via a "cron job" on the kirk account. To edit this job, as kirk, at the Terminal, type 'crontab -e' and use 'vi' style editing commands, or 'crontab -l' to just show it. (To become kirk, login as drift, then in a Terminal, type 'sudo su -' (then type the drift password) to become root, then 'su kirk' to become kirk.)

<li>It fetches their file, archives it (to /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/DATA_ARCHIVE/), uncompresses it, and starts the parsing script (see next section).
</ul>
 
<h2>2. PARSING THE DATA</h2>

This PHP script on dub-local.icess.ucsb.edu (called by the fetching script above) is /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/parse_calcofi_argos_svp_data.php and is pretty well documented. It breaks down the fairly cryptic GPS encoding and then saves it to a friendly format. It archives this file to /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/DATA_ARCHIVE/yyyymmdd_CALCOFI_SVP_LATEST_DATA.txt and copies this file to /home/kirk/public_html/drifter/realtime-SVP/CALCOFI_SVP_LATEST_DATA.txt so the website has access to it. 
 

It outputs 1 record per position report in this format: 
<pre>
drift_no,YY-MM-DD,HH:MM:SS,milliseconds_since_Jan01_1970,orig_report_num,lat,lon,position_type(1=GPS,0=ARGOS),SST(C),batt(V),base_time,record_num
</pre>
e.g.
<pre>
93561,2007-04-03,10:34:45,1175610885000,136,+26.6980,-081.9550,0,NaN,NaN,NaN,NaN (an argos position)
93561,2007-04-03,10:33:37,1175610817000,137,+26.6979,-081.9557,1,NaN,12.4,2007-04-03_11:33:30,2 (a gps position)
</pre>
<ul>
<li>There is very little configuring it, and it's well documented should you need to change anything.

</ul>
 
<h2>3. DISPLAYING THE DATA (at [http://www.icess.ucsb.edu/drifter/realtime-SVP/ realtime page] or [http://svp.drifterdata.com http://svp.drifterdata.com]) </h2>

The Google mapping code was adapted from the Iridium/Microstar realtime page at [http://www.icess.ucsb.edu/drifter/realtime/ http://www.icess.ucsb.edu/drifter/realtime/]

The two main javascript files are ajax.js and map.js. 
 
The javascript files are compressed using http://www.icess.ucsb.edu/drifter/realtime/JavascriptCompressor.html, so changes made to the xxx__UNCOMPRESSED__.js files won't show up on the page unless they are compressed and saved without the "__UNCOMPRESSED__" portion in the name, '''OR*''' at the beginning of index.php those two types of files are commented/uncommented out as appropriate. 

 
<h2> POTENTIAL PROBLEMS / TROUBLESHOOTING</h2>

Prob: The data file (/home/kirk/public_html/drifter/realtime-SVP/CALCOFI_SVP_LATEST_DATA.txt) is not getting saved/updated
<ul>
<li>Is the dub-locl computer up?
<li>Is /home/kirk/ mounted on dub-locl? (It should come up automatically)
<li>Has 6 hours passed since the last time it ran? It only runs about every 6 hours (see above), but they only update the file once per day at 8am Eastern.
<li>Try fetching the data yourself via ftp:
</ul>
<pre>
ftp://ftp.aoml.noaa.gov/phod/pub/daily_buoydata/7325/
login: anonymous
pass: e_mail
</pre>
Look for a file of today's data with the following name format:
ddMMMyy.LOG-GZ, for example: 15JUL09.LOG-GZ (i.e. for july 15th, 2009) 
 
NOTE: if you want to get data from a specific time period, use julian dates and GMT hours after the comma after 'ds'.
For example:
<pre>
prv,7325,ds,174/12-175/10,93561-93587 (for June 23rd at 12Z through June 24th at 10Z)
</pre>

Prob: The data file (/home/locl/file_sharing/SVP_CALCOFI_LATEST_DATA.txt) shows no data
<ul>
<li>There probably aren't any drifters talking in the last 24hours (look for the line "No data available or authorization failure" in the file or try manually getting the data)
</ul>

----
<h2>INFO ABOUT TIME CALCULATION</h2>
Basically each data block is for three hourly reports, and data blocks can be repeated (I
have no idea how that's determined), and there is a slight adjustment
to the time based on "fix delay" (or "Length of Acquisition", which is
usually on the order of <60 seconds). 
 
For example (showing the second to last block in the existing file as
I write this): 
<pre>
07325 93575 15 27 N 3 2009-06-25 20:18:59 34.416 240.156 0.000 401652653
2009-06-25 20:21:22 3 12 62 678 94
00 01 344156 01
1198452 01 04 689
01 344155 01 1198448
01 04 661 01
344156 01 1198448 01
04 587 00
</pre>
 
This *first line* contains ARGOS only info:
<pre>
prog_num 07325
drift_num 93575
lines_in_sat_pass 15
num_sensors 27
sat_name N
resolution 3
time 2009-06-25 20:18:59
xmit_lat 34.416
xmit_lon 240.156
xmit_alt 0.000
xmit_freq 401652653
</pre>
 
The next 7 lines contain 3, hourly GPS reports. 
 
---- Line 1: (2009-06-25 20:21:22 3 12 62 678 94) 
<pre>
BASE Date/Time 2009-06-25 20:21:22
# identical messages rcvd 3
Drogue count over last half hour 12
Battery voltage = n * 0.2 62 -> 12.4V
SST(C) = x * 0.043 - 5 678 -> 24.154
Checksum 94
</pre>
 
---- Line 2: (00 01 344156 01) 
<pre>
Msg ID 00 -> this is 1st message sent
Valid Pos #1 (1=good, 0=bad) 01 -> good
Lat #1 (ten-thousandths of degree) 344156 -> 34.4156
Lat #1 Ref (0 = South, 1 = North) 01 -> North
</pre>
 
---- Line 3: (1198452 01 04 689) 
<pre>
Lon #1 (ten-thousandths of degree) 1198452 -> 119.8452
Lon #1 Ref (0 = East, 1 = West) 01 -> West
Pos #1 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #1 (C) = x * 0.043 - 5 689 -> 24.627
</pre>
 
---- Line 4: (01 344155 01 1198448) 
<pre>
Valid Pos #2 (1=good, 0=bad) 01 -> good
Lat #2 (ten-thousandths of degree) 344155 -> 34.4155
Lat #2 Ref (0 = South, 1 = North) 01 -> North
Lon #2 (ten-thousandths of degree) 1198448 -> 119.8448
</pre>
 
---- Line 5: (01 04 661 01) 
<pre>
Lon #2 Ref (0 = East, 1 = West) 01 -> West
Pos #2 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #2 (C) = x * 0.043 - 5 661 -> 23.423
Valid Pos #3 (1=good, 0=bad) 01 -> good
</pre>
 
---- Line 6: (344156 01 1198448 01) 
<pre>
Lat #3 (ten-thousandths of degree) 344156 -> 34.4156
Lat #3 Ref (0 = South, 1 = North) 01 -> North
Lon #3 (ten-thousandths of degree) 1198448 -> 119.8448
Lon #3 Ref (0 = East, 1 = West) 01 -> West
</pre>
 
---- Line 7: (04 587 00) 
<pre>
Pos #3 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #3 (C) = x * 0.043 - 5 587 -> 20.241
Null bits (only for padding, ignore)
</pre>
 
 
NOTES: 
-Total bit count (a very non trivial calculation) of all 7 lines must equal the checksum value or
message block is considered garbled and thus ignored. 
 
-Times of GPS reports are calculated thusly: 
 
1) Take BASE time, subtract (Msg ID*3) [that is, if message has been
repeated, it is at least 3 hours old -- I have a switch in my code
(it's turned on for now) which will ignore messages with a message
ID>0 because the original may be also present, and it's possible the
duplicate isn't an exact duplicate and then you get slightly different
reports at similar times] 
2) Then, subtract 2 hours for Pos #3, and 1 hour for Pos #2 and 0 for Pos #1 
3) Then subtract the associated small "Length of Acq" 
 
Thus, the 2nd GPS time (i.e. #2) would be calculated thusly: 
<pre>
BASE time: 2009-06-25 20:21:22
minus 0 hours (because Msg ID is 0)
minus 1 hour (because it's Pos #2)
minus (pos #2 length of acq) 16 seconds

equals: 2009-06-25 19:21:06
</pre>
 
An additional wacky thing is that due to repetition of the messages,
or god knows what, the calculations of the reports you see aren't
necessarily in chronological order. So, after doing all the
calculations, I then sort them chronologically before outputting
(within the parse_argos_data.php script), so that when showing the
track lines, the points are in order.

CalCOFI Drifter Realtime Webpage Info

2009-07-10T06:46:56Z

Kirk:

<h1>CalCOFI SVP Drifter Realtime Webpage Wiki</h1>

NOTES AND THINGS TO KNOW ABOUT THE SVP REALTIME PAGE 
Jun, 2009 Kirk

Webpage:
[http://www.icess.ucsb.edu/drifter/realtime-SVP/ SVP Realtime Page]

There are three main parts needed to display the data (details below): 
1. Fetching the data (using Python script running on dub-locl) 
2. Parsing the data (using PHP script running on dub-locl) 
3. Displaying the data (using Javascript running on your browser) 

<h2>1. FETCHING THE DATA</h2>

On dub-locl.icess.ucsb.edu in /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/ there is a Python script 'fetch_calcofi_svp_data.py'.
<ul>
<li>There is essentially nothing to configure it, and it's well documented should you need to change anything. It is set to fetch via ftp from ftp.aoml.noaa.gov for the last 9 days worth of positions.

<li>It may need to be updated with drifter numbers and temperature coefficients as more are sent drifting.

<li>It is set to run about every 6 hours (05:30, 11:30, 17:30 & 20:30 Pacific, and they should post the data at 8am Eastern Time) via a "cron job" on the kirk account. To edit this job, as kirk, at the Terminal, type 'crontab -e' and use 'vi' style editing commands, or 'crontab -l' to just show it. (To become kirk, login as drift, then in a Terminal, type 'sudo su -' (then type the drift password) to become root, then 'su kirk' to become kirk.)

<li>It fetches their file, archives it (to /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/DATA_ARCHIVE/), uncompresses it, and starts the parsing script (see next section).
</ul>

<h2>2. PARSING THE DATA</h2>

This PHP script on dub-local.icess.ucsb.edu (called by the fetching script above) is /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/parse_calcofi_argos_svp_data.php and is pretty well documented. It breaks down the fairly cryptic GPS encoding and then saves it to a friendly format. It archives this file to /localhome/kirk/Scripts/CalCOFI_ARGOS_SVP_scripts_and_data/DATA_ARCHIVE/yyyymmdd_CALCOFI_SVP_LATEST_DATA.txt and copies this file to /home/kirk/public_html/drifter/realtime-SVP/CALCOFI_SVP_LATEST_DATA.txt so the website has access to it. 
 

It outputs 1 record per position report in this format: 
<pre>
drift_no,YY-MM-DD,HH:MM:SS,milliseconds_since_Jan01_1970,orig_report_num,lat,lon,position_type(1=GPS,0=ARGOS),SST(C),batt(V),base_time,record_num
</pre>
e.g.
<pre>
93561,2007-04-03,10:34:45,1175610885000,136,+26.6980,-081.9550,0,NaN,NaN,NaN,NaN (an argos position)
93561,2007-04-03,10:33:37,1175610817000,137,+26.6979,-081.9557,1,NaN,12.4,2007-04-03_11:33:30,2 (a gps position)
</pre>
<ul>
<li>There is very little configuring it, and it's well documented should you need to change anything.

</ul>
 
<h2>3. DISPLAYING THE DATA (at [http://www.icess.ucsb.edu/drifter/realtime-SVP/ realtime page] or [http://svp.drifterdata.com http://svp.drifterdata.com]) </h2>

The Google mapping code was adapted from the Iridium/Microstar realtime page at [http://www.icess.ucsb.edu/drifter/realtime/ http://www.icess.ucsb.edu/drifter/realtime/]

The two main javascript files are ajax.js and map.js. 
 
The javascript files are compressed using http://www.icess.ucsb.edu/drifter/realtime/JavascriptCompressor.html, so changes made to the xxx__UNCOMPRESSED__.js files won't show up on the page unless they are compressed and saved without the "__UNCOMPRESSED__" portion in the name, '''OR*''' at the beginning of index.php those two types of files are commented/uncommented out as appropriate. 

 
<h2> POTENTIAL PROBLEMS / TROUBLESHOOTING</h2>

Prob: The data file (/home/kirk/public_html/drifter/realtime-SVP/CALCOFI_SVP_LATEST_DATA.txt) is not getting saved/updated
<ul>
<li>Is the dub-locl computer up?
<li>Is /home/kirk/ mounted on dub-locl? (It should come up automatically)
<li>Has 6 hours passed since the last time it ran? It only runs about every 6 hours (see above), but they only update the file once per day at 8am Eastern.
<li>Try fetching the data yourself via ftp:
</ul>
<pre>
ftp://ftp.aoml.noaa.gov/phod/pub/daily_buoydata/7325/
login: anonymous
pass: e_mail
</pre>
Look for a file of today's data with the following name format:
ddMMMyy.LOG-GZ, for example: 15JUL09.LOG-GZ (i.e. for july 15th, 2009) 
 
NOTE: if you want to get data from a specific time period, use julian dates and GMT hours after the comma after 'ds'.
For example:
<pre>
prv,7325,ds,174/12-175/10,93561-93587 (for June 23rd at 12Z through June 24th at 10Z)
</pre>

Prob: The data file (/home/locl/file_sharing/SVP_CALCOFI_LATEST_DATA.txt) shows no data
<ul>
<li>There probably aren't any drifters talking in the last 24hours (look for the line "No data available or authorization failure" in the file or try manually getting the data)
</ul>

----
<h2>INFO ABOUT TIME CALCULATION</h2>
Basically each data block is for three hourly reports, and data blocks can be repeated (I
have no idea how that's determined), and there is a slight adjustment
to the time based on "fix delay" (or "Length of Acquisition", which is
usually on the order of <60 seconds). 
 
For example (showing the second to last block in the existing file as
I write this): 
<pre>
07325 93575 15 27 N 3 2009-06-25 20:18:59 34.416 240.156 0.000 401652653
2009-06-25 20:21:22 3 12 62 678 94
00 01 344156 01
1198452 01 04 689
01 344155 01 1198448
01 04 661 01
344156 01 1198448 01
04 587 00
</pre>
 
This *first line* contains ARGOS only info:
<pre>
prog_num 07325
drift_num 93575
lines_in_sat_pass 15
num_sensors 27
sat_name N
resolution 3
time 2009-06-25 20:18:59
xmit_lat 34.416
xmit_lon 240.156
xmit_alt 0.000
xmit_freq 401652653
</pre>
 
The next 7 lines contain 3, hourly GPS reports. 
 
---- Line 1: (2009-06-25 20:21:22 3 12 62 678 94) 
<pre>
BASE Date/Time 2009-06-25 20:21:22
# identical messages rcvd 3
Drogue count over last half hour 12
Battery voltage = n * 0.2 62 -> 12.4V
SST(C) = x * 0.043 - 5 678 -> 24.154
Checksum 94
</pre>
 
---- Line 2: (00 01 344156 01) 
<pre>
Msg ID 00 -> this is 1st message sent
Valid Pos #1 (1=good, 0=bad) 01 -> good
Lat #1 (ten-thousandths of degree) 344156 -> 34.4156
Lat #1 Ref (0 = South, 1 = North) 01 -> North
</pre>
 
---- Line 3: (1198452 01 04 689) 
<pre>
Lon #1 (ten-thousandths of degree) 1198452 -> 119.8452
Lon #1 Ref (0 = East, 1 = West) 01 -> West
Pos #1 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #1 (C) = x * 0.043 - 5 689 -> 24.627
</pre>
 
---- Line 4: (01 344155 01 1198448) 
<pre>
Valid Pos #2 (1=good, 0=bad) 01 -> good
Lat #2 (ten-thousandths of degree) 344155 -> 34.4155
Lat #2 Ref (0 = South, 1 = North) 01 -> North
Lon #2 (ten-thousandths of degree) 1198448 -> 119.8448
</pre>
 
---- Line 5: (01 04 661 01) 
<pre>
Lon #2 Ref (0 = East, 1 = West) 01 -> West
Pos #2 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #2 (C) = x * 0.043 - 5 661 -> 23.423
Valid Pos #3 (1=good, 0=bad) 01 -> good
</pre>
 
---- Line 6: (344156 01 1198448 01) 
<pre>
Lat #3 (ten-thousandths of degree) 344156 -> 34.4156
Lat #3 Ref (0 = South, 1 = North) 01 -> North
Lon #3 (ten-thousandths of degree) 1198448 -> 119.8448
Lon #3 Ref (0 = East, 1 = West) 01 -> West
</pre>
 
---- Line 7: (04 587 00) 
<pre>
Pos #3 Length of Acq (seconds = n * 4) 04 -> 16(seconds)
SST #3 (C) = x * 0.043 - 5 587 -> 20.241
Null bits (only for padding, ignore)
</pre>
 
 
NOTES: 
-Total bit count (a very non trivial calculation) of all 7 lines must equal the checksum value or
message block is considered garbled and thus ignored. 
 
-Times of GPS reports are calculated thusly: 
 
1) Take BASE time, subtract (Msg ID*3) [that is, if message has been
repeated, it is at least 3 hours old -- I have a switch in my code
(it's turned on for now) which will ignore messages with a message
ID>0 because the original may be also present, and it's possible the
duplicate isn't an exact duplicate and then you get slightly different
reports at similar times] 
2) Then, subtract 2 hours for Pos #3, and 1 hour for Pos #2 and 0 for Pos #1 
3) Then subtract the associated small "Length of Acq" 
 
Thus, the 2nd GPS time (i.e. #2) would be calculated thusly: 
<pre>
BASE time: 2009-06-25 20:21:22
minus 0 hours (because Msg ID is 0)
minus 1 hour (because it's Pos #2)
minus (pos #2 length of acq) 16 seconds

equals: 2009-06-25 19:21:06
</pre>
 
An additional wacky thing is that due to repetition of the messages,
or god knows what, the calculations of the reports you see aren't
necessarily in chronological order. So, after doing all the
calculations, I then sort them chronologically before outputting
(within the parse_argos_data.php script), so that when showing the
track lines, the points are in order.