ETA on Linux and Galileo

Nate The Surveyor

Well-Known Member
Why not set up 10 systems, in challenging environments, for 10 days, with different settings, and have them store coords every 3 minutes, and just see what settings are best?
 

Duane Frymire

Active Member
Why not set up 10 systems, in challenging environments, for 10 days, with different settings, and have them store coords every 3 minutes, and just see what settings are best?
Different settings will be best at different times on different days in different geographic areas. Seems to me the memory limits need to be overcome somehow.
 

Shawn Billings

Shawn Billings
5PLS
Different settings will be best at different times on different days in different geographic areas. Seems to me the memory limits need to be overcome somehow.

After so many signals in a single engine, you get to a point of diminishing returns. I think separating the signals between engines will ultimately prove to be a very successful approach to faster verification, but we'll have to see.
 

Nate The Surveyor

Well-Known Member
I was confused too. I called Shawn. He said that testing, and pre release has all this stuff. Whatever goes to release, will be more simple. This is mainly for the pls team. And, the ambitious.
N
 

Darren Clemons

Well-Known Member
Different settings will be best at different times on different days in different geographic areas. Seems to me the memory limits need to be overcome somehow.
I’ve thought them same thing all along Duane. I always though the “more birds the better” and that we’d move towards 20+, then maybe 30+ sats and be crunching them all, but Javad has always been emphatic in that “more than 20” signals are too many.....and he is definitely “master of his domain” as far as RTK surveying so I have no doubts whatever we end up with will be the best there is. I honestly never thought we’d be “restricted” on how many signals we could/would use.

The efficiency, to me, will lie in removing the inferior signals being used, not in adding in more. From all my years of GPS RTK work, the times you really, really struggle to get that tough fix is when you have a very weak, inferior signal trying to “help” in your overall solution. The “bad” data being thrown into the solution by it sometimes keeps the other, more solid signals from giving you a solution. I.E. - 8 or 9 sats in a rough area can, and sometimes will, knock out two separate three phase shots in a matter of a few minutes and sometimes that same spot could give you 11-13 sats and you may be getting three 15 minute PPK shots....
 

Duane Frymire

Active Member
I’ve thought them same thing all along Duane. I always though the “more birds the better” and that we’d move towards 20+, then maybe 30+ sats and be crunching them all, but Javad has always been emphatic in that “more than 20” signals are too many.....and he is definitely “master of his domain” as far as RTK surveying so I have no doubts whatever we end up with will be the best there is. I honestly never thought we’d be “restricted” on how many signals we could/would use.

The efficiency, to me, will lie in removing the inferior signals being used, not in adding in more. From all my years of GPS RTK work, the times you really, really struggle to get that tough fix is when you have a very weak, inferior signal trying to “help” in your overall solution. The “bad” data being thrown into the solution by it sometimes keeps the other, more solid signals from giving you a solution. I.E. - 8 or 9 sats in a rough area can, and sometimes will, knock out two separate three phase shots in a matter of a few minutes and sometimes that same spot could give you 11-13 sats and you may be getting three 15 minute PPK shots....
8 or 9 usuable sats is typical in this area rather than exception. So it seems the benefit would be in adding a couple to the mix. Currently there are six different algorithms trying to solve in different ways from that mix. If I take away one of those and replace with say glonass/galileo, I might have 5 engines working on the 8 or 9, and 1 engine working on 5 or 6. I have great confidence in Javad and his team, and the approach seems a more efficient use of memory. But I do wonder why it wouldn't be easier to upgrade memory, and if memory is going to be a problem down the road anyway. Maybe users would balk at sending in units and paying for chip upgrade, or maybe it's not even possible. At any rate, I will try it out later this week and see what I can break:)
 

Duane Frymire

Active Member
After so many signals in a single engine, you get to a point of diminishing returns. I think separating the signals between engines will ultimately prove to be a very successful approach to faster verification, but we'll have to see.
I'm going to try it later this week. In this area I rarely see more than 11 or 12 being used so too many signals is a problem I can only dream of. Been trying to find some recent writing on the signals with thoughts of which two might be good choices to work together in one engine. Do you have any resources you can share? Looks like the newer signals (mboc) are requiring the reciever to store and remember data that used to be continually streamed, hence the memory problem? Using T2 as base, looks like all engines would be set to GPS/Glonass, ie one setting for all engines?
 

Darren Clemons

