Modify

Opened 12 years ago

Closed 12 years ago

Last modified 8 years ago

#3 closed defect (fixed)

Duplicate data records in generated RINEX files

Reported by: johansen Owned by: stoecker
Priority: normal Component: rtcm3torinex
Version: Keywords:
Cc:

Description

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.

Attachments (2)

duplicate.patch (379 bytes ) - added by johansen 12 years ago.
duplicate-sample.zip (157.4 KB ) - added by johansen 12 years ago.
Sample data

Download all attachments as: .zip

Change History (8)

by johansen, 12 years ago

Attachment: duplicate.patch added

comment:1 by stoecker, 12 years ago

Owner: changed from stoecker to johansen
Status: newneedinfo

Do you have an example datastream for this behaviour?

by johansen, 12 years ago

Attachment: duplicate-sample.zip added

Sample data

comment:2 by johansen, 12 years ago

Owner: changed from johansen to stoecker
Status: needinfoassigned

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

comment:3 by stoecker, 12 years ago

Owner: changed from stoecker to johansen
Status: assignedneedinfo

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.

comment:4 by johansen, 12 years ago

Owner: changed from johansen to stoecker
Status: needinfoassigned

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.

comment:5 by stoecker, 12 years ago

Resolution: fixed
Status: assignedclosed

In [2507/ntrip]:

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

comment:6 by stoecker, 12 years ago

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.

Modify Ticket

Change Properties
Action
as closed The owner will remain stoecker.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.