gnsstk: Todo List

Make sure this document is up to date and maybe add a sequence diagram.

Member BDSD1NavTimeOffset_T::getOffsetTest ()

Truth values here need to be verified.

Member BDSD2NavTimeOffset_T::getOffsetTest ()

Truth values here need to be verified.

JMK says: I looked at the subframe 4 pg 18 data on line 251 (look for subframe456) and broke out the bits by hand. The WNlsf was 766, and that's what the code is returning. I honestly have no idea what this expression here is supposed to be, but I'm keeping it in case someone else wants to have a go at it: int(851/256)*256 + 254

Member FileSpec_T::testFileSpecTypeOps ()

implement testFileSpecTypeOps

Member FileSpec_T::testInitValid ()

implement %% in FileSpec

implement precision support in FileSpec

Member FileSpec_T::testSortList ()

should we make it a requirement that the length is specified, and throw an exception if it isn't?

Member FileSpec_T::testToString ()

test all spec tokens to uncover any conflicts

implement precision support in FileSpec

Member GalFNavTimeOffset_T::getOffsetTest ()

Truth values here need to be verified.

Member GalFNavTimeOffset_T::validateTest ()

determine what ranges are valid for Galileo

Member GalINavTimeOffset_T::getOffsetTest ()

Truth values here need to be verified.

Member GalINavTimeOffset_T::validateTest ()

determine what ranges are valid for Galileo

Member GLOCNavAlm_T::validateTest ()

Implement some testing when the function has some meat to it.

Member GLOCNavEph_T::getXvtLTTest ()

The epsilon commented out is what the above comment refers to. The epsilon being used is a kludge because the results aren't entirely right. IOW this should be investigated and fixed at some point.

Member GLOCNavEph_T::getXvtSimpleTest ()

The epsilon commented out is what the above comment refers to. The epsilon being used is a kludge because the results aren't entirely right. IOW this should be investigated and fixed at some point.

Member GLOCNavEph_T::validateTest ()

add more reasonable tests when GLOCNavEph has some validation

Member GLOCNavUT1TimeOffset_T::getOffsetTest ()

Truth values here need to be verified.

Member GLOCNavUT1TimeOffset_T::validateTest ()

Implement some testing when the function has some meat to it.

Member GLOFNavAlm_T::validateTest ()

Implement some testing when the function has some meat to it.

Member GLOFNavData_T::validateTest ()

Implement some testing when the function has some meat to it.

Member GLOFNavEph_T::validateTest ()

Implement some testing when the function has some meat to it.

Member GLOFNavISC_T::validateTest ()

Implement some testing when the function has some meat to it.

Member GLOFNavTimeOffset_T::getOffsetTest ()

Truth values here need to be verified.

Member GLOFNavTimeOffset_T::validateTest ()

Implement some testing when the function has some meat to it.

Member GLOFNavUT1TimeOffset_T::getOffsetTest ()

Truth values here need to be verified.

Member GLOFNavUT1TimeOffset_T::validateTest ()

Implement some testing when the function has some meat to it.

Namespace gnsstk

Get rid of the stdio.h dependency if possible.

Member gnsstk::BDSD1NavAlm::validate () const override

implement some checking.

Member gnsstk::BDSD1NavEph::fixFit ()

Determine if this is an appropriate adjustment

Member gnsstk::BDSD1NavEph::validate () const override

implement some checking.

Member gnsstk::BDSD1NavHealth::getHealth () const override

Determine if this is reasonable. It appears as though the reserved health bits can sometimes be non-zero even if other explicitly defined bits are not, and also different signals can be set unhealthy. So if we have health data that is tagged as B1I that says B3I is unhealthy, do we indicate that we're unhealthy? Compare that to GPS LNAV which defines health bits in a similar fashion (different bits indicate health on different signals), but it's not really used that way - typically either all bits are set or cleared. As such, we need to clarify user expectations as much as anything.

