Bill,

Why set the data logger to Static mode at all (Part 3 Static Init.). Aren't you effectively undoing this when you remove the 1-second ???? observation between the static and kinematic observation of your init. point ?

Why not just set the point and record the data logger info in kinematic mode (since you aren't turning the reciever off anyway) but occupy the point for the required static time for the distance required ??

Am I missing something ??

I have been following the precedures for initialization, and sometimes it just goes haywire and I lose a whole day of work.

The processor refuses to recognise sometimes that an observation, whether over a static point or a previously processed point, is an initialization, and treats all subsequent kinematic observations as 20 second static shots with huge errors. How can I MAKE the processor see that it is an init?

I have tried everything....control point, not control point, download in new project, existing project. If there is something fishy about the static shot, say errors of (float?) 0.16 feet, then will kinematic based on this point go wild? I initialized on a previously processed point, gave the same site ID, 20 seconds occ 5 second interval, and the processor refuses to see this as an init.

Another mystery. Today I turned on the kinematic alarm on the rover while doing static observations. Clear sky, open country, logging 8 satellites continuously according to the tracking LED, and yet the kinematic alarm sounds once in a while. I did this because sometimes I'm doing kinematic with 8 sats and the alarm goes off for no reason. I did a static shot today with one blink on the occ timer in 14 minutes reading 8 sats the whole time, with the kinematic alarm going. Perfect observation and processing.

Seism,

I don't know how to force the processor to read a point as an init but...

I USE A SLIGHTLY MODIFIED PROCEDURE THAN RECOMMENDED. I also lost a day because of wild re-inits using short occ. times on previously established points. Thereafter I decided it would be better to loose 5 minutes than 10-12 hours. When K-alarm goes off I use a 5 minute occupation of a previously established point for the re-init or a 20-30 minute occ. of a new point(depends on terrain and distance to old point). I don't go to static mode and I don't turn the reciever off. Has worked just fine for me. Also make sure PDOP is below 5.

Jimbo

Jim,

When collecting a kinematic observation with Locus Handheld, the longest observation time (Time on Site) that you can enter is 999 seconds (may be less, can't remember at the moment). When the countdown reaches 0, a record is written to the D-file changing the Site ID to ????. If your required static observation time is more than 999 seconds, all data after 999 seconds will be assigned a Site ID of ????.

This is a limitation in the handheld software that will be fixed in the next version.

Bill Martin
Ashtech Precision Products

Seism,

Please email me a data set exhibiting the initialization problem. I may have overlooked something in my procedures that you data set will help to identify.

Bill Martin
Ashtech Precision Products

Seism,

Regarding the kinematic alarm. The 'problem' could be attributed to a number of things.

1. The satellite tracking LED shows how many satellites above 10-degrees from the horizon that are being tracked and logged to memory. The Kinematic Alarm only uses satellites above 15-degrees due to Locus Processor only using satellite data above 15-degrees. For this reason, you cannot depend solely on the satellite tracking LED. It's possible that some of your 8 satellites were below 15-degrees.

2. The kinematic alarm is designed to flag cycle slips in the data caused by complete loss-of-lock on a satellite or noisy data from a satellite. If the noise level of the data from enough satellites reaches the threshold value, the Kinematic Alarm will sound. Noisy data can be caused by a number of factors other than obstructions, such as a highly active ionosphere. It could also be due to a poorly functioning Locus Receiver.

If you email me a the data file you discussed in your post, I can take a detailed look at it to see if I can isolate the reason for the alarm sounding.

Bill Martin
Ashtech Precision Products

For kinematic datasets with problems for “Initializing by performing a Static Survey” (without turn off/on receiver between static and kinematic observations) you can also try the following procedure that works fine for me.
You must make a change in data from handheld downloaded D-file, so make first a backup copy of it !


Example of kinematic survey, 4x4 seconds interval per point:
D-file D5036A00.263

%CMT=D-FILE CREATED BY LOCUS HANDHELD SOFTWARE VERSION 1.00
%VER=1
%RID=LOCUS,,,5036 ;receiver type, serial number
C 208043.403,1080 ;start time for static observations, week
%FTR=0,IN05, ;static point ID (IN05)
%ANT=0,,2.125,, ;antenna height
C 210293.126,1080 *** ;end time for static observations, week
%FTR=1,????,
C 210293.807,1080 *** ;start time for kinematic initialization, week
%FTR=0,IN05, ;init. point ID (prev. static surveyed)
%ANT=0,,2.125,, ;antenna height
C 210309.807,1080 ;end time for kinematic initialization, week
%FTR=1,????,
C 210775.464,1080
%FTR=1,????,
C 210776.147,1080 ;start time for 1st kinematic point, week
%FTR=0,0550, ;kinematic point ID (550)
%ANT=0,,2.125,, ;antenna height
C 210792.147,1080 ;end time for kinematic point, week
:
:
:
As you can see, the start/end time for observations is given in seconds, real number. I think somewhere in Locus Processor is used an integer function, instead a real one. In datasets where the integer parts of the end time of static survey and the start time of kinematic init are different there are no problem. Otherwise, like in my example (integer part of both times is 210293), I think that software has a little problem in handle this situation.
So, if you cut the end time for static survey at least 1 second earlier (in my example modify 210293.126 in 210292.126) everything is OK.

Hope this help,
Alec Sturza