Duplicate data records in generated RINEX files

[johansen]

When the RTCM data contains GPS and Glonass data, data records are output both when receiving the 1004 GPS message and the 1012 Glonass message. Observed in NO_RTCM3_MAIN mode with RINEX v. 2.

A patch is attached to output a data record only after receiving the last RTCM message for an epoch.

[stoecker]

Do you have an example datastream for this behaviour?

[johansen]

Sample data

[johansen]

I have attached a zip archive containing containing RTCM sample data and corresponding RINEX files processed with and without the patch.

[stoecker]

I don't see this happen with rtcm3torinex. I think your "makerinex" software does wrong interfacing to the routines not interpreting the partial return states.

P.S. The name "makerinex" is already taken by our companys rinex converter since November 2000 (e.g. used in BKG RINEX files). I would suggest to use another name.

[johansen]

I had a look at the source code and found that this happens only when NO_RTCM3_MAIN is defined, so it would not affect rtcm3torinex.

makerinex (or whatever we should name it) defines NO_RTCM3_MAIN and calls HandleByte() for each input byte. HandleByte() handles ephemeris if RTCM3Parser() returns 1019 or 1020, else it outputs data records.

With NO_RTCM_MAIN undefined, RTCM3Parser() returns 1019 or 1020 after decoding ephemeris, it returns 1 or 2 after decoding all data records for an epoch (!syncf) and has no other non-zero return values.

With NO_RTCM_MAIN defined, RTCM3Parser() also returns 1005, 1006, 1013 etc. after decoding "header"-type records and 1004, 1012 etc. after decoding incomplete data for an epoch (syncf). These return values go into the "else" clause in HandleByte() and cause bogus RINEX data records.

By calling RTCM3Parser() directly instead of calling HandleByte() we could check the return states, but then we would lose all the nice RINEX formatting code in HandleByte(). With the patch, HandleByte() works also with NO_RTCM_MAIN defined.

[stoecker]

In [2507/ntrip]:

fix #3 - patch by johansen - duplicate RINEX epochs due to new data types

[stoecker]

Right. I was not aware of the fact that such code has been added. BNC directly calls the RTCM3Parser, so this error did not appear there.