Member gnsstk::BDSD1NavISC::validate () const override

implement some checks.

Member gnsstk::BDSD2NavAlm::validate () const override

implement some checking.

Member gnsstk::BDSD2NavEph::fixFit ()

Determine if this is an appropriate adjustment

Member gnsstk::BDSD2NavEph::validate () const override

implement some checking.

Member gnsstk::BDSD2NavHealth::getHealth () const override

Member gnsstk::BDSD2NavISC::validate () const override

implement some checks.

Member gnsstk::BinexData::UBNXI::read (std::istream &strm, std::string *outBuffer=NULL, size_t offset=0, bool reverseBytes=false, bool littleEndian=false)

Member gnsstk::Cholesky< T >::operator() (const ConstMatrixBase< T, BaseClass > &m)

potential complex number problem!

Member gnsstk::CommandOptionParser::displayUsageDoxygen (std::ostream &out)

add smarts to the synopsis section generation that handles the Mutex and other similar meta-options so the generated synopsis doesn't produce option sets that won't work

is this really correct in all cases? Probably not.

Member gnsstk::EngEphemeris::getTot () const

Determine if this function is needed, as it is never used

Class gnsstk::EphTime

Make this class inherit from TimeTag like all the others.

Class gnsstk::Epoch

Fix these comments.

Member gnsstk::Epoch::NEW_EXCEPTION_CLASS (EpochException, gnsstk::Exception)

Do we need this, or can we get by with InvaildRequest and/or InvalidParameter?

Member gnsstk::Epoch::scanf (const std::string &str, const std::string &fmt)

Someone figure out how to make the table below show up nice in doxygen.

Member gnsstk::Epoch::set (const TimeTag &tt=SystemTime())

Could we get away with just CommonTime sets? The TimeTags can convert themselves to CommonTime objects. That's what we do internally anyway...

Member gnsstk::Epoch::setLocalTime ()

What is this?

Member gnsstk::FactoryControl::timeOffsFilt

Determine if RinexTimeOffset or GLOFNavUT1TimeOffset can be refactored so they derive from StdNavTimeOffset, or at the very least can/should be filtered via TimeOffsetUnique in NavDataFactoryWithStore.

Member gnsstk::GalFNavAlm::fixFit ()

set the fit interval correctly

Member gnsstk::GalFNavAlm::validate () const override

implement some checking.

Member gnsstk::GalFNavEph::dumpSVStatus (std::ostream &s) const override

We're currently printing the transmit time of the subframes, which may be different from the TOW value that's in the page. A quick comparison between the earlier implementation's output and the current implementation's output show that the values being dumped are the same. Not sure if we're consistently mislabeling or if the TOW really is the same as the transmit time we're printing.

Member gnsstk::GalFNavEph::validate () const override

implement some checking.

Member gnsstk::GalFNavHealth::GalFNavHealth ()

Figure out a way to initialize sisaIndex such that not having the value doesn't result in the health status being tagged as Degraded.

Member gnsstk::GalFNavIono::validate () const override

implement some checking.

Member gnsstk::GalFNavISC::validate () const override

implement some checks.

Member gnsstk::GalFNavTimeOffset::validate () const override

determine what ranges are valid for Galileo.

Member gnsstk::GalINavAlm::fixFit ()

set the fit interval correctly

Member gnsstk::GalINavAlm::fixHealth ()

determine if this educated guess about health status is correct or at least reasonable.

Member gnsstk::GalINavAlm::validate () const override

implement some checking.

Member gnsstk::GalINavEph::validate () const override

implement some checking.

Member gnsstk::GalINavHealth::GalINavHealth ()

Figure out a way to initialize sisaIndex such that not having the value doesn't result in the health status being tagged as Degraded.

Member gnsstk::GalINavIono::validate () const override

implement some checking.

Member gnsstk::GalINavISC::validate () const override

implement some checks.

Member gnsstk::GalINavTimeOffset::validate () const override

