to do:

1) ----------------------------------------------------------------------

summary: accretion to badbin.asc by "list" in matlab editing 
        includes bins previously flagged bad due to pgood<30
 
 
Suppose I go through an adcp cruise and do some editing,
(creating badbin.asc, etc) and apply the editing.  Now, when I go
back into the matlab editing there are white circles at the
bottom (presumably from applied editing of 30pgood cutoff).
 
These can't be graphically removed by any of the tools available,
and they are already flagged as bad bins in the editing, so
there's no need to flag them again.  BUT, if I wanted to flag a
few more bins at the top and "list" (append to badbin.asc my new
few bad bins) it includes all the white circles in the addition
to badbin.asc.  That means there can be a pretty big overhead in
badbin.asc accretion when simply touching up the data.
 
 
2) ----------------------------------------------------------------------

in $prog/codas3/adcp/demo and $prog/matlabef/*/ there are duplicate
copies of various things (control files and other home-brewed things
such as mkbadprf.m  

Q:  Which one is the original?? (for anything that is duplicated)
Q:  where does the original go, 
Q:  do we link to the originals? or only have one copy?


3) ----------------------------------------------------------------------


summary : make a newday.prl type of program that will include a basic
    sweep of editing so a very raw look at a new dataset could be 
    done without any manual editing


    specifically:

    on station only: (eliminate ctd wire interference)
        1) moderately high threshold for amplitude 
        (to NOT flag any scattering layers but still get the bottom) 
            - eg) AMP_THRESHOLD=30
        2) high WVAR_THRESHOLD so as to never flag a profile
            -  (eg. 10000) 
        3) usual value of EV_THRESHOLD (eg. 70)

    underway only: (eliminate bias in direction of travel)
        1) moderately high threshold for amplitude 
        (to NOT flag any scattering layers but still get the bottom) 
            - eg) AMP_THRESHOLD=30
        2) high WVAR_THRESHOLD so as to never flag a profile
            -  (eg. 10000) 
        3) anyting reference layer velocity is >.03*velocity in 
            u and v, flag the profile and throw it out

    all:
        *1) could flag all profiles with no good bins over 80pg 
            in reference layer (if so, use bins 4-12)
        2) run setflags to get rid of everything with <30pg.

* from JF: we have found that this is overkill on some cruises....there are
places with no bins =80  that still look like data is reasonable, even if
confidence is diminished; 

4) ----------------------------------------------------------------------
--NOT IN EVIDENCE-- (erase this message)
apparent setflags bug:  set_flags.cnt "set_range" appears to clear 
     the "glitch bit" rather than the "range bit"

5)  ----------------------------------------------------------------------

When loading transect broad band shipboard data with a time
correction, using loadtbbp, the "time_corrected" bit in the
data processing mask (as it appears with showdb, option 1)
does not get turned on.  98/04/24 
        
6) ----------------------------------------------------------------------

Transect tbbdemo: 

nav/navtime.prl
- for filename parsing currently uses 's/\/ /g'  -need to also use 's/\\/ /g'
    (i.e. deal with dos and unix paths)

- better handling of bad GPGGA messages

edit/plotpg.m
- y axis label appears to be dependent on 60bins in some way: Curt and Tarry 
    got ylabels from 1 to 10 for bin number. ... (check it out?)


7) ----------------------------------------------------------------------
codas3 cnt file comments:

1) Add a note to set_top.cnt documentation that says
    - time range must match database (get it from showdb)
    - speed_threshold is the speed ABOVE which top bins are removed 
        (i.e. a lower limit on ship speed for bad data)
    - must set speed_threshold to 0.0 to get all profiles (does have a  
        default)

2) arrdepuw.cnt (says "this file is specifically for on-station data",
    whereas it is actually for underway data) - fix it.