Problem with STRSVR and file output when splitting by time and loosing connection to stream ?

[gemetris]

Hello.

We are experiencing lots of problems with STRSVR when using a timer.
I mean: we are processing GNSS raw data (RTCM) each our.
The raw data is coming in real time (RTCM): we read it with STRSVR and write it to a file. Then convert to RInex and process.
The fiels are splitted hourly.
Everything works fine, until the GNSS are powered off (and not data is coming any more).
We we use a time in order to measure only some hours per day, the RTCM/raw files are not written/slitted correctly any more.

For example, if we power the GNSS on for one our, then power off for one hour, then on again, the file created by STRSVR will contain 2 hours and th4 next one will be empty. The hourly file splitting won't work correctly.

Other example: we power the GNSS on form 0:00 to 3:00. The file named "0000" won't exist, the file "0100" will contain data for 01:00 to 02:00, the file "0200" the data for 02:00 to 03:00 and there will be a file "0400" containing data at 04:00 (some mesurements until the GNSS is power off and then, at the end of the file, the data between 00:00 and 01:00 the net day !!

We can also see in last write time info in OS, that the files are written in a "special" order (caution: the is a difference between GPS and OS time, so the 2 hours difference is normal):

And because we use "-ts" and "-te" then for convin, nothing works correctly because it is expected that the RTCM file is in chronological order without gap (I guess, or tehre is something other).
I guess there is something between file splitting and buffer management.
Or did I miss something?

[rtklibexplorer]

Hi, Sorry for the slow response. I have got behind on my emails over the holidays. I have not had time to try and duplicate your issue or to fix it but have not forgotten about it and hope to take a look at it fairly soon. Best regards, Tim

…

On Wed, Dec 22, 2021 at 8:57 AM Gemetris Innovation SA < ***@***.***> wrote: Hello. We are experiencing lots of problems with STRSVR when using a timer. I mean: we are processing GNSS raw data (RTCM) each our. The raw data is coming in real time (RTCM): we read it with STRSVR and write it to a file. Then convert to RInex and process. The fiels are splitted hourly. Everything works fine, until the GNSS are powered off (and not data is coming any more). We we use a time in order to measure only some hours per day, the RTCM/raw files are not written/slitted correctly any more. For example, if we power the GNSS on for one our, then power off for one hour, then on again, the file created by STRSVR will contain 2 hours and th4 next one will be empty. The fhourly file splitting won't work correctly. Other example: we power the GNSS on form 0:00 to 3:00. The file named "0000" won't exist, the file "0100" will contain data for 01:00 to 02:00, the file "0200" the data for 02:00 to 03:00 and there will be a file "0400" containing data at 04:00 (some mesurements until the GPSS is power off and then, at the end of the file, the data between 00:00 and 01:00 !! We can also see in last write time info in OS, that the files are written in a "special" order (caution: the is a difference between GPS and OS time, so the 2 hours difference is normal): [image: Capture] <https://user-images.githubusercontent.com/55704516/147119909-78402f8b-a4d0-48d0-823f-8037feaed442.PNG> And because we use "-ts" and "-te"then for convin, nothing works correctly because it is expected that the RTCM file is in chronological order. I guess there is something between file splitting and biffer management. Or did I miss something? — Reply to this email directly, view it on GitHub <#106>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3YLORNP4YSC3LTFIRKTS3USHYPBANCNFSM5KS3QQTA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gemetris]

Are there some news here?