determine what ranges are valid for Galileo.

Class gnsstk::GenericNavFilterData

in the long term it might be preferable to put this functionality into NavFilterKey and eliminate this class, but that would require redoing the existing filters to reflect the more abstract implementation using getBits.

Member gnsstk::getRefFrameRlz (RefFrameSys sys, const CommonTime &when)

fix these dates up, I wasn't able to quickly find actual publication dates.

Member gnsstk::glo::fnbMB

Is this right?

Member gnsstk::GLOCNavAlm::fixFit ()

get a better end fit interval than this.

Member gnsstk::GLOCNavAlm::getXvt (const CommonTime &when, Xvt &xvt, const ObsID &=ObsID()) override

Add some sanity checks later.

Member gnsstk::GLOCNavAlm::iav

These constants are defined in the individual ICDs for each signal. They're currently taken from the L3 ICD as I don't have any L1 or L2 data. As such, they may need to change to signal-dependent in the future.

Member gnsstk::GLOCNavAlm::validate () const override

implement some checking.

Member gnsstk::GLOCNavEph::apcOffset

implement support for this, see ICD-GLONASS-CDMA General Edition Appendix J, and weep.

Member gnsstk::GLOCNavEph::derivative (const Vector< double > &inState, const Vector< double > &accel, const Vector< double > &lt, bool simplified) const

figure out a reasonable way to handle the fact that FDMA nav uses a less precise value for omega_e. Maybe a different PZ90Ellipsoid class?

Member gnsstk::GLOCNavIono::getIonoCorr (const CommonTime &when, const Position &rxgeo, const Position &svgeo, CarrierBand band) const override

implement this

Member gnsstk::GLOCNavIono::validate () const override

Implement some validation.

Member gnsstk::GLOCNavUT1TimeOffset::validate () const override

add some checks.

Member gnsstk::GLOFNavAlm::fixFit ()

Document correct predconditions here.

get a better end fit interval than this.

Member gnsstk::GLOFNavAlm::validate () const override

implement some checking.

Member gnsstk::GLOFNavData::validate () const override

implement some checking.

Member gnsstk::GLOFNavEph::validate () const override

implement some checking.

Member gnsstk::GLOFNavISC::getISC (const ObsID &oid1, const ObsID &oid2, double &corrOut) const override

I'm not sure if I have this polarity right. dtau_n=t_f2-t_f1.

Member gnsstk::GLOFNavISC::validate () const override

implement some checking.

Member gnsstk::GLOFNavTimeOffset::validate () const override

add some checks.

Member gnsstk::GLOFNavUT1TimeOffset::validate () const override

add some checks.

Class gnsstk::GNSSTKFormatInitializer

Resolve the memory leak caused by the constructor here.

Member gnsstk::GPSCNav2Alm::fixFit ()

Determine a more reasonable set of values. This was copied from OrbAlmExt.

Member gnsstk::GPSCNav2Alm::validate () const override

implement some checking.

implement some checks.

Member gnsstk::GPSCNav2Eph::fixFit ()

replace all these magic numbers with named constants or enums, with sensible names, not "NINTY_MINUTES" [sic]

Member gnsstk::GPSCNav2Eph::validate () const override

implement some checking.

implement some checks.

Member gnsstk::GPSCNav2ISC::haveSF2

deal with the fact that there are two subframes in this, i.e. implement a proper getUserTime() method

Member gnsstk::GPSCNav2ISC::validate () const override

implement some checks.

Member gnsstk::GPSCNavAlm::fixFit ()

Determine a more reasonable set of values. This was copied from OrbAlmExt.

Member gnsstk::GPSCNavAlm::validate () const override

implement some checking.

Member gnsstk::GPSCNavEph::fixFit ()

replace all these magic numbers with named constants or enums, with sensible names, not "NINTY_MINUTES" [sic]

Member gnsstk::GPSCNavEph::validate () const override

implement some checking.

