I have a Leica TS16 and I want to perform measurements in continuous mode as fast as possible on a moving prism that is mounted on a rover. I configured the TS to acquire a point every 0.1 seconds and i ran the measurement for a few hours. I noticed two problems:
- the time precision of the timestamps is very low. The prism was moving at (almost) constant speed (~50cm/s). However, the speed computed using the TS points and the relative timestamp oscillates between 0.2 and 1.1 cm/s. Assuming that the space precision is very high, this means that there is a problem with timestamps.
- the time difference between subsequent measurements is always greater than the desired one, and it keeps increasing over time, starting from about 0.16s at the beginning, to more than 0.5s at the end
The measurements were performed in very good conditions, with no obstacles nor reflections. The TS firmware was updated to the latest version
Is there a way to fix this problem?
The delay might be caused by the time need to calculate the distance. Usually, the time when the shot was taken is not relevant for most applications, what is crucial is that the standard error of the measurement is acceptable.
I would test it in a more controlled environment to see if the difference in time between when you expect the measurement to happen vs when it's stored is constant (if it's a standard calculation delay, there is a reasonable chance that it could be). If that's the case, you just have to apply that delay as a correction to the stored time and you should get more accurate times for the measurements.
@minbarwinkle thank you for your suggestion. I think that the error is not constant, however I will give it a try. How do you suggest to setup a controlled environment for such a test?
Had this problem a few years ago.
Found two things contributed to the latency:
Wireless/radio/bluetooth latency combined with flash memory write speed.
Going cabled helped minimize the communication latency (a bit).
The memory write speed was slightly improved with the fastest SD card we could find.
If you are/were trying to log GNSS shots and TS shots at the same time on the DC, you may be overloading the DC communication link.
We ended up logging raw data to the GNSS (base/rover) in PPK mode and only kept the TS measurements flowing through the DC.
Then processing the ppk and TS together got us as good as we could get.
Several hours of measurements at 1 measurement / 0.1 sec is A LOT of data to store.
?ÿ
You may want to consider laser scanning / mobile lidar with the timestamp sync'd with the GNSS pulse output instead.
?ÿ
?ÿ
10Hz logging rate? What in the world is the target application for this sort of work?
Had this problem a few years ago.
Found two things contributed to the latency:
Wireless/radio/bluetooth latency combined with flash memory write speed.
Going cabled helped minimize the communication latency (a bit).
The memory write speed was slightly improved with the fastest SD card we could find.
If you are/were trying to log GNSS shots and TS shots at the same time on the DC, you may be overloading the DC communication link.
We ended up logging raw data to the GNSS (base/rover) in PPK mode and only kept the TS measurements flowing through the DC.
Then processing the ppk and TS together got us as good as we could get.
Several hours of measurements at 1 measurement / 0.1 sec is A LOT of data to store.
?ÿ
You may want to consider laser scanning / mobile lidar with the timestamp sync'd with the GNSS pulse output instead.
?ÿ
?ÿ
We are storing the measurements in the internal memory and when the session ends we export them in a SD. I think this is the best solution to minimize timing problems.?ÿ
10Hz logging rate? What in the world is the target application for this sort of work?
I was wondering about that. It almost seems like they're trying to get a point cloud without a scanner.?ÿ
I.m not familiar with the detailed operation of theTS16, but I've seen this sort of problem in the past when somebody tries to use an instrument in ways that were not intended. This might well be a buffering problem within the data handling - not important for most survey, but obviously a concern if you are effectively trying to use the instrument to track the trajectory of a moving object.
It might be that the instrument is also trying to "learn" the measureing environment, deciding that as things keep changing it ought to allow for a little more time on each measurement, "just to be sure". I'd ask your dealer for a detailed explanation.
According to this documentation, 1.5 seconds per measurement is about the best you can expect from this product, and that's just to measure the HA/ZA/SD for each shot.
With trimble gear you can enable tracking mode (as opposed to standard mode) and grab the instantaneous position of the point at any time. I honestly can't remember if Leica has anything similar, but then again I don't know if Trimble would be able to keep up with 10Hz positioning either. I doubt it.
?ÿ
This thread reminded me of when I worked for a Trimble dealer, and we rented out an R10 setup to a geologist or engineer (can't remember which) who was going to be doing some GPR work and wanted to sync up their positions with the GPR data. So I set everything up for them, including a 1Hz logging rate so that they could post-process their trajectory with timestamped positions. (There was a continuously operating base on the project site to process against.)
Well, they came back from their trip all pissed off. At Trimble, at my employer, and especially at me.
Why? They had changed their logging rate to 20Hz.?ÿOf course their receiver had filled up with data long before they got done with the project. If they had downloaded the data at the end of each day (which I showed them how to do) it wouldn't have been a problem, but of course they couldn't be bothered to do that. So they just....kept working, ignoring the fact that the little blinky lights weren't blinking after a couple days. Didn't have data for half of their GPR runs.
Keep in mind that this was for a GPR unit that was pushed at walking speeds by the operator. And never mind that the base they would have been processing against was only logging at 1Hz...
Every 0.1 seconds??ÿ I don't think I've worked with a total station that seemed remotely capable of taking shots that fast.
You need to look at running spatial analyzer software and a laser tracker with a smr. What type of work are you trying to perform. The laser tracker will take a shot will locate points down to less than a 1/8 apart about as fast as you slide the smr dow or across and item. I have used this to map machinery. ?ÿAnd key items on structures. Now if you are trying to map a large area a scanner might be better. If small like say from an engine size down to a ?ÿsmaller than a small screw size then a radial arm scanner would be better. ?ÿIf you are trying to us gps and total station continuously you are moving faster than the epoch rate of the satellites themselves so your internal clock of the receiver would need to be updated to something like a rubidium etc. so your out pacing any accuracy or precision in the time component .
give us a hint at what you are trying to achieve and there are some very smart people here that probably can help ?ÿI am not the smart people. ?ÿBut I will help if i can. Just by some of your verbiage the first thing that came to my mind was metrology measurements. ?ÿ?ÿ
?ÿ
Pretty much off-topic, but I'm reminded just how bad the internal clock in my Carlson Surveyor+ is.?ÿ It loses (or gains, don't recall) multiple hours in a month.?ÿ It's so bad that I don't bother updating the clock setting until it gets the date wrong.?ÿ I don't use the clock for anything other than putting the date in my raw data files anyway, but if a $10 Casio watch can hold a few seconds a month, why did Juniper put such a low-accuracy clock in their pricey field computer?
I am replying to the ones that are concerned about the possibility of acquiring at 10Hz.
There is an official app that can be installed on the TS16 that is called TS Survey Streaming. This app allows to continuously measure points and stream them to file, network, bluetooth etc. Now according to the manual, this app allows to stream data with a frequency up to 100Hz (if streaming onboard and not remotely). Now, if this is possible I don't think that measuring at 10Hz should be a problem...
If you believe that, I "officially" have a bridge in Brooklyn to sell you.
It shouldn't be a problem.
