Unknown Error

[James Suttles]

I have ran this file several times, and I get an unknown error. Anyway to get it reduced and identify what the issue may be.

@Alexey Razumovsky

Link to file

Javad Dpos

Shared with Dropbox

www.dropbox.com

 

[James Suttles]

Converted the file to Rinex and sent file to OPUS and got a solution.... So not sure what could be the issue.

 

[James Suttles]

I have another file that is exhibiting the same behavior.

Thanks

 

[Alexey Razumovsky]

DPOS does not accept files that pass over GPS midnight.

Splitted files here

 

[James Suttles]

Just curious, is that something that can be overcome by DPOS, or is that something we will just have to deal with. When I convert the files to RINEX and submit to OPUS, OPUS will process the file, whiteout having to split the file, but we loose the other constellations in our reduction.

Thanks

 

[Alexey Razumovsky]

DPOS has low knowledge about availability CORS data on the period of observation. First day may have full files set, second day may have no data at all. It destroys a workflow because DPOS does not show table of data availability and hides some stages of data managment.
I agree that it decreases a functionality but it help to avoid an uncertainty.

 

[Matt Johnson]

DPOS has low knowledge about availability CORS data on the period of observation. First day may have full files set, second day may have no data at all. It destroys a workflow because DPOS does not show table of data availability and hides some stages of data managment.
I agree that it decreases a functionality but it help to avoid an uncertainty.

I would suggest that DPOS automatically spits the file at the end of the day and then processes both days separately and provides an adjusted solution. If no data is available on the 2nd day then the solution from the first day would be provided.

 

[Alexey Razumovsky]

@Matt Johnson First day - 10 hours, second day - 1 hour. No way to adjust automatically because 1 hour data often yields better rms and so bigger weight. In the meantime 10 hours solution is much more accurate.

 

[Matt Johnson]

@Matt Johnson First day - 10 hours, second day - 1 hour. No way to adjust automatically because 1 hour data often yields better rms and so bigger weight. In the meantime 10 hours solution is much more accurate.

Could you provide a weighted average using the duration of each session as the weight? If not then it probably would just be best to use session with the longest time.

 

[James Suttles]

Ok, I have another file with unknown error. I purposefully checked to be sure and catch the file before it crossed over GPS midnight. I am not sure how the best way to split the file, like you did @Alexey Razumovsky. So with that said is there a way to tell the Delta Base Station to Stop the file crossing over GPS Midnight and create the next file on the Beginning of the next GPS Day.

Link to the File. If you can work your magic on this file that would be great. The converted RINEX file sent to OPUS processed without aborting, so I am guessing its the Midnight issue again.

Javad Dpos

Shared with Dropbox

www.dropbox.com

Thanks

 

[Alexey Razumovsky]

https://javad-software.s3.amazonaws.com/software/Justin/log0803a_new.zip

Here you go

 

[Adam]

So with that said is there a way to tell the Delta Base Station to Stop the file crossing over GPS Midnight and create the next file on the Beginning of the next GPS Day.

That would be handy.

@Eugene Aksyonov

 

[Eric Tweet]

That would be handy.

@Eugene Aksyonov

One way to facilitate this would be logging with AFRM. I have that sort of thing set up on my permanent base, continuously logging with 3-hour file splits. Any interval that factors into 24 would yield a split at midnight. For my setup this allows me to pull and merge files of reasonably short duration for processing when needed, while being able to satisfy the OPUS "maximum 48 hours, not crossing UTC midnight more than once" condition for longer durations. Perhaps a bit of a roundabout solution for some situations...

Also I don't know off the top of my head if AFRM-managed logging can be set up for activation when using the Fn key to begin recording. (but my guess is that it can)

 

[Adam]

Wow, nice info. Is AFRM a setting that can be applied in net and modemview or nethub?

Is your permanent base a Javad receiver?

Thanks for the input.

 

[James Suttles]

Looks like it can be set with both programs. I have set it to force file rotation, should know in an hour if it rotates and creates a new file.

 

[Eric Tweet]

Yep, as James mentioned both programs should do the trick. I was just now poking around at the options in NetView&Modem on my T-1. And if it's not set by default, I believe you can have it synchronize file creation to the epoch at the beginning/end of the nearest hour, so that it's not logging from, say 3:21 PM to 4:21 PM, but rather 3:00PM-4:00PM, etc.

My perma-base is a Topcon NET-G3A. So obviously I can't use NetView to enable the feature (or maybe I can... GREIS is just GRILL on steroids!), but I believe the functionality is essentially identical. I have used AFRM with my T-1, though rarely encounter the need to do so, hence my head-scratching about some of the details.

 

[Adam]

Yep, as James mentioned both programs should do the trick. I was just now poking around at the options in NetView&Modem on my T-1. And if it's not set by default, I believe you can have it synchronize file creation to the epoch at the beginning/end of the nearest hour, so that it's not logging from, say 3:21 PM to 4:21 PM, but rather 3:00PM-4:00PM, etc.

My perma-base is a Topcon NET-G3A. So obviously I can't use NetView to enable the feature (or maybe I can... GREIS is just GRILL on steroids!), but I believe the functionality is essentially identical. I have used AFRM with my T-1, though rarely encounter the need to do so, hence my head-scratching about some of the details.

Ok, I'm curious. How's cell coverage in your area of Alaska? Do you mostly work in the developed areas of Alaska? I'm in NC and I struggle with poor cell service in rural areas.

 

[James Suttles]

Ok, that worked, it just stopped the file at 23:59:42 and started a new file at 0:00:12 so it will create a new file every 24 hours on 12 seconds after GPS Midnight. Hopefully problem solved.

 

[Eric Tweet]

Ok, I'm curious. How's cell coverage in your area of Alaska? Do you mostly work in the developed areas of Alaska? I'm in NC and I struggle with poor cell service in rural areas.

Oh boy... I'm based in Nome. Cell coverage in town and the immediate area has gotten quite decent these days. However if I have to hop over the mountains just a couple minutes north of town, or really a 10 minute drive in any direction, then I'm SOL. Some places work fine, but most are not even worth hoping for a good cell signal. I always have my T1 base and HPT435BT handy if I leave town even slightly just in case. (I just recently had to set some new subdivision corners down in an old gravel pit IN TOWN and I just couldn't get a signal without placing my phone on my head).

Aside from that, my frequent stomping grounds span from Little Diomede island, across the southern Seward Peninsula down to Stebbins and St. Michael. "Developed" becomes a sufficiently relative term. Surprisingly the cell coverage in the villages across that area is not half bad usually. However, I don't currently have a portable base with a working cell modem, so I'm UHF-only whenever I have to go village-hopping. Half the time my out-of-town jobs are 5 miles up thus-and-such river, or 30 minutes over raw tundra by ATV, so in the end, I really just reserve cellular coms for work when safely in Nome proper.

That said, I've got an LS+ on the way and on the verge of snagging a T3 to go along with that, which would make cellular a much more viable option in many more situations...

Bonus attachment: A view from yesterday's commute

 

[Adam]

Awesome. Thanks for sharing. Really cool.