Member gnsstk::GPSCNavRedAlm::validate () const override

implement some checking.

Member gnsstk::gpslnav::AlmBitInfo

Add enumerations for almanac data bits.

Member gnsstk::GPSLNavAlm::validate () const override

implement some checking.

Member gnsstk::GPSLNavData::refioffsetQZSS

figure out when to use QZO iref and when to use GEO. According to table 3.2.1-1 the PRN assignments are mostly defined, but PRN 198 and 202 are in satellite category "QZO/GEO" so it's not 100% clear.

Member gnsstk::GPSLNavEph::validate () const override

implement some checking.

Member gnsstk::IonexStore::ionoMappingFunction (double elevation, const std::string &ionoMapType) const

Implement ESM support in IonexStore

Implement something for the ionoMapType "NONE" case

Member gnsstk::IonoCorr::GPSB

add support for remaining systems in RINEX 3.04

Member gnsstk::isValidRinexObsID (const std::string &strID)

determine if this really belongs with the RINEX files

Member gnsstk::KlobucharIonoNavData::validate () const override

implement some checking.

Member gnsstk::LNavAlmValFilter::checkAlmValRange (LNavFilterData *fd)

implement this

Member gnsstk::mixedScanTime (CommonTime &t, const string &str, const string &fmt)

use a more appropriate exception class

Class gnsstk::NavDataFactoryWithStore

Currently it's possible for health messages from one signal to stomp health messages on another signal. Specific example: if you have a CNAV message with the three signal health bits that get split up into L1, L2 and L5, it's possible for the L1 signal from the CNAV message to overwrite the health status from an LNAV message for L1 and vice versa. Since it's possible for the health bits to be different, we probably need to decide if we need to do something about this issue and if so, what.

Member gnsstk::NavDataFactoryWithStore::dump (std::ostream &s, DumpDetail dl) const override

To support the variances between nav codes Terse dump formats, it would probably be best to implement a "getTerseHeader" method and just call it for the first object in this map (which should be the same class for each item in nsami.second).

Member gnsstk::NavDataFactoryWithStore::matchHealth (NavData *ndp, SVHealth xmitHealth)

This next statement kind of sort of enforces ephemeris health however it's possible, for example in GPS LNAV to have almanac pages with the transmit and subject satellites the same, making it effectively indistinguishible from ephemeris health. Are there situations where that could yield incorrect results?

Member gnsstk::NavLibrary::getIonoCorr (const SatID &sat, const CommonTime &when, const Position &rxgeo, CarrierBand band, double &corrOut, NavType nt=NavType::Any, int freqOffs=0, bool freqOffsWild=true)

Update the ObsID constructor to include freqOffs data

Member gnsstk::NavLibrary::getISCNMID (const SatID &sat, const ObsID &oid)

Add support for other GNSSes to getISCNMID.

Member gnsstk::NavMsgDataPNB::dump (std::ostream &s, unsigned totalBits) const override

eventually we'll likely want to make this a bit more configurable. This applies to GPS and BeiDou at the very least, but probably not GLONASS. Configuration shouldn't involve the use of variables in this class if it can be avoided, since there can be a large number of these objects when processing data. It would be better to figure out a way to make the nav code-specific derived classes set the configuration somehow via methods or static data or some such.

Member gnsstk::NeQuickIonoNavData::ModelParameters::ModelParameters (double modip_u, const Position &pos, double az, CCIR &ccirData, const CivilTime &when)

figure out what is meant by "too close to foF2" in eq.37

Member gnsstk::NeQuickIonoNavData::validate () const override

implement some checking.

Member gnsstk::NEW_EXCEPTION_CLASS (GeometryException, gnsstk::Exception)

determine if this file should be moved into GNSSCore

Member gnsstk::NewNavToRinex::fillDataGalFNav (const NavDataPtr &ndp, Rinex3NavData &rnd, HealthGetter &healthGet)

figure out how best to get BGD E5b/E1 which is not in the F/NAV ephemeris.

