Activity Feed › Discussion Forums › GNSS & Geodesy › Pulled base receiver legs before turning power off, trimming bad data
Pulled base receiver legs before turning power off, trimming bad data
Posted by big-al on May 4, 2021 at 8:34 pmOn a recent job, I mistakenly pulled the set of legs that my BRx7 base receiver was sitting on before turning off power to the unit. The receiver was logging 30 second data to a static file at the time. By the time I got to my truck, I quickly realized the error, and turned off the power, but I may have logged 2-3 minutes of bad data as a result. Links below provide access to RINEX data.
My question – Is there a way to definitively determine whether there is “bad” data at the end of the file?
BTW, I got a good solution from OPUS without trimming anything at the end of the file.
big-al replied 2 years, 11 months ago 8 Members · 18 Replies- 18 Replies
I have never ever done anything like. RIIIGGHHT!!! My data indicates a kinetic property, so, if I ever did something like that, I could find the kinetic marker and cut the data after it.
Is there a kinetic property in a RINEX file?
Thanks for your help. I’m using Carlson SurvCE v6. There are some entries in the Carlson raw file RW5 at the beginning of the session when setting up the base, but I don’t think there’s much more than that. Otherwise, all I have is the BIN file saved on the BRx7, which I have converted to the 21O and 21N files provided.
An Ashtech receiver would say “antenna is moving”. Used those markers to trim files when the wind blows my setup over. Just recorded when I set it back up and kept on working. One very windy location I had three antennas blow over, one setup twice. Just had more files to process.
Paul in PA
OK, Paul, that triggers two ideas – 1) Contact Hemisphere (manufacturer of BRx7) to see if the native BIN file might have such an indicator, and 2) Contact Carlson to see if the RW5 might have an indicator. I’ll post my results here for others. Thanks.
Even though you got a solution it could be biased by the extra data.
It seems that when I once ran a session through the Canadian NRC site it gave me a graph of position vs time. That would let you identify the beginning of movement, so you could chop off that much of a RINEX file and resubmit to OPUS.
.I ran your file as a kinematic observation file, processed against MASH and I can’t see that the receiver moved during the observation. I don’t think you have anything to worry about.
The results are attached…
3 minutes of 30 s epochs would be 4-5 pings vs the total number over the course of the session. Probably didn??t cause a significant variation in the session.
@mark-silver
Very helpful, thank you. I agree, your results seem to indicate no movement. What software did you use to do this? (I may encounter this again…and, now, I have to figure out what job I pulled the legs on!)
I have several: SPSO, TBC (same, just different version), CGO2 that I use on a regular basis. CGO2 is the easiest, so I used it. This is a VERY common issue for some owners of the static receivers we sell. So we actually have a Trim function built into our download tool and we use it all the time.
There are three ways to screw the occupation up: 1. Turn the receiver on when you take it out of the box and then screw it to the tripod and level up; 2. Take the receiver off mount while on and put it in the box. This is usually also accompanied by a drive back to the office, so the processing reveals all the stops along the way; 3. Exchanging the Base and Rover, then processing a Rover as if it is a static base, usually accompanied by strong denial until a map of the rover’s trajectory is produced.
Have a great week!
Mark
@mark-silver
Thanks again Mark. I used to have a license of TBC, but moved away from Trimble and ended up selling my license. I don’t have SPSO or CGO2, either. Sounds like CGO2 is a good tool, and I think you sell it?
By the way, I did hear back from Carlson, and neither the static BIN file or the RW5 file at the rover would contain any indicators if the base was moved/knocked over.
This happened to me a few weeks back with the same receiver. Once I converted the .bin to rinex I just opened the observation file with notepad and manually trimmed 5 minutes of data. Took me a minute to see what format it was, but the timestamps are pretty easy to see on each set of observation. I then sent it through OPUS and it processed just fine.
If you have plenty of data for a solution, then just edit out the last 5 minutes to be safe. You could process the data as kinematic (force kinematic) and see when it moved. Or, submit to NRCAN CSRS-PPP, which will process kinematic data using point positioning techniques.
Yes, agreed. Part of my problem is that I’m now not exactly sure on which recent job I pulled the legs prematurely, so I will have to repeat this exercise until I figure it out. Trimming the last 5 minutes is a good idea (and I did it for this job to be safe) but its a bit of a blind guess. Submitting to NRCAN as suggested allows me to decide which job needs to be trimmed at the end. Thanks so very much for the input.
Easy to do! BTW, the BRx7 receivers are simply amazing to me. I’m very happy with my purchase.
Using the Canadian CSRS-PPP online service (thanks very much for the suggestion, it is a great tool), I submitted a bunch of recent RINEX files to see if I could find the job on which I had mistakenly pulled the legs. I submitted the RINEX files using the ITRF option and selected “Kinematic”. The resulting graphic reports are fascinating. One of the pages shows the kinematic position, broken down by latitude, longitude, and height. The attached image shows the result on the offending job. The last 2-3 minutes of the static file was corrupted. I trimmed 4 minutes from the file and resubmitted to OPUS.
The results were ever so slightly different than the prior obtained results, decreasing by 0.001 meters in Northing, exactly the same in Easting, and increasing in height by 0.001 meters. What I trimmed off the file was a move horizontally south and west and up in height. I would have expected that if the bogus positions at the end of the session were removed, the solved position (after trimming) would have been in the opposite direction of the receiver’s movement. Thus, I would think the Northing would have increased, the Easting would have increased, and the Height would have decreased. But, the results are negligibly different and if anything are opposite from my expectations. This makes me think that perhaps OPUS somehow automatically QC’s the data, and rejects any observations that exceed the QC thresholds. Anybody know whether this is true?
Log in to reply.