Well-Known Member
8 or 9 usuable sats is typical in this area rather than exception. So it seems the benefit would be in adding a couple to the mix. Currently there are six different algorithms trying to solve in different ways from that mix. If I take away one of those and replace with say glonass/galileo, I might have 5 engines working on the 8 or 9, and 1 engine working on 5 or 6. I have great confidence in Javad and his team, and the approach seems a more efficient use of memory. But I do wonder why it wouldn't be easier to upgrade memory, and if memory is going to be a problem down the road anyway. Maybe users would balk at sending in units and paying for chip upgrade, or maybe it's not even possible. At any rate, I will try it out later this week and see what I can break:)
I agree 100% Duane. If it’s just a problem of upgrading the processing chip, and paying to do so, I’d gladly send my units back to have them “powered up”. All of us in our company have already talked about that. Having to do something like this to allow the current GNSS chip to “handle it” hasn’t been a very comforting thought from the first time I heard it. It’s still quite mind boggling, to be honest, that this is even an issue with all the technology and engineering involved in the LS and with it being known literally for years that Galileo and Beidou we’re coming online.
 

Darren Clemons

Well-Known Member
I'm going to try it later this week. In this area I rarely see more than 11 or 12 being used so too many signals is a problem I can only dream of. Been trying to find some recent writing on the signals with thoughts of which two might be good choices to work together in one engine. Do you have any resources you can share? Looks like the newer signals (mboc) are requiring the reciever to store and remember data that used to be continually streamed, hence the memory problem? Using T2 as base, looks like all engines would be set to GPS/Glonass, ie one setting for all engines?
I believe Javad is referring to a total of 20-26 signals, which is only 10-13 dual frequency satellites. The current pre release, as I tried it last week, would only allow for a maximum of 13 satellites to be used in any particular engine configuration. Even if you’re not using Galileo yet and you’re “tracking” a total of 15 satellites - 9 GPS and 6 Glonass, two of those satellites will now be tossed out of the solution process, leaving you with the maximum of 13 dual frequency sats for the total of 26 different signals.
 

Matt Johnson

Well-Known Member
5PLS
Looks like the newer signals (mboc) are requiring the reciever to store and remember data that used to be continually streamed, hence the memory problem?

No, the drain on the resources is from tracking additional satellites and RTK processing. Each additional satellite and signal that is added exponentially increases the processing power that is needed in RTK processing.

It’s still quite mind boggling, to be honest, that this is even an issue with all the technology and engineering involved in the LS and with it being known literally for years that Galileo and Beidou we’re coming online.

The current Triumph 2 chip went into production approximately 6 years ago. What is possible now was not possible then. Moore's Law predicts that processing power doubles every 2 years.
 

Duane Frymire

Active Member
No, the drain on the resources is from tracking additional satellites and RTK processing. Each additional satellite and signal that is added exponentially increases the processing power that is needed in RTK processing.



The current Triumph 2 chip went into production approximately 6 years ago. What is possible now was not possible then. Moore's Law predicts that processing power doubles every 2 years.
If too many satelites is now the problem, couldn't we go the other way with mask angle to eliminate some? I was once told might as well make it 5 deg. instead of traditional 10 because engines would eliminate the bad signals or geometry. So , why not set mask angle to 20 or 40 through 80 (whatever ideal range is), something like that?
 

Shawn Billings

Shawn Billings
5PLS
I think you all are missing the potential of having these signals processed by several engines instead of one engine processing all of the signals. If all of the signals go into one pot, you do not know how each signal may be contributing to the final solution. It could be that with many signals in one solution that some signals would be weighted so as to not really make any contribution to the resulting position. By segregating them, you can see that for Engine 1 which is set to some set of signals, that it is fixed and agrees with Engine 2, that is set to an entirely different set of signals. How might this affect our verification procedure when two engines using two different constellations are fixed and agree with one another? I don't have the answer to that question, but theoretically, I think it could make a significant positive impact on verification. All of the signals are still being used, what we are looking at is strategies on how to use them. Do you know what strategy Trimble, Leica and Topcon are using with their processing? Or do they just give you a solution? How are Beidou, Galileo and Glonass weighted in their engine? Presently you can actually look and see if you can get a Glonass-only, or Galileo-only or Beidou-only fix, side by side if you prefer.

Y'all are complaining without even knowing the benefits and limitations of what is being offered.
 

Duane Frymire