Member gnsstk::OrbitDataSP3::validate () const override

Determine and implement validity criteria.

Member gnsstk::ord::getSvXvt (const gnsstk::SatID &satId, const gnsstk::CommonTime &time, NavLibrary &ephemeris)

getXvt was expected to throw an exception on failure in the past. This assert more or less mimics that behavior. Refactoring is needed.

Member gnsstk::PNBBDSD1NavDataFactory::addData (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut, double cadence=-1) override

Implement a parity check

Member gnsstk::PNBBDSD1NavDataFactory::finishAlm (AlmPtr &alm, bool fromWNa, const NavSatelliteID &key, NavDataPtrList &navOut)

see comment in BDSD1NavHealth::getHealth()

Member gnsstk::PNBBDSD1NavDataFactory::processSF5Pg9 (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

figure out what the reference time is supposed to be, which is not a high priority as the ICD itself says "Not broadcast temporarily".

Member gnsstk::PNBBDSD2NavDataFactory::addData (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut, double cadence=-1) override

Implement a parity check

Member gnsstk::PNBBDSD2NavDataFactory::finishAlm (AlmPtr &alm, bool fromWNa, const NavSatelliteID &key, NavDataPtrList &navOut)

see comment in BDSD2NavHealth::getHealth()

Member gnsstk::PNBBDSD2NavDataFactory::processSF5Pg101 (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

figure out what the reference time is supposed to be, which is not a high priority as the ICD itself says "Not broadcast temporarily".

Member gnsstk::PNBGalFNavDataFactory::addData (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut, double cadence=-1) override

implement validity checks if there are any.

Member gnsstk::PNBGalFNavDataFactory::processAlmOrb (const std::vector< PackedNavBitsPtr > &almPage, GalFNavAlm *alm, GalFNavHealth *hp1, int ptA, int ptB, int asiSVID, int asbSVID, int asidAhalf, int asbdAhalf, int asiEcc, int asbEcc, int asiw, int asbw, int asidi, int asbdi, int asiOMEGAdot, int asbOMEGAdot, int asiM0, int asbM0, int asiaf0, int asbaf0, int asiaf1, int asbaf1, int asiE5ahs, int asbE5ahs)

figure out what DVS and SISA should be here.

Member gnsstk::PNBGalINavDataFactory::addData (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut, double cadence=-1) override

implement validity checks if there are any.

Member gnsstk::PNBGalINavDataFactory::processAlm (unsigned wordType, const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

Matthew Koenn suggested effectively caching results for almAcc look-ups. Probably can't take the time to dig into it right now, but wanted to leave a reference to the comment here. https://sgl-git.arlut.utexas.edu/sgl-tks/gnsstk/-/merge_requests/523#note_524670

Member gnsstk::PNBGalINavDataFactory::processAlmOrb (const std::vector< PackedNavBitsPtr > &almWord, GalINavAlm *alm, GalINavHealth *hp1, GalINavHealth *hp2, int wtA, int wtB, int asiWNa, int asit0a, int asiSVID, int asbSVID, int asidAhalf, int asbdAhalf, int asiEcc, int asbEcc, int asiw, int asbw, int asidi, int asbdi, int asiOMEGA0, int asbOMEGA0, int asiOMEGAdot, int asbOMEGAdot, int asiM0, int asbM0, int asiaf0, int asbaf0, int asiaf1, int asbaf1, int asiE5bhs, int asbE5bhs, int asiE1Bhs, int asbE1Bhs)

figure out what DVS and SISA should be here.

Member gnsstk::PNBGalINavDataFactory::processEph (unsigned wordType, const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

Word type 5 is not officially part of the ephemeris and doesn't contain an IODnav field, so how do we make sure that our word type 5 is usable with the ephemeris?

Member gnsstk::PNBGLOCNavDataFactory::addData (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut, double cadence=-1) override

implement CRC check

Member gnsstk::PNBGLOCNavDataFactory::processEph (unsigned long stringID, const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

Not sure if this is signed or not but it seems likely.

Member gnsstk::PNBGLOFNavDataFactory::addData (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut, double cadence=-1) override

Implement a parity check, if there is any.

Member gnsstk::PNBGLOFNavDataFactory::processAlm (unsigned long stringID, const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

Should we process the transmit satellite health here?

Member gnsstk::PNBGLOFNavDataFactory::processEph (unsigned long stringID, const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

Maybe make it so we can still get the health w/o strings 1&4

I think reference time is referenced to the start of the transmit day, but is that true?

Member gnsstk::PNBGLOFNavDataFactory::processTimeUT1 (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

determine if this data is only in GLONASS-M

Member gnsstk::PNBGPSCNav2DataFactory::processAlmOrb (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut, unsigned offset=0)

I'm not entirely sure what's appropriate here. The source signal is actually L1C CNAV2 but it's broadcasting signal status for L2 signals that don't have CNAV2.

apply 13-bit week rollover adjustment, not 10-bit. Must be completed by January, 2137 :-)

GEO QZSS satellites use a different i0 reference, but I have yet to figure out how to determine if a QZSS satellite is GEO or QZO

Member gnsstk::PNBGPSCNav2DataFactory::processEph (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut, unsigned offset=0)

apply 13-bit week rollover adjustment, not 10-bit. Must be completed by January, 2137 :-)

Member gnsstk::PNBGPSCNavDataFactory::processAlmOrb (unsigned msgType, const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

I'm not entirely sure what's appropriate here. The source signal is actually L2C CNAV but it's broadcasting signal status for L1 signals that don't have CNAV.

apply 13-bit week rollover adjustment, not 10-bit. Must be completed by January, 2137 :-)

Member gnsstk::PNBGPSCNavDataFactory::processEph (unsigned msgType, const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

Should we ignore the PNB satellite ID and just use the PRN in the nav message, or maybe compare the two as an validity check?

Is this strictly relevant for ephemeris assembly? Seems like if these are rebroadcast messages they're not going to correspond to the ephemeris data being broadcast by QZSS.

I'm not entirely sure what's appropriate here. The source signal is actually L2C CNAV but it's broadcasting signal status for L1 signals that don't have CNAV.

apply 13-bit week rollover adjustment, not 10-bit. Must be completed by January, 2137 :-)

GEO QZSS satellites use a different OMEGAdot reference, but I have yet to figure out how to determine if a QZSS satellite is GEO or QZO

Member gnsstk::PNBGPSCNavDataFactory::processRedAlmOrb (unsigned msgType, unsigned offset, unsigned pre, bool alert, unsigned wna, double toa, const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

I'm not entirely sure what's appropriate here. The source signal is actually L2C CNAV but it's broadcasting signal status for L1 signals that don't have CNAV.

apply 13-bit week rollover adjustment, not 10-bit. Must be completed by January, 2137 :-)

Class gnsstk::PNBGPSLNavDataFactory

Currently this code enforces strict matching of toa between SVID 1-32 and 51. While this helps ensure that the time stamp of the almanac orbital elements has the correct week number, it does mean that if you're missing the page 51 for a particular toa, you won't get those almanacs. This is probably not ideal and likely needs to be enhanced without significantly increasing the risk of using an incorrect WNa.

Member gnsstk::PNBGPSLNavDataFactory::addData (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut, double cadence=-1) override

maybe someday add a parity check to PackedNavBits

Are the nav subframes really known to be upright?

support GPS PRNs 33+ (IS-GPS-200 40.1, appendix IV)

Member gnsstk::PNBGPSLNavDataFactory::processAlmOrb (unsigned long prn, const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

determine if this offset applies only when the subject satellite is QZSS or if it is used whenever the transmitting satellite is QZSS.

Member gnsstk::PNBGPSLNavDataFactory::processSVID51 (const PackedNavBitsPtr &navIn, NavDataPtrList &navOut)

Should we be generating health objects for both PRN 196 and 203, for example? It's not entirely clear from the table if the PRN should be 196 for L1 C/A and 203 for L1 C/B, or if the health status applies to both at the same time.

Member gnsstk::Position::copyEllipsoidModelFrom (const Position &src)

Modify Position to store a shared_ptr<EllipsoidModel> instead of AEarth, eccSquared etc.

Member gnsstk::PRSolution::PreparePRSolution (const CommonTime &Tr, std::vector< SatID > &Sats, const std::vector< double > &Pseudorange, NavLibrary &eph, Matrix< double > &SVP, NavSearchOrder order=NavSearchOrder::User) const

getXvt was expected to throw an exception on failure in the past. This assert more or less mimics that behavior. Refactoring is needed.

Member gnsstk::Rinex3ClockHeader::reallyGetRecord (FFStream &s)

how to check numSolnSatsValid == satList.size() ?

Member gnsstk::Rinex3NavHeader::compare (const Rinex3NavHeader &right, std::vector< std::string > &diffs, const std::vector< std::string > &inclExclList, bool incl=false)

compare stringCorrSysTime... not clear how to do this since the exact same data structure is used to store stuff from TimeSysCorr and CorrSysTime.

Member gnsstk::Rinex3ObsData::setObs (const RinexDatum &data, const RinexSatID &svID, const RinexObsID &obsID, const Rinex3ObsHeader &hdr)

If the existing channel data is greater than or equal to this number, we have stuffed the maximum number of channels into the field. I don't really know what to do in the event that we exceed this limit.

Member gnsstk::Rinex3ObsHeader::ObsIDMap

document me

Member gnsstk::Rinex3ObsHeader::prepareVer2Write (void)

unset R3-specific header members?

Member gnsstk::Rinex3ObsHeader::VersionObsMap

document me

Member gnsstk::RinexNavDataFactory::convertToHealth (const Rinex3NavData &navIn, NavDataPtrList &healthOut)

add other GNSSes

Member gnsstk::RinexNavDataFactory::convertToIono (const CommonTime &when, const Rinex3NavHeader &navIn, NavDataPtrList &navOut)

We don't know whether the iono data came from I/NAV or F/NAV so I just arbitrarily chose to store it as I/NAV. Probably the best thing to do would be to update the find() method in the future so that it hides all of these assumptions from the user.

Member gnsstk::RinexNavDataFactory::convertToOffset (const Rinex3NavHeader &navIn, NavDataPtrList &navOut)

add support for delta t LSF in RINEX 3 (leapDelta, leapWeek, leapDay in Rinex3NavHeader).

Member gnsstk::RinexNavDataFactory::convertToOrbit (const Rinex3NavData &navIn, NavDataPtr &navOut)

set sv health correctly

add other GNSSes

Member gnsstk::RinexNavDataFactory::fillNavData (const Rinex3NavData &navIn, NavDataPtr &navOut)

figure out how to handle the case where Bit 0 and 2 are both set (see table A8).

add other GNSSes

Member gnsstk::RinexNavDataFactory::fixTimeBeiDou (const Rinex3NavData &navIn, OrbitDataKepler &navOut)

Probably need to do half week tests on the transmit time

Member gnsstk::RinexNavDataFactory::fixTimeGalileo (const Rinex3NavData &navIn, OrbitDataKepler &navOut)

Probably need to do half week tests on the transmit time

Member gnsstk::RinexNavDataFactory::process (const std::string &filename, NavDataFactoryCallback &cb) override

what about embedded RINEX headers?

Member gnsstk::RinexObsID::rinexVersion

move this into RinexObsID along with all the other RINEX-specific code at some point.

Class gnsstk::RinexSatID

determine if this really belongs with the RINEX files

Member gnsstk::RinexTimeOffset::getUserTime () const override

figure out a sensible value, if there is one.

Member gnsstk::RinexTimeOffset::validate () const override

implement some validation

Class gnsstk::SatID

Update the above table for the proper nomenclature for identification.

Member gnsstk::Sinex::Data::reallyGetRecord (FFStream &s)

- Store

Member gnsstk::Sinex::Data::reallyPutRecord (FFStream &s) const

- Put block comment

Member gnsstk::SP3NavDataFactory::convertToOrbit (const SP3Header &head, const SP3Data &navIn, bool isC, NavDataPtr &navOut)

the ::pow statement was pulled from SP3EphemerisStore. I'm not 100% sure it's possible to get sigma this way. We should determine if it is possible and if so write tests for this case. Look for all uses of isC and correlationFlag.

Member gnsstk::SP3NavDataFactory::find (const NavMessageID &nmid, const CommonTime &when, NavDataPtr &navOut, SVHealth xmitHealth, NavValidityType valid, NavSearchOrder order) override

If someone attempts to use SP3 but sets the type filter to exclude clock, no clock data will be stored and this will end up returning false. I'm not sure if this is valid behavior.

Member gnsstk::SP3NavDataFactory::interpolateClk (const NavMap::iterator &ti1, const NavMap::iterator &ti3, const CommonTime &when, NavDataPtr &navData)

this doesn't look right to me because it seems like it should be biasSigData[Nhi]-biasSigData[low] but this is how it is in SP3EphemerisStore.

Member gnsstk::SP3NavDataFactory::setSignal (const SatID &sat, NavMessageID &signal)

What do we do with non-standard antennas?

GLONASS frequency offset should be set to something, but what?

add more systems as needed.

Class gnsstk::SP3SatID

determine if this really belongs with the SP3 files

Member gnsstk::StdNavTimeOffset::dump (std::ostream &s, DumpDetail dl) const override

maybe need to make this a dynamic label for systems that start at DN=0

Member gnsstk::StringUtils::x2d (std::string &s)

detecting 0 isn't quite right...

Member gnsstk::StringUtils::x2uint (const std::string &s)

Need to find a way to combine this with x2d.

Member gnsstk::TransformLibrary::TransformLibrary ()

correct?

Member GPSCNav2Eph_T::validateTest ()

implement some tests when we implement validate()

Member GPSCNav2TimeOffset_T::getOffsetTest ()

Truth values here need to be verified.

Member GPSCNavTimeOffset_T::getOffsetTest ()

Truth values here need to be verified.

Member GPSLNavEph_T::fixFitTest ()

When using navdmp, it indicated the begin valid time was 597600 SOW. The fixFit() method, which was taken from OrbElemRinex::computeBeginValid, does not make this 2-hour boundary adjustment when the Toe isn't already aligned on 2-hour boundaries. So for now we use 603360 SOW for the test, since that matches expected behavior for this code.

Member GPSLNavTimeOffset_T::getOffsetTest ()

Truth values here need to be verified.

Member main ()

test edit(), clear()

Member NavDataFactoryWithStore_T::findNearestTest ()

add tests for findNearest using Almanac data and maybe Health.

Page Navigation Message Library

Update the ObsID stuff to match the decision about using freqOffset in the table above.

try to fix the NavType links above.

Determine if a URA in meters should be added to OrbitDataKepler or OrbitData.

Member PNBBDSD1NavDataFactory_T::addDataValidityTest ()

implement some tests after we have parity checking and such.

Member PNBBDSD1NavDataFactory_T::processSF5Pg24Test ()

test with AmID=b10 and b11

Member PNBBDSD2NavDataFactory_T::addDataValidityTest ()

implement some tests after we have parity checking and such.

Member PNBGalINavDataFactory_T::processEphTest ()

while our assertions are the same for both signals, that's not a guarantee, operationally. Probably should add a test where the health status is different between E5b and E1B.

Member PNBGLOCNavDataFactory_T::processEphTest ()