Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Acquired spectrum has bad date #86

Closed
christophkern opened this issue Jul 11, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@christophkern
Copy link

commented Jul 11, 2018

Every so often, a spectrum is saved with a bad date. Usually, only one such spectrum is written, and the following one is fine again.
In my example measurement, all spectra are good up to 436. Spectrum 437 has a bad date in the STD file. Spectrum 438 is fine again.
This issue has occurred several times now - perhaps a bad GPS point? But strange that it always seems to be just one spectrum that is affected, not several in a row.
The attached std spectra have been renamed to *.txt in order to allow uploading to github.

00436_0.STD.txt

00437_0.STD.txt

00438_0.STD.txt

@dnorgaard-usgs dnorgaard-usgs self-assigned this Jul 19, 2018

@dnorgaard-usgs dnorgaard-usgs added the bug label Jul 19, 2018

dnorgaard-usgs added a commit to dnorgaard-usgs/MobileDOAS that referenced this issue Jul 19, 2018

@dnorgaard-usgs

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2018

The code was modified to read the date from GPS as an int instead of string. This simplifies the code quite a bit. It is also more consistent with how the time is read (into a long), and there have not been any reported cases of bad time in the STD files (to my knowledge). In theory, non-alphanumeric characters would not parse into int and would not get read into the date field. So far the date is writing as before, but since this error does not occur often and cannot be reproduced, it cannot be said for certain this fixes this bug.

The date appears to be used only in the spectrum files.

@dnorgaard-usgs

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2018

Will reopen if problem persist.

@dnorgaard-usgs

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2019

The potential fix previously submitted causes a serious bug in that the date can be improperly decoded for writing into STD files if a potential 5 digit integer date (e.g. 20219) is not padded with zero first. It could be that the data can be read as int still from GPS but care must be taken to store in string as 6 characters. For now I am just going to revert this change.

dnorgaard-usgs added a commit that referenced this issue Feb 2, 2019

Merge pull request #108 from dnorgaard-usgs/master
mostly for #101 but also to revert #86
@dnorgaard-usgs

This comment has been minimized.

Copy link
Contributor

commented Feb 4, 2019

Mattias has a fix that will check the checksum of the GPS data to ensure we don't get garbage date from GPS.

@dnorgaard-usgs

This comment has been minimized.

Copy link
Contributor

commented Feb 6, 2019

Mattias committed some code changes yesterday that read the date as long and convert to 6 character string. (Along with some other improvements surrounding the handling of date.) This should, in theory, fix this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.