ME70 GPS Data for 1703RL and 1706RL

[alicebeittel]

NCEI says they are missing GPS data for 1703RL and 1706RL for ME70 data. Raw data contains GPS - follow up email sent.

[alicebeittel]

@nmfs-swfsc-ast/ast

Does anyone know if there were any GPS issues with 1703/06 RL surveys? I did not see anything noted in the survey report. NCEI says they are unable to access GPS data for 1703RL and 1706RL ME70 data. 1706RL .raw ME70 files do not have a GPS variable when opened in EV. 1703RL .raw ME70 files have a GPS variable but the cruisetrack has many red x notations for bad GPS data. Which I think is just a result of max/min acceptable gap values set in the Variable Properties for the "position GPS fixes" variable. Curious that this survey has ME70 data with a lot of bad GPS data while other surveys (2018) have little to no bad GPS data with the same max/min acceptable gap value settings. Any ideas of why this might be?

It could be that there is an issue with how the data was packaged for NCEI which is preventing them from seeing the GPS data, but figured I'd pitch this to the group for any additional thoughts. Thanks!

[alicebeittel]

[kstierhoff]

We don't routinely look at the ME70 data, so it's possible that there was a GPS input problem during that period that went unnoticed. I'm just speculating and I'll admit I'm a bit out of my depth on this one. It might be worth repackaging a small amount of data from one of the problem surveys for them to test? I'll admit I'm a bit out of my depth on this one.

[alicebeittel]

@kstierhoff That's a good idea -- I'll try re-sending a small amount. Thanks!

[ddemer]

I'm unsure why there is no GPS data in the ME70 data from 1706. Although we haven't been analyzing these data, at least routinely, we usually ensure that the data are being collected properly. If EV does not find the GPS data, try EchoCheck.

In Echoview, "bad" GPS data can occur if the data rate is high and the precision is low, which causes large apparent speed between fixes. Try increasing the maximum allowable speed. If this reduces the number of "bad" fixes, check both the data rate and the number of significant digits in the longitude and latitude compared to data from other surveys that do not have this problem.

[kstierhoff]

@ddemer's comment about nav precision reminded me that around that time, the precision of SCS data in 2017 was set to 2 decimals:

I noticed this by the jagged vessel paths when creating the survey report that year:

This could be one issue with those ME70 data. The precision was adjusted by the ST (Jaclyn) in spring 2018, so the problem should have been solved prior to the summer 2018 survey and beyond.

[alicebeittel]

Thanks @ddemer @kstierhoff. I ran select files form both 1706 and 1703 through EchoCheck (great tool!).

Good to know Kevin! That could explain the bad data issue for 1703. Since 1703 has GPS data, I've repackaged a sample set of data and resent it to NCEI + let them know of the large apparent speed (maybe they have a similar setting that needs to be adjusted...not sure how they are looking at the GPS data). Once I increased the max apparent speed to 26 kts in EV, the "bad" GPS labels reduced to 1. Would the low precision have an impact on the usability of this data for others? I would guess it is precise enough to be informative and depends on someone's analysis goal. I see only two decimals for the 1703 data and longer numbers for 1807 data in Echocheck (There are also ~2x as many datagrams for a select 1703 file compared to a 1807 file with no "bad" GPS labels (variable properties the same and files are of similar size). That all checks out.

In addition to that issue, it looks like 1706 must have dropped receiving GPS data during the survey since earlier files have many GPS points but ones later (1706RL_ME70-D20170627-T083725.raw) only have one lat/long position at the beginning of the file. They should have more given the number of pings/file size for those files.

[alicebeittel]

@jrenfree @kstierhoff Do either of you know if there is another set of GPS data during 1706 I could send to NCEI to supplement the ME70 data set? I do see we have the SCS files -- can I use one of these for the nav data? If so, which one?

It looks like ME70 on 1706RL must have stopped receiving GPS data during the survey since earlier files have many GPS points but ones later (1706RL_ME70-D20170627-T083725.raw) only have one lat/long position at the beginning of the file. They should have more given the number of pings/file size for those files.

Thanks!!

[kstierhoff]

Hi Alice, You could extract the Lasker underway meteorological data from ERDDAP here, after filtering for the survey period: https://coastwatch.pfeg.noaa.gov/erddap/tabledap/fsuNoaaShipWTEG.html

For example, the URL below will give you a CSV from 7/1-10/1/2017: https://coastwatch.pfeg.noaa.gov/erddap/tabledap/fsuNoaaShipWTEG.htmlTable?ID%2Csite%2CIMO%2Ccruise_id%2Cexpocode%2Cfacility%2Cplatform%2Cplatform_version%2Ctime%2Clatitude%2Clongitude%2CairPressure%2CairTemperature%2Cconductivity%2CrelativeHumidity%2Csalinity%2CseaTemperature%2CwindDirection%2CwindSpeed%2CplatformCourse%2CplatformHeading%2CplatformSpeed%2CplatformWindDirection%2CplatformWindSpeed%2Cflag&time%3E=2017-07-01T23%3A59%3A00Z&time%3C=2017-10-01T23%3A59%3A00Z&flag=~%22ZZZ.*%22

By changing htmlTable? to csv? in the first line, you can generate a CSV. You can also adjust the date range in the last line to the specific dates of the survey, in case that date range overlaps other surveys.

[alicebeittel]

Thanks @kstierhoff, I downloaded what I needed and will send over to NCEI.