Active Member
I think you all are missing the potential of having these signals processed by several engines instead of one engine processing all of the signals. If all of the signals go into one pot, you do not know how each signal may be contributing to the final solution. It could be that with many signals in one solution that some signals would be weighted so as to not really make any contribution to the resulting position. By segregating them, you can see that for Engine 1 which is set to some set of signals, that it is fixed and agrees with Engine 2, that is set to an entirely different set of signals. How might this affect our verification procedure when two engines using two different constellations are fixed and agree with one another? I don't have the answer to that question, but theoretically, I think it could make a significant positive impact on verification. All of the signals are still being used, what we are looking at is strategies on how to use them. Do you know what strategy Trimble, Leica and Topcon are using with their processing? Or do they just give you a solution? How are Beidou, Galileo and Glonass weighted in their engine? Presently you can actually look and see if you can get a Glonass-only, or Galileo-only or Beidou-only fix, side by side if you prefer.

Y'all are complaining without even knowing the benefits and limitations of what is being offered.
I'm not complaining Shawn. Just questioning and floating ideas.
 

Matt Johnson

Well-Known Member
5PLS
If too many satelites is now the problem, couldn't we go the other way with mask angle to eliminate some? I was once told might as well make it 5 deg. instead of traditional 10 because engines would eliminate the bad signals or geometry. So , why not set mask angle to 20 or 40 through 80 (whatever ideal range is), something like that?

The RTK engine algorithm will select the best satellites to use. This is much better than have the user set some high mask angle to limit the satellites.
 

Darren Clemons

Well-Known Member
I think you all are missing the potential of having these signals processed by several engines instead of one engine processing all of the signals. If all of the signals go into one pot, you do not know how each signal may be contributing to the final solution. It could be that with many signals in one solution that some signals would be weighted so as to not really make any contribution to the resulting position. By segregating them, you can see that for Engine 1 which is set to some set of signals, that it is fixed and agrees with Engine 2, that is set to an entirely different set of signals. How might this affect our verification procedure when two engines using two different constellations are fixed and agree with one another? I don't have the answer to that question, but theoretically, I think it could make a significant positive impact on verification. All of the signals are still being used, what we are looking at is strategies on how to use them. Do you know what strategy Trimble, Leica and Topcon are using with their processing? Or do they just give you a solution? How are Beidou, Galileo and Glonass weighted in their engine? Presently you can actually look and see if you can get a Glonass-only, or Galileo-only or Beidou-only fix, side by side if you prefer.

Y'all are complaining without even knowing the benefits and limitations of what is being offered.
Not complaining here either Shawn, just stating some things I saw last week and making comments (thought that’s what message boards were for ;)). I think a lot of us are just tired of waiting and quite confused. This last two days of discussions has probably enlightened several of us more than the past 9 months! We’ve kind of been left hanging in the dark without much info to be honest. Discussions like this are what a lot of us want to read so we’re kept in the loop, at least on some level, of what’s being worked on. “Everyone else” , we’ve heard, has Galileo and Beidou already and we know Javad’s will be different and superior once we get it. We’ve got a bad ass system already that will outperform all the others even with the additional constellations.

I get the gist completely now on what the end result now is going after. Lots of different solutions from lots of different signals in lots of different combinations, which, as you say, will lead to a much better verification process.

As I mentioned earlier in the thread, I totally believe Javad is “The master” of all things GPS and this will be the best product out there. I just think it’s going to be much, much different than ANY of us thought. It is for me anyway. Any of us who’ve used GPS in canopy for years have always begged, pleaded and hoped for “more” satellites to increase our chances of a fix. Just the mention of “only using a maximum of 13” puts most of us in a panic.
What’s being planned is that we’re not, of course, only using 13 and 13 only - ONE engine is using a max of 13, another engine a max of 13 and so on....if you are tracking a total of 30 - 10 GPS, 5 Galileo, 7 Beidou and 8 Glonass they all will be used - just not all in every engine.
 

Shawn Billings

Shawn Billings
5PLS
What’s being planned is that we’re not, of course, only using 13 and 13 only - ONE engine is using a max of 13, another engine a max of 13 and so on....if you are tracking a total of 30 - 10 GPS, 5 Galileo, 7 Beidou and 8 Glonass they all will be used - just not all in every engine.

Exactly.

And I can't say for certain yet, but I think this divided approach will be superior to having all 30 in one engine anyway. As the PLS team, we're only about a week ahead of what you all know. Things are progressing quickly now and we now have the tools in Pre-Release and Testing versions to start making some tests to see exactly what these new capabilities will actually mean in the field.
 

Greg Flowe

Active Member
How is the testing going? Are you seeing any drastic improvements on the tracking in canopy? I look forward to hearing good news.
 
Top