After reading Nate's topic on hz rates and the responses, and one from a well known software vendor, there are still questions unsettled:
If I have a GNSS sensor w/20 hz capability, can I stream 20hz RTK corrections using a) UHF modem, b) cellular modem ?
And, if I can stream 20hz, do some sensors have capability to process 20hz corrections or just 1hz?
Which sensors can stream at 20 hz in base mode and which sensors can process 20hz corrections in RTK rover mode?
?ÿ
?ÿ
I can't answer your question but I believe your choke point is going to be the time necessary for your radio to transmit this data. Can it fit all of the data into 1/20th of a second? If not, your are then limited by the volume of data needing to be transmitted.
CMR, CMR+, and different versions of RTCM are different "shorthand" for the data transmission and will affect the time needed to complete the transmission of data.
I believe your choke point is going to be ....
.... human capacity to comprehend. These things could be the size of the head of a pin, but they have to be big enough for human fingers to manipulate them. Cell phones got smaller and smaller up to a point, and then they started getting bigger, so humans could see their screens. If my RTK initializes in a few seconds, as they all do, that is fast enough. Any faster has no real purpose.?ÿ
@norman-oklahoma that is the question, do faster data corrections help and if so, how.
Was in the field yesterday watching one of our rovers struggle with processing data in a canopy to get a fix.?ÿ I looked at Nates post to see if Javad was transmitting, receiving, and processing all the 5hz data and fixing quickly in canopy.?ÿ I have two machines with 20hz capability.?ÿ I have a vendor saying he thought uhf could only translate at 1hz.
Is 1 or 5 or 20hz any better at processing real time in the field in difficult situations?
has anyone here done any testing?
If my RTK initializes in a few seconds, as they all do, that is fast enough. Any faster has no real purpose.?ÿ
Respectfully, I must disagree with you. When you are in heavy canopy, it can become a game changer.
We are not saving microseconds. We are getting "Data between the cracks".
N
I have a vendor saying he thought uhf could only translate at 1hz.
I am 95% sure that the PDL/TDL external radios that I have used off and on for most of my career only transmit at 1Hz. At least, that's what the datasheets always said...
If my RTK initializes in a few seconds, as they all do, that is fast enough. Any faster has no real purpose.?ÿ
The value in fast initialization lies in the fact that initializations don't always resolve the integer ambiguities correctly, especially once you depart from wide-open conditions.?ÿ The profile I generally use has the receiver continuously reinit until 60 seconds have elapsed and the confidence counter (a Javad metric) hits 50. If I had to wait a few seconds for each one of those inits I'd be there all day.?ÿ
I am 95% sure that the PDL/TDL external radios that I have used off and on for most of my career only transmit at 1Hz.
My Javad 35w will broadcast at a true 5hz, but it runs a lot hotter when it does.?ÿ I didn't see enough difference between true 5hz and extrapolated 1hz to justify the additional stress on the radio and battery.?ÿ And I only tried 5hz with GPS and GLO; it may not work with additional constellation data.
@lurker?ÿ
We have the stock standard setup of a base transmitting at 1Hz, running RTK with the original setup being GPS and GLONASS. The latency (age of the corrections) as seen at the rover DC when near the base was always 1s, far away from the base or poor radio reception would see the latency increase. When we upgraded the firmware to include BeiDou, the latency when near the base increased to 2s.?ÿ
Documentation suggests that 4800bps (think older trimtalk etc) was barely enough for 1Hz RTK corrections unless using the slightly more compact CMRx format.
The few public CACS stations ( Canada-flavoured CORS) I've checked around here transmit 300-350 bytes per "correction", once per second. That usually includes corrections for both GPS and GLONASS SVs, I forget if they also track other constellations.
Multiplying that by 20 means you need about 7kB/s throughput (estimating with about 10 bits per byte to include modulation overhead, so around 70kbit/s), which is kindof a lot for a single UHF channel. I'm not pro at spectrum / bandwidth calculations but there's never a free lunch; you can only send so much data on a single 12.5kHz channel - I think 19200bps might be close to a realistic limit. Hopefully someone can correct me or validate this.
I think 19200bps might be close to a realistic limit. Hopefully someone can correct me or validate this.
As I recall, I had to change the modulation selection in order to get 5hz to work, though I don't remember which spec it required.?ÿ I do know that I had to sacrifice a bit of range when switching to that spec.?ÿ (It's been a few years since I changed back to 1hz, so the details are fuzzy.)?ÿ
I rarely use UHF nowadays, I'm able to get corrections via TCP pretty much everywhere I usually work.
@jim-frame and if your RTK base station (RTN) were streaming 20hz corrections over tcp/ip would you be able to take advantage of 5hz on your rover?
are the RTK computations for 1hz to 2hz corrections exponentially more intensive and from 1hz to 5hz maybe require 25 times the processing?
where is the sweet spot?
are the RTK computations for 1hz to 2hz corrections exponentially more intensive and from 1hz to 5hz maybe require 25 times the processing?
I would expect the data and computation to grow in only linear proportion to the rate.
Pedanticism: your example of 25 is a second power relation, rate squared; not an exponential relation, something to the power of the rate.
where is the sweet spot?
The sweet spot for me is upsampling 1hz from the base to 5hz on the rover, because that's what works.?ÿ 🙂
It's important to remember that RTK Hz rate may refer to two different ideas: solution rate and position rate. To my?ÿ knowledge in almost every instance >5Hz is referring to position rate. Recently we announced that we can support 200Hz. That's a position rate, not a solution rate. This is great for getting positions when the receiver is in motion. A lot can happen at high speeds in one second. Higher position rates fill in those gaps between the position at each second.
Solution rate refers to how many times per second the processor attempts to resolve ambiguities per second. The time required to perform the calculations for resolving integer ambiguities will be the most significant impediment to a faster solution rate. When we first started looking at increasing the solution rate, we started at 2Hz (twice per second). We saw improvements in time to fix under canopy and soon Javad realized that he could run the computations as fast as 5x per seconds so we went to a 5Hz solution rate. The 5Hz rate was even more robust than the 2Hz rate under canopy. Obviously in the open, fix times were extremely fast, but as @norman oklahoma pointed out, this increased solution rate won't have much apparent influence in the open where fix times are already very fast, regardless of solution rate. But today's surveyors are pushing RTK deeper and deeper into canopy and the faster solution rate is getting them fixed solutions faster in those places.?ÿ
Initially we had to transmit at 5Hz so that the processor had fresh corrections to perform the calculations. To do this with GPS + Glonass, when broadcasting over UHF we broadcast RTCM 3.0 Min with D16QAM with channel spacing at 12.5kHZ (narrowband compliant). This did put a serious strain on the radio as the duty cycle was quite high (most of the time it was transmitting with very little rest between transmissions). This causes the radio to get much hotter, requiring a cooling fan when broadcasting at higher wattage output. But it proved the concept to be very worthwhile.?ÿ
Javad then came up with a proprietary approach that would allow a correction to be extrapolated in a special way so as to allow for the correction to be sent at a 1 second rate, but for the processor to still perform the calculation five times per second. We observed that the performance was not diminished by this approach and it was better for the radio, both in terms of life and in terms of range. The faster modulation (D16QAM over DQPSK) reduced the range noticeably, so returning to the lower modulation allowed us to reclaim that lost range.?ÿ
Interestingly frequency hopping spread spectrum (FHSS) has the bandwidth to transmit at 5Hz without the same overhead as UHF. Also internet based corrections (TCP/NTRIP) can handle the bandwidth at 5Hz as well. For us, we've not revisited the need for faster transmitting because Javad's proprietary extrapolation process (upsampling) allowed us to use 1Hz transmission rate again and maintain 5Hz solution rate.
I suspect there is a point of diminishing returns. I don't know if 20Hz would be a significant improvement over 5Hz. Possibly... I just have no experience with it. I do know that 2Hz was better than 1 Hz and 5Hz was better than 2Hz, so